A Startup doesn't have to Grow into Product & Engineering

All minds have to see the whole task to contribute effectively. — Oppenheimer

A startup usually begins life as a single-digit strong team with no boundaries. As they grow, they might soon find themselves to be a 200 strong company with function-aligned teams such as marketing, sales, product, engineering, support, etc. Each function is led by a director or a VP who reports to an SVP or CxO. The functions collaborate with each other, no doubt, but quite often, there is unhealthy tension between them.

Function Friction

Product might think that Engineering isn’t aligned with its priorities. Their OKRs might not align. Then there’s the daily dance of delivery. Engineering might think that product is burdening them with lots of half-baked specs. They might feel like they are a feature factory even if they are not. For example, if they don’t have easy access to product and marketing analytics, or if they are discouraged to discuss them, then they are a feature factory as far as they are concerned.

Sales might think that the business ought to be sales-led, product might think it ought to be product-led, design bats for being design-led, engineering for being technology-led. More the functions, more such notions. Soon enough, these notions translate to not-so-collaborative behaviors. They might begin to optimize for their needs at the expense of the larger good. Your growing startup begins to suffer the effects of organizational debt.

Organizational debt

Organizational debt can be worse than technical debt because unlike software design, "organization design is rarely thought out from a baseline of principles. The prevailing design is mostly a product of happenstance, mergers or acquisitions, people-retention compulsions, and the ideas of whoever is in charge at various levels in the organization".

Organizational debt might be worse in the classic enterprise—the 10K+ people organization. Their success in the market is often a result of the momentum they have built up over the years. Current structures and team dynamics might often be slowing them down without their knowledge. It can be a nasty off-balance-sheet liability.

Do it Differently

The dysfunction is avoidable if you hire right and organize right as you grow. As a small startup, you have the opportunity to avoid growing into the structural dysfunction of the biggies you compete with. You have the opportunity to be business-aligned rather than function-aligned in your org structure.

It means you align your teams along product lines, product modules, capabilities, or value streams. Not along functions. You don’t have a marketing org, a product org, or an engineering org.

For instance, say you are a startup building the next Jira. Don’t grow into Product and Engineering. Instead, organize along product modules: user and permissions management, core issue tracking, workflows, dashboards and reports, etc. Put someone in charge of product and engineering for each module. The product manager and the engineering manager for that module report to the module lead who might be a VP-level hire for a growing product. Module leads report to a Business Unit Lead—similar to a P&L savvy CPTO for the product.

As your startup grows to include new products, repeat the design. Doing it this way improves the speed and quality of product iteration as you race to strengthen your product-market fit. 

A bit like Amazon

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.

It Sucks Less

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.

Quality and Standards

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.

Reuse

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.

Career Paths

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.

Senior Hires

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.

CTO?

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.

Imagine a Product Organization where individual contributors such as product analysts report to product managers who report to product directors who report to an SVP of Product. And a bigger (usually) Engineering organization where individual contributors report to managers and all the way up to an SVP of Engineering. When a product analyst from Product collaborates with their counterpart in Engineering in this setup, the organizational distance is 9 as shown in the figure. It can be reduced to 4 with a business-aligned structure as shown below.

Organizational distance limits the quality and speed of iteration and collaboration because each organizational sub-unit has its own sub-culture and its own priorities. Habits and worldviews harden along the solid reporting lines because that’s where work assignment, pay rises, team mobility, and promotions are decided.

You are not Apple

Apple is a rare example of a large successful business that is not organized around its products or business units. In 1997, as Steve Jobs returned to Apple, he refactored the various existing business units with separate P&Ls into a function-aligned organization with a single P&L. How else could he be the detail oriented Master of Product Design that he was? The reorganization certainly put him firmly at the center of all major decisions. It was a power move to exert more control over product design and direction and it only worked because of who he was. Over time, his successors learnt to work with it.

That said, they still don't have functions like Product and Engineering. Product and engineering roles exist, but they are under functions such as Retail, Software, Hardware, etc. Even under Software, they are not organized as Product and Engineering. Instead they have teams such as Apps & Frameworks, Cloud & Infrastructure, Core Operating Systems etc. This reduces the organizational distance for the most common vectors of intensive collaboration.

What if you are Stuck?

What if you are already deep into a function-aligned organization? You see the problems but there is no going back. It’s too big a change and too disruptive. What then? Your best bet is to introduce a robust mechanism that raises the stakes for cross-functional iteration and collaboration.

I have written about this topic earlier in terms of activity and business outcome oriented teams and business-capability-centric organization. They are available on Martin Fowler's website. Function-aligned teams lie in between activity and outcome oriented teams because a function carries out a set of related activities. It is still short of owning all the key activities that contribute to a business outcome. Avoid it if you can.

To get notified of more posts like this, subscribe to my newsletter on LinkedIn.