Specialization Is For Insects
Coordination effort is a silent killer.
As companies grow, there is a stark shift from having a team of generalists to a team of specialists.
A young startup might ask an engineer to play roles ranging from engineer to PM to interim manager to solution consultant and more. A young startup might ask a PM to be a PM and pricing expert and a product marketing expert and a documentation writer and an ersatz designer and an interim engineering manager.
In bigger companies, all of these roles are done by specialists.
The upside of this transition is that, most of the time, you get higher quality output for each of these vocational tasks as you specialize. A dedicated pricing specialist is way better than a pinch-hitting PM. A PM is way better than the average engineer doing PM stuff.
There are major downsides though.
The number one downside is that all of these specialists must coordinate to get anything done. Coordination effort skyrockets. This can lead to dramatically increased times to deliver projects. And, sometimes, the coordination effort is so significant that the project slows to a crawl and lacks time for iteration, leading to lower quality.
In a world where slowness kills companies, this can be existential.
Another major issue is that as the number of required specialists goes up, the probability of an underperforming member of a project team goes to 100%. Most companies have 0 ability to react in realtime to an underperforming member of a project (perf management is too slow; embedded roles lack visibility). This can lead to serious deficiencies, slow delivery, and morale issues.
Finally, an amazing engineer is actually better than an average PM at product management. An amazing PM is actually better than an average pricing expert on pricing. As a result, deference to specialists can be deadly. If a great PM says that the design sucks, I don’t care if a middling designer has more experience, the design probably sucks.
Headcount growth is part of any successful company trajectory. But, to avoid these pitfalls, ensure that:
You stay as lean as possible as long as possible (with great people in seat). Don’t let yourself go beyond 2 org chart layers until you’re absolutely forced to do it.
You have strong oversight over projects as specialists increase in number. You should be able to make sure that projects don’t go slow, and you should also have a process to detect and correct performance issues.
Share to Twitter , Hacker News , LinkedIn
Great post! It is true that the coordination required to use multiple specialists will significantly slow down the project.
However speed is not always what is the most appropriate. Doing a task/project fast and "sort of" hit the mark, can be worse than performing it slower but with higher quality.
I guess it is one responsibility of the leadership to define what matter for each project, and what "good enough" looks like.
Great post!
I agree with the cost of coordination. It's especially visible as a start-up moves to a scale-up and then to a mature company. These transitions are when many employees leave, since the work has slowed down. Only a few companies can keep the teams empowered and autonomous.
I found Clement Kao's article on the organisation's coordination costs to be insightful. https://medium.com/product-manager-hq/coordination-costs-8d614a81ec08
As the company matures, it should ask the team about the hours spent on coordination. This allows it to establish a metric and try to monitor the velocity.