When the general is weak and without authority; when his orders are not clear and distinct; when there are no fixed duties assigned to officers and men, and the ranks are formed in a slovenly haphazard manner, the result is utter disorganization. Sun Tzu
Quick — what’s the most important factor in scaling a high tech development team?
People. Getting and keeping great people is critical. Equally critical is how people are organized. (If your off-the-cuff answer was different, I recommend you read The Art of Scalability.)
Ideation, prototyping, and testing have to be channeled without slowing things down. Faster innovation, in the right direction, is correlated with success in the market.
In an effective organization, teams are organized in such a way that decisions can be pushed down to the lowest level, while the overall direction of progress serves the needs of customers. Alignment to customer needs is the role of the product manager on the team. Any time anyone has to go up a level, or sideways, or anywhere other than the team itself to make a decision, velocity is diminished.
Accomplishing a goal should require crossing as few organizational boundaries as possible. Each team should be able to innovate with few to no dependencies. I call organizations like this modular.
The best basis of a modular organization is a modular architecture. In such a system, each module is developed and released independently — as long as the module is serving its function, it is free to serve that function better and faster. New functions can be added without breaking existing ones. When the team is in charge of developing a module, the product manager can inspire the team to freely innovate to serve customer needs.
To make this idea more concrete, consider an organization where to release a new version of a service, you need to create a ticket for the operations team. The ticket goes into a queue. Your team needs to wait for ops before the new version can be released. Or likewise the opposite end of the stack, suppose the front end team can’t release a new design until the user research group has obtained and analyzed customer feedback. This blocks velocity and kills innovation. These problems with horizontal engineering organizations are well known.
A similar and less well recognized effect occurs when the product team is organized horizontally — for example where some people have access to customers and others don’t, or where some have access to data acquisition plans and others don’t. The product person either has to cross an organizational boundary to get what they need, or they have to guess. Velocity & innovation suffer.
Further, in such a team the “front end” product managers get blame or kudos for the full feature or product, even when they have no control over and make no contribution to the lower layers. This lack of control over one’s destiny makes everyone unhappy and kills motivation.
What to do if you find yourself in this situation? Ideally, band together with other product managers to form a vertical coalition. If that doesn’t work, you may need to quietly look elsewhere. And interview prospective companies more carefully in the future.