There are a lot of companies developing products.
Many of them started as small “garage” startups, with all the creativity, inexhaustible energy and high delivery pace. Others, that are big enterprises, have already forgotten how it was “to be a small startup”. Anyway, after some time (after the growth) most of these companies struggle with low quality of new product ideas, low speed of development, lack of ownership.
They struggle with lack of Product Thinking.
Most of these companies realize that there are challenges that must be solved, and all of them start “improving” their products. But only a few succeed.
Why?
Because they are fixing just symptoms but not the root causes.
Years of working within startups and product companies made me learn that most of the problems are more or less the same and their basis is in organisational design and behavior.
Below is the list of 7 typical organizational barriers I’ve seen so far that prevent your product from prosperity.
Barrier 1. “Slow” team patterns.
The most typical examples of “slow” team patterns are functional-, component- and BIG teams. In 99,9% cases these patterns slow down the value delivery speed significantly.
Having separate Front-end, Back-end, QA, DB teams creates room for “errors” in communication and delays delivery of value. It also often leads to lack of ownership: every team does “its” part of the feature.
What is a BIG team? 15+ people (yep, even in 2022 this may happen). No comments. Too many communication connections to deal with.
What to do?
Captain Obvious: instead, as much as possible utilize small (aka. two-pizza) Cross-Functional teams that can be responsible for end-to-end solutions.
It’s not a dogma to have 100% teams cross-functional, but I suggest striving for this. Of course there are corner cases, when it is really more beneficial to utilize e.g. functional teams, but they are rare CORNER cases.
Barrier 2. Short-lived teams.
What is a short-lived team?
It is when the cast of the team changes so quickly and so often, that the team can’t approach high-effectiveness. It’s not necessarily about high staff turnover (but it is also the case). It is more about rotation of people between teams, projects, departments. On one hand such an approach may help to address emerging opportunities quickly, which is especially important for service/outsource companies. On the other hand, it does not really allow the team to get to the top level of performance.
Everybody(almost) knows about Tuckman’s team development model, which consists of 4(+1) stages: Forming, Storming, Norming, Performing (+ Adjourning). Yep, this model is too simplified for the modern environment, but at least it shows an approximate trend of how teams evolve. So, short-lived teams can’t be too long (if ever) on the top level of their performance by their design. Perpetual changes move them to the earlier stages (of course there can be exceptions, but in general this works like described). It does not mean you should avoid rotating people between teams/streams/departments. But you need to do this carefully with the eye on the team forming processes.
One of the not so obvious side effects of “short-lived teams” is that their setup does not motivate people to learn the business domain in depth: everyone understands that highly likely they will be moved to another team soon, hence “why to waste time for deeply learning something temporal?”.
Both mentioned aspects lead to lower quality of ideas and solutions, lower customer focus, slower feedback loop, lower team performance.
“Short-lived teams” is a very typical pattern in service-oriented companies.
What to do?
Unlike the previous barrier this one is not as clear to be solved quickly. The roots may be in the company business model (as for service-oriented companies). In such a case you likely can’t solve it completely. You have to find compromises. My suggestion is if you have to rotate people between “business domains”, rotate the entire team. At least the performance of the team will be affected less.
Barrier 3. “Single point of contact” roles
One more very common approach.
It is so convenient to have someone who will be responsible for everything, someone who answers all the questions, a single point of contact… and failure).
Typical example of such a role is a Delivery Manager. Once, when I was in this role I heard the following expectations from me: Project Manager, Solution Architect, People Manager, Agile Coach, Scrum Master and Product Owner (all mentioned roles, at the same time, in the same project; Scrum Master and Product Owner simultaneously).
My subjective opinion, products should avoid dedicated ownership and strive for the collective one instead.
Why?
Because collective ownership promotes collective decision making, which aids engagement, support, and brings on higher quality of these decisions. You may argue: collective decision making is slow! And you are right. Partially. Of course, in some critical situations you’d better take all the responsibility on you and make the quickest decision. But overall, the quality of the collective decision outweighs slight “delays”.
What to do?
Review your org structure, find out a single point of failure/contact, start sharing responsibilities for the “final result”.
For example, you develop some product. A Product Manager provides “vision and requirements” to the Engineering manager, who then is responsible to “deliver” it within her/his dev team. And then everybody (even the product manager) requests the EM to provide “the status” once per 1-2 weeks. In such a case you inevitably get to the situation, when all of the decisions (and then failures) will be on the EM.
Start with creating “a delivery pair”: PdM and EM. Now they BOTH are responsible for the final results. This will be the first step to collective ownership.
Barrier 4. Proxy-roles.
What is a proxy role?
Speaking name. It is a permanent role which acts “on behalf”, has a clear function, but no responsibilities to make the decisions the “on behalf” part can.
It’s easier to get it by an example.
The most typical proxy role I’ve ever faced is Business Analyst. Important note, I’m not saying that BA is a useless discipline. I’m talking about the implementation of this role in most of the teams.
What does a “typical BA” do in 95% cases?
He/she collects requirements from a very busy Product Owner (I call such a role “user story writer”). Sometimes he/she may even play a role of a “proxy-PO”, substituting the real-PO at team meetings but without any real power of prioritizations (you’ve definitely heard from BA “I need to ask the PO”).
If we project proxy-roles on the software development, they are like additional integration points (in communication, in our case). As you should know, integration points are one of the main sources of errors and slowdown. In addition to that, there will be one more negative consequence in the specific example above: a team highly likely will be significantly less involved in the business. “Hello” to the lack of focus on the end-user.
One more example of proxy roles is a “classical” Project Manager (I usually call this role Project Coordinator). The person who controls all the communication channels, “connects” the team and stakeholders/users/whoever. As a result, if developers have questions to stakeholders or users, they ask PM to ask 🙂
What to do?
You do not need to eliminate proxy-roles if there are no proxy-roles
Vlad Zenkevich
Usually, the presence of proxy roles is a sign that someone could work better 🙂
First, review all the roles involved in the value delivery flow.
Second, ask yourself “What key expertise/skill/resource this particular role has that can’t be covered by other roles?”
Third, if you find proxy roles, deep dive into the real reasons these roles exist.
Let’s get back to the example when BA plays the proxy-PO role. Maybe your PO is overwhelmed with too many teams and simply can’t work with them closely? Or maybe the PO does not want to be PO? Maybe there are “single-point of contact” roles? Maybe the original role can be played only in a part-time manner and the proxy backups it?
Based on that you can decide what to do. Usually, you either will re-distribute responsibilities or support the “original” role to get to the required performance.
Barrier 5. “Boss-Executor” relationships.
Unfortunately, this toxic approach still can be seen in collaboration between… the boss and the report. All the decisions are dictated top-down, without any discussion.
However, this is not the only case (and not the most important). Often this happens between peers. A typical example is a collaboration between Product Manager and Engineering Manager, when the former is a de-facto boss for the latter. You can often hear “I’m the Product Manager, I’m a mini-CEO, I’m setting the priorities, your job is to implement them”, or “I’m a main contact point for our stakeholders (hello “single-point of contact” roles), they expect me to be responsible for the whole product, so I expect you to…”.
You may think that there is nothing wrong with such an approach: clear process, everybody understands who is responsible for what. Kindly read Barrier 3.
By following the “Boss-Executor” approach you lose a part of the objective picture, opinion of another party with different skills, experience, ideas. Again, you lose collective ownership and get a lower level of involvement and responsibility in the team (I won’t be repeating myself about the benefits of collective ownership).
What is even worse – you get into a “linearized” (aka waterfall-like) decision making process “I say, you execute”, with the lower level of these decisions.
What to do?
First, you need to understand the nature of the problem.
In my experience I have met 3 of them:
- Sometimes the problem would be in the decision making process. Likely, you will have to make cosmetic changes in the organizational structure and redistribute responsibilities.
- Sometimes organizational culture promotes such relationships. In that case, you will likely have to change the organizational structure. It’s a complex topic, often doomed to failure. Before doing anything, get full buy-in and support from the top management.
- Sometimes it is just a question of personality. Involve a psychotherapist and a lawyer, just in case.
Barrier 6. Stakeholder-driven solutions.
This happens when stakeholders/supervisors are directly involved in the decision making process of teams, projects, etc. down to design and architecture of features. In one of the advanced cases in my career I worked with a VP (with 200+ people in his department) who was participating in all decisions of his product team, even in “which color should this button be?”
Why stakeholders are not the best source of product decisions is a theme for another article. In short, very often deep stakeholders’ involvement in the product decisions results in linearization (a-ka waterfall) of the decision flow. It is not because stakeholders are evil (some of them definitely are). It is because such a setup promotes quick top-down solutions.
What to do?
The solution is as obvious as difficult to implement: one more organizational change – you have to move your stakeholders out of the product decisions process. It doesn’t mean “stop listening to stakeholders/supervisors at all”. They are a very important source of ideas. As important as users, dev team, sales, etc.
Besides the organizational change you also need to outline a clear and transparent decision process every party understands and agrees with (e.g. answer “why feature A but not feature B?”). This is a must-have point to get every party’s buy-in.
Barrier 7. Engineering is just a vendor.
Here I will be very very concise.
Simply, if you want to use not more than 50% of engineering potential, treat them as a vendor.
“We say if you’re just using your engineers to code, you’re only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation; yet, they are not even invited to the party in this process.”
― Marty Cagan, INSPIRED: How to Create Tech Products Customers Love
In many companies even their own internal IT dept is still treated as an external vendor. I call this approach “internal outsource”.
What to do?
Simply, start involving engineering in the decision process.
Isn’t it strange to keep people who actually build your product far away from the product decisions?
Conclusion
These were 7 most common barriers that impede cultivation of the product mindset.
Too often we try to make cosmetic changes (introducing new processes, new modern tools and frameworks, etc.) without having a careful look at the environment that surrounds these changes. Without a look at the design of the organization and what behavior it promotes!
My last suggestion is you’d better consider org.design and collaboration as the very first point to review before taking any action that you suppose must “improve” your org life.
Have anything been missed? If you have any ideas, kindly comment!
