Engineering Org Design: Code-centric vs. Product Goal-centric Teams

There are many facets to engineering and product org designs, and a full discussion could easily fill a book.

One thing that is certain though, is that there is no such thing as a perfect org structure. Whatever is chosen is a compromise with a set of tradeoffs. And being crisp and explicit about what tradeoffs you are making is probably the single best thing you can do.

Probably the most common tradeoff in org design I see for startups that are starting to scale relates to the types of mission/scope you give to engineering groups/teams.

Broadly speaking the two most common approaches, are what I will frame as ‘code’ vs. ‘product-goal’ centric approaches. And neither is universally superior. They optimize tackling different problems, while also creating their own unique problems. The best choice will depend on what is urgent for your company in the next year or two, and what downsides you can tolerate. In fact, in my 20 years of experience, I have seen an almost predictable tick-tock between the two approaches every 18–24 months as a company grows and scales (though ‘code-centric’ tends to dominate at smaller team sizes and ‘product-goal centric’ tends to emerge more at larger company sizes for reasons that I’ll attempt to outline), but hopes of picking a model that will last indefinitely is probably naïve.

So first let’s define our terms.

A ‘code’ centric approach is one where engineering teams are organized to have missions that have code or technology defined boundaries. For example, a “web” team, or a “database” team, or many notions of “platform” teams. These teams are organized around strong ownership of a particular part of a code base and the technology affinity that engineers in the area may share, but are more often required to be in service of multiple product goals, and have a more matrixed relationship with the product mgmt. organization.

A ‘product-goal’ centric structure is one where engineering teams are primarily given missions that have a product goal (or sometimes a metric) as their mission. Some examples might be the “XYZ product” team, or an “ABC feature” team or a “performance” team. In contrast, these teams have strong ownership of product goals, and clear alignment with the product mgmt. organization, and have a more matrixed relationship with the codebase itself.

In rough visual form:

It’s worth noting that if you can find areas of your work where product goals align to an exclusive technology stack, you should almost certainly embrace it with your org structure (an example might be a modest sized discrete Mobile application) as it will often be the best of both worlds, but unfortunately for medium sized companies such opportunities are the exception not the rule.

What to choose and when to choose it…

Here we’ll summarize the differences, and discuss in more detail, as well as what to look for in your organization to find the right fit.

Code centric:

Pros:

• Engineering skill concentration
• Expertise development, easier hiring
• Strong code ownership and lower ‘bus-factor’ risk
• Able to invest in/re-architect an area of the code base
• Code will develop and mature more quickly
• Best leverage of tech leads
• Testing infrastructure & reliability

Cons:

• Higher burden on product/program management co-ordination
• Harder to make big direction changes, introduce large new product capabilities.

Product-goal centric:

Pros:

• Stronger partnership with product organization
• Clearer accountability towards goals / impactful metrics
• Better understanding of users and customer amongst engineering
• Able to tackle more ambitious product changes/investments

Cons:

• Requires diverse engineering skills on each team
• Code quality and engineering productivity will decay over time

Engineers

With a code-centric group structure, you can more easily put engineers with a common interest or skillset together. You can leverage senior engineers to more effectively mentor and supervise the more junior ones and you will be growing the expertise of your engineering team more quickly because of this. Hiring tends to also be a bit more efficient with easier to access referral networks and expertise concentrated to better identify the best candidates in a particular specialty.

Conversely, with a product-centric structure, you will need to ensure you have enough folks with the right skill sets to assign to different groups, such that each group actually has what it needs to go after it’s mission. They will also require some level of organizational support to maintain a community around the code-area or technical specializations, to cover things like code-ownership, and increasing their technical expertise (see my colleague Ryan’s post on how an Eng Ops organization can help here). A simple rule of thumb is that you should have at least 2 engineers in each product-centric group that can cover a particular technical specialization. This is to provide code-reviews, avoid “bus-factor 1” problems and mitigate isolation. If you can’t meet this minimum, think really hard about whether you can actually make this model work.

State of the codebase

Many companies are not investing in maturing their codebase as they chase after initial product/market fit. However, as they find fit, and secure funding to scale the company, the balance often shifts, and can shift back again, as the company evolves further and needs to expand it’s product portfolio.

Broadly speaking having a code-centric org structure will pay down technical debt, while having a product-goal centric one will incur it.

Further, the code-centric model is in my experience the only way to go if your ambitions include significant upgrades to major engineering subsystems within your product.

Let me digress briefly into my favorite mental model: technical subsystem maturity. In it, each major subsystem goes through 3 major generations to reach maturity.

The first generation is constructed with lots of duct-tape, bailing wire and energy drinks. You’re not exactly sure what is needed, so you just do what’s required to keep things working as you add new capabilities. Dreams of robust testing infrastructure remain as dreams. But then, there comes a point where that approach has clearly reached it’s limit. You need to make something that is more reliable and can support more engineers working on it, while also supporting a few new capabilities.

Generation 2 then makes it’s appearance. It has similar functionality as Generation 1 but with a focus on removing most of the overtly broken/confusing/embarrassing parts, with a sprinkling of additional functionality and extensibility, but more importantly new people can come up to speed on it and be productive. This then serves you well hopefully for at least a few years, when it’s limited capabilities, inflexible architecture, and/or increasing requirements for good participation in the overall technical ecosystem around it often require a 3rd generation to be developed.

This 3rd generation generally gets it right-enough and is the point in time when most reasonable engineers would call a system mature, and can often be supported by a smaller number of engineers, with minimal drama disseminating from it’s general direction.

