I think that most practitioners in the technology space will have come across a project with an incredibly skewed managers-to-doers ratio. Symptoms are typically long discussions that are detached from the on-the-ground reality, difficulties to build consensus about the right approach because of the number of opinions involved, and a way too long wish lists of features (to include everyone’s input) for the capacity of the team charged with the implementation.
In this article, I want to explore one of the dynamics I observed that can lead to these constellations.
Every project requires a certain number of activities directly linked to the act of building the result and some activities around coordination.
Coordination activities are things like: Making sure that what is built is consistent with expectations (or the other way around). Bringing the right information to the right people so that they can make decisions. Resolving conflicts between team members and facilitating decision-making and much much more. These coordination activities are sometimes described as management. However, it is important to note that this work is not necessarily linked to any one person, it is completely feasible that several people take on this coordination work as part of their responsibilities.
Building activities are any actions directly on the value stream: Designing user interfaces, programming, making sure a system is running correctly, producing content that a customer is consuming.
These two categories of activities are both important for the success of a project. I have repeatedly argued that product management, i.e. determining what to build is one of the most important responsibilities around a software project because the best engineering team is worthless if you are building something that no one wants or needs. This is clearly in the camp of coordination activities.
Nevertheless, these two categories of activities are inherently different.
Consider for instance what happens if you add a new person to a team and you ask this person to primarily do building work: The additional person might speed up the development work, their impact may also be zero or slightly negative due to diminishing returns and the overhead of large teams, but the total amount of change in your output has a certain upper and lower bound.
Adding someone charged with coordination activities to a team can completely make or break the project. Having the right person at the right place can multiply a team’s efficiency whereas the wrong person could break the team dynamics or turn the project into a direction that makes it lose all value. Furthermore, it is not true that having multiple people charged with coordination activities necessarily improves the quality of the output. The opposite is quite likely true: Having too many cooks in the kitchen can cause conflicts of objectives or lead to a lack of alignment and focus.
How The Cycle Is Created
It is at this point I think that a vicious cycle occurs. If at any stage in the life of your organization a constellation occurs in which a significant number of people with coordination roles are involved – for example, a project that spans multiple teams – the coordination overhead will be felt. Many voices and opinions mean meetings need to be organized, protocols need to be written and goals need to be aligned.
It is tempting to try to resolve the situation by adding someone into the mix who can “stay on top” of all of this overhead. This new person again has a coordinating role. And while their contribution may be valuable for the project they were assigned to, this also means that in the next project that is launched, a new stakeholder is present, increasing the incidental complexity further.
To be clear, in some projects this complexity is inherent. Big projects indeed need to navigate a complex social and technical landscape and it is necessary to have someone in place that manages this complexity. The problem occurs if the complexity is not inherent in the scope of the project but purely incidental, arising from the structure and processes of the organization.
In the latter case, the new manager effectively becomes what David Graeber calls a “Duct-Taper”: A person whose main contribution consists in papering over a problem that exists purely because of inefficient processes. The added complexity is that the presence of this Duct-Taper may make the process even more complex for the next project, triggering the need for even more duct tape.
The solution to all of this seems obvious: Instead of applying duct tape, it would be better to simplify the process so that the additional coordination is not even necessary. I can think of a couple of strategies that may work depending on your situation – material for a future blog post.
However, in practice, this is not so easy. Adam’s, Klotz et al demonstrated that there is a human bias to solve a problem by adding an element to the status quo. Solutions that require removing elements from the existing situation are much less frequently proposed. In business life, this is even more complex as we are talking about real people who cannot just be pushed aside, reallocated, or reprogrammed.
Furthermore, there is an element of misaligned incentives: While the manager that has the authority to make the necessary changes to a project setup has an incentive to see it succeed, they also don’t want it to look trivial. There is not a lot of prestige in trivial projects. From the outside, it is sometimes hard to tell if complexity is inherent or incidental leading to an incentive to keep at least some of the incidental complexity in place.
In conclusion, solving this problem is likely not that easy. However, being aware of the proliferation cycle can already help us recognize when it occurs and to take early preventive steps.
The Solution Space 
Leave a Reply