I’ve been giving thought to high-level org design. Specifically, how decisions made around team orchestration have ripple effects throughout the broader organization and outwards to customers.
Organizational Options
When thinking about how to design an engineering org, there are a few classic approaches - each with their own set of advantages and drawbacks.
Functional Teams
In this structure, teams are organized by technical domain expertise. Teams govern a very specific set of codebases within their respective discipline.
An example would be a “Back-end team”, responsible for maintaining all server side code and a “Front-end team”, responsible for all client side repositories. When a project spins up, a set of developers are plucked from their functional groups to create an ephemeral project team. That ephemeral, cross-functional team ships the feature, then disbands back to their functional groups upon completion.
Product Line Teams
In this structure, teams are organized across product lines. These teams are cross-functional and permanent in nature. They have full autonomy in with respect to how they design and deliver their software, as well as a long term mission that guides their work.
An example of this approach would be a fully cross-functional team (BE, FE, Design, Product, QA & DevOps) dedicated to a specific product line - like a content management system. Pushing a CMS forward requires vision from Product, inspiration from Design, Back-end developers to configure server side code, and Front-end devs to bring the product to life.
Hybrid
This approach uses product line teams when appropriate, and one or two layers of horizontal, functional groups who serve the product line teams above them. Examples of core, functional layers in this approach tend to be groups like DevOps, Security, and/or QA - whose output can be used to support all cross-functional teams that rely on them.
Tribal Bands
Flat, tribal bands of teams, working in very loose coordination with each other. These teams tend to move very fast, but lead to a much greater chance of company-wide re-work, counter-productive competition, and communication challenges.
Benefits of Product Line Teams
I’ve had the opportunity to work in all of these variations during my career – both as an individual contributor and as an engineering leader. In my experience, teams find the most success, happiness, and clearly defined sense of ownership when organized into long standing, product focused teams.
A few desirable outcomes emerge when teams are organized across a set of well defined product lines:
Clear Mission
Product focused teams tend to have very clear missions.
In order to feel successful, teams need to know that the work they are doing is making an impact. They need to know how to define success within the context of the company’s broader mission. Once clear, they’ll know that each step they take, is a step in the direction to fulfill that mission.
Creating a clear north star can be challenging for purely functional teams. For instance, it’s easier to rally around a product driven mission of “let’s build a first class content management system”, than it is to rally around a more technical mission like “let’s build the most technically proficient, clearly architected codebase”.
Tight Customer Relationship
The feedback loop of understanding customers, knowing how to satisfy them, and shipping products to do so is a virtuous cycle.
Product focused teams who share a close relationship with their customers tend to have tighter feedback loops. They understand how to make their customers happy and gear development efforts to reinforce that relationship.
Contextualized Peer Review
When organized into product focused teams, code review tends to be contextualized around product initiatives.
Contrast this to being organized into functional groups, in which each member of a single functional team might be working on one-off features across multiple product lines. Peer reviews in this scenario often lack the necessary context to provide coherent feedback and code is either rubber stamped or held in review for long periods of time.
Clear Product Ownership
Product focused teams also tend to have very clear lines of ownership. As such, these teams know how to prioritize bugs, features, and technical debt within the domain of the product that they are responsible for.
Contrast that with a functionally organized org, in which features built by cross-functional, ephemeral project teams are left in the cold when it comes to maintenance.
I’d love to hear your thoughts on organizational design. If you have different experiences feel free to connect with me to discuss.