Anyhow, when you are approaching one of these inflection points where you need to really tackle upgrading a subsystem, you will almost never have success if you have to pull together a virtual team or committee from a bunch of different product-centric groups to tackle it. You need the technical leadership, goal-alignment and concentrated expertise of code-centric organization, or you should simply defer tackling this.

Conversely, if you have recently crossed over one of these inflection points, or simply are not as concerned about the state of the code base, you may be better off in a product-centric organizational structure. This will move the product forward more quickly, and enforce better discipline with the teams about what work they prioritize (e.g. don’t build APIs in a vacuum).

Co-ordination complexity

A key tradeoff between these models is where the complexity around coordinating work lies, and subsequently on the maturity of the product management organization and engineering managers/tech leads. Think carefully about the strengths and weaknesses of the people in your current organization and where it is most able to navigate and absorb the type complexity the org design creates.

A code-centric model pushes a lot of complexity onto the product management organization. For a product manager to execute successfully on their job will require negotiation and aligning priorities and schedules across multiple engineering teams. Do not underestimate how challenging this can be, especially in environments that lack robust global prioritization mechanisms, and clear roles and responsibilities between engineering, product and program management functions.

Experienced product managers in organizations with a mature product development process can manage this, as can your rare superstar PM, but with anything less, you should assume some negative consequences of this as part of the overall org design tradeoff.

Unfortunately, the product-centric model also creates it’s own coordination burden, this time on the engineering side of the house. Multiple engineers from multiple teams will be expected to work simultaneously in the same codebase with different goals, and will need to navigate the process (or anarchy) associated with this as well. An engineering team not ready for this may also stumble badly, though generally speaking this tends to be somewhat easier for less mature organizations to slog through than the product side complexity (if for no other reason than the conflicts escalate at worst to the Eng VP not to the CEO).

Accountability

The last major tradeoff theme is around accountability to impactful goals. Here the product-centric model has a pretty clear advantage, and is in my view one of the reasons that this model tends to dominate in larger and more mature organizations where accountability concerns also dominate.

Accountability in this context consists of three pieces: a mission with clear value to the business, the authority and resourcing to prosecute that mission, and meaningful credit/fault for it’s success or failure.

In a product-centric model, you’ve got a pretty straight-line relationship across these. You’ve got a product manager at the tip of the spear who selects the mission, backed by a dedicated team of knowable size to execute against the chosen mission. Wrong mission? It’s clear where the problem lies. Sloppy execution? Clear again. Wrong resourcing? Easy to see.

Conversely, in an engineering-centric model, it gets matrixed all to hell. Product managers are likely selecting missions in tension between what customers want and what they can coax the engineering org to execute against. Prioritization and resourcing conflicts/ambiguity abound, and if it’s not going well, it can be entirely unclear where the problems really lie as most people involved only have visibility into a partial slice of the big picture.

In smaller organizations where it’s still possible to have executive leadership maintain a good grip on these facets, these concerns can be managed and minimized, but as responsibility and execution gets decentralized as you scale they will become bigger and bigger concerns.

A “typical” journey

While I’m not sure there really is a typical journey for an org structure, if one were to exist, it might look like this.

Early Days

Code-centric — Org structure is not top of mind. Engineers are hired and get right to work on the code they know best. At some point it makes sense to form teams, and the easiest thing to do is to lump engineers who work on same code on the same team. There isn’t much in terms of competing demands, and the product organization is nascent and concerned mostly with supporting development in the founding direction of the company so this works fine for a bit. Tick.

Product Growing Pains

Product-centric — As the company acquires more customers, and listens to what they have to say, prioritization across conflicting demands starts to emerge, and a more opinionated product organization naturally develops. It starts to realize, however, that it’s really hard to get engineering to execute against these more nuanced priorities. The case for a product-centric organization is at hand. Tock.

Engineering Growing Pains

Code-centric — That works ok for a bit, but with increasing frequency, the asks coming from the product organization are met with a response from engineering that they are either not possible, or not remotely efficient to do with the highly suboptimal current state/structure of the technology stack. Tick.

Accountability Growing Pains

Product-centric — The company has a few high profile projects that are late/don’t meet goals. Many meetings are called to dig in. Several slide decks are authored. Ultimately it’s agreed that a product-centric structure emerges as the best solution to the current problem at hand. Tock.

Same problems, more scale, more options

Hybrid/Nested — Tech debt as a limiting factor rears it’s head again, but in some far more than others. The company as a whole has matured and is not willing to entertain compromise on weaker prioritization or accountability mechanisms it has built up. But it’s now large enough that these org design tradeoffs do not need to apply universally to all of engineering. Perhaps a more code-centric infrastructure/platform “division” emerges, alongside product-centric product engineering teams. Or possibly the company is even ready for multiple self-contained business units, which then recursively apply these principals within them.

Summary

So, if you got this far, hopefully it’s clear that there really is no one best answer, and that product and code-centric org designs are best thought of as levers you have at your disposal to shift tradeoffs, depending on your current goals, challenges and dysfunctions.

When tackling an org design, be clear up front on your priorities, what you need to optimize for and what you can live with. And remember that the structure discussed here is only one part of what you need to design for (the people and roles are equally if not more important!). But to boil the structure part down:

• Product-centric aligns product and engineering, accelerates product and shifts burdens to engineering, fosters accountability and creates technical debt
• Code-centric aligns engineering and code, accelerates engineering and shifts burdens to product, pays down technical debt and can muddy accountability especially at scale.

Best of luck and happy re-orging!