Amazon is structured on these lines. It has multiple business units—AWS, Retail, Devices, Studios, etc. None are organized as product and engineering. You only need browse their jobs page to understand how a particular division is structured. Here's Retail, e-Commerce Foundation, and Fulfillment.
AWS is set up similarly, not as a product org and an engineering org. Instead, it is made up of numerous service teams, each responsible for specific services (modules) like EC2, S3, Lambda, etc. Each of these teams consists of various roles, including product managers, software developers, solution architects, and more. Within these teams, there's a blend of product and engineering responsibilities, with the team collectively owning the lifecycle of their service.
Please note this is not the same as feature teams. They live only as long as they release a feature. Business-aligned teams are closer to real pods–not the fake pods you might have encountered as part of a digital transformation. Those are fake pods because the members of the pod all report to different managers belonging to different function reporting lines. So what, you might ask? Unfortunately, reporting lines make the difference between a team and a coalition.
Teams vs. Coalitions
Stringing together a selection of foot-soldiers from multiple reporting lines does not make for a real team. It doesn’t matter that they jointly participate in standups, planning meetings, demos, business reviews, and retrospectives. If they can’t make significant decisions without checking with multiple bosses, they are a coalition, not a team. And as we see with national governments, coalitions are not very effective.
We often witness the us vs. them syndrome or the othering effect with multiple reporting lines. A situation where we don't respect the point of view or the way of working of someone in another reporting line as much as that of someone in our own reporting line. It happens whether the reporting is business-aligned or by function. However, its effect is more severe with functions because functions typically need to collaborate more closely and regularly than business-aligned teams.
Perhaps we should stop saying agility needs cross-functional teams because that is mistaken to mean teams that span several functions. No, that isn't the point. The point is that we need people specialized in different functions in the same team. Mulitdisciplinary teams or polyskilled teams might be a better name.
No design is perfect and a business-aligned structure will have its share of challenges. But they’ll hurt your business outcomes less than the friction between functions. Even if each business-aligned team begins to optimize for its needs at the expense of the larger good, it will still represent business needs rather than the needs of a function.
But since the challenges are new and unfamiliar, you might be intimidated by them to consider organizing this way. Here's the lowdown.
Maintaining quality standards and consistency is one such challenge. How do we make sure that designers, developers, and other specialists adhere to basic standards and conventions? We solve the way it is solved for enterprise architecture and infosec—through lightweight governance and controls.
Achieving reuse in another challenge. Won't engineers in different teams keep reinventing the wheel unless they are under a single command? Again, this is mitigated the same way we ensure that their tech stack doesn't diverge too much from what is a standard choice for the company—through lightweight governance and controls. That said, you don't want to be too focussed on achieving reuse. Reuse implies dependency and sometimes, redundancy beats dependency.
You might worry about career paths in this setup. Roles above VP are multi-functional roles. They don't represent a natural progression from the VP role. In the beginning, these positions are held by the members of the founding team who probably already have multi-functional experience. The way for the others, who might join as ICs or managers in Product or Engineering, is to move horizontally before they move vertically beyond a point. Besides, some of it is addressed by the inevitable churn.
Finally, hiring for the BU Lead positions might pose a challenge. They might be less easily available than a pure product or engineering leader. Look for ex-startup CEOs–those who tried, ran out of runway, and are back on the job market–there’s usually enough of them because most startups don’t take off.
Does such an organization have a place for a CTO when no engineering managers report to them? Yes. You only need to look at Amazon again. All their developers, SDMs, or TPMs don’t ultimately report to the CTO, Werner Vogels.
Besides, many startups build their solutions on a base technology platform. The various modules/capabilities/value streams sit on top of this platform which is common to all of them. Ideally, this common base does not have any module-specific business logic. It is best developed and maintained by a team under the CTO.
Depending on the size of the common base relative to the module-specific functionality, the CTO's platform team will be bigger or smaller than the module-specific teams.
Organizational Distance Matters
Why does a function-aligned organization struggle as it scales? I think it has got to with the average organizational distance at which high-intensity collaboration occurs.
I define organizational distance between person X and Y as the number of sold-line hops needed on the org chart to go from X to Y.