The Perfect Product and Engineering Organization
“Any organization that designs systems will produce a design whose structure is a copy of the organization’s communication structure.”
Melvin Conway
One of the questions I’ve been asked most often, either as a part of diligence or talking with CEOs, is how the product and engineering organization should be designed. Many times the question arises out of perceived (or real) poor performance from this part of the company, and the belief is that by adjusting the organization the problems will disappear. Though organization design can be a part of the problem, it is rarely the root cause of performance issues.
There are many ways to organize product and engineering, and usually the right answer for your company is a blend of these different models, tailored to the personnel you have and the specific nature of the problem you’re solving. Let’s discuss the most common models and when they’re appropriate, keeping in mind Conway’s Law referenced above, that how we build our organization and communicate will materially impact the design of the system we build.
Foundational Principles of Organization Structure
Regardless of how you’re organized, there are a few principles that should guide your organization design:
- More smaller teams will outperform less, larger teams
- The more autonomous each team is within an organization, the faster you’ll go. Decentralize decision making as much as possible.
- Accountability for delivering on objectives should be clearly assigned to each team.
- Your design should reduce friction and dependencies wherever possible
Monolithic/One Big Team
In the early days of a company, or when a company has less than eight or so people in product and engineering, having everyone on one team is appropriate. The structure is flat, everyone knows what everyone else is doing, and the team can move quickly. However, once you get beyond this size, the Monolithic model begins to grind to a halt. Decision making gets slower, and dependencies begin to emerge. It is important to transition away from this model as soon as your team starts to bog down.
Product-Focused
A set of teams is assigned to a specific product, as the name would indicate. Each team should be as autonomous as possible, but all of the teams work together to deliver a given product.
Customer-Focused
If your company is sales-focused, as opposed to product focused, and your product is unique to each customer profile, it’s not uncommon to have teams assigned to a given customer profile. For example, you might have a team that works on Financial Sector customers vs a team that works on Manufacturing Sector customers. There may be enough specific knowledge required for a given vertical that this approach makes sense.
Technology-Focused
A set of teams is assigned to a part of the stack, such as the Front End Team, Back End Team, Analytics Team, Machine Learning Team, and so on. This model is typically used if the company is heavily engineering-focused and the skills for a specific part of the stack are most important.
Shared Teams
Regardless of your functional model, it’s very common to have shared teams that work across all other teams. For example, you might have a Platform Team that’s responsible for building shared services that all of the other teams use. DevOps is also another shared function in smaller organizations.
Your organization is likely to be a blend of these different models and will evolve and change as the company grows. Part of the engineering leader’s job is to constantly evaluate the organization structure and adjust to drive better outcomes.
Testing new ideas with small teams and experiments, just as you do with small product changes, allows the organization to continuously learn and adapt.
There is no perfect organization design, as is likely obvious by now. Instead of spending a bunch of time up front trying to get to the optimal design, clearly define the outcomes that matter and focus on getting better over time.
I’d love to hear from you. What has worked well for you, what have you learned doesn’t work? What do you wish I’d covered on this topic?