When Scaling Your Team, You Pick Your Silos

I think we all know there is no One True Way to structure a product development organization. I've experienced and created several in my career, and I know there are many more variations I've never experienced.  There are two common options I want to explore here.

The Functional Hierarchy

When your team grows beyond the point where all developers can report to a single manager, a functionally-structured organization will often create groups based on layers of the tech stack--front-end, back-end, persistence, etc.  If the team is sufficiently specialized, you might see an architecture team or a data science team. Even without groupings based on technology specialties, a functional organization will at some point need to put in place layers of management so that individual leaders are not overwhelmed by the number of direct reports they must manage.

The QA, Product and TechOps organizations will grow similarly, but separately. They may be partitioned based on specialization (for example QA automation vs. white-box testing, sysadmins vs. devops engineers), but in a strictly functional organization, these teams will need to add hierarchical layers to accommodate scale.

The advantage of a functionally-organized structure is that managers are generally responsible for the functional areas where they have the most expertise.  Also, since teams are organized into areas of specialization, functional expertise can be developed and honed.  It is probably true that functionally-organized teams are more likely to be consistent in their approach, and this is reflected in consistency of the work product. 

The drawback of functionally-organized teams is that each of the functional hierarchies is insulated from the others.  Cross-functional collaboration is less natural than in a structure that forces this organically. You must add touch points  between functions to allow effective collaboration independent of the organizational structure--it doesn't come "for free" as a side-effect of the way the team is organized.  Matrixed organizations often arise as a way to introduce some form of structure across the primary functional axis.  The matrixed team is comprised of representatives from each function, but this team is focused on a particular product or project. While this approach represents a workable compromise, it sometimes leads to tension when the objectives of the matrixed team are in conflict with the objectives of the functional team.

The Product-Oriented Organization

Product-oriented organizations choose to address scale by deconstructing the product into meaningful units and creating cross-functional teams around those units.  The teams might follow product SKUs, or the product might naturally break down into areas with sufficient gravity to warrant a separate team (and typically, a separate Product Manager).  It's important to avoid structural complexity within product-oriented teams, so you need to look for ways to keep the teams reasonably sized and intelligently organized.  

The advantage of product-oriented teams is that they contain all the components necessary to build a product.  They can act autonomously and make quick decisions about their work.  They can be focused as a unit on the customer and the product, and collaboration comes naturally.  It is probably true that product-oriented teams are able to innovate more quickly and be more customer-focused than functionally organized teams.

The drawback of teams organized this way is that they might not benefit from best practices in functional areas that exist in other teams. There may be inconsistencies between product teams, and product teams are more subject to resource constraints when bottlenecks exist in a particular function. If consistency across products is important, you must expend extra effort to create this consistency since it doesn't come naturally as a result of the organization.  If dependencies exist across products, then you must put in place a process such as a scrum of scrums to coordinate the teams' efforts.  There may also be a need for a "best practices team" that makes sure functional areas within product teams are cross-trained with similar functions on other teams.

Tradeoffs and Preferences

Neither functional hierarchies nor product-oriented teams solve all organizational problems. Each approach has advantages and drawbacks, as do the many variations on these two models. Hybrid approaches like the matrix model attempt to address the shortcomings of a pure functional hierarchy, but these aren't immune to tensions and challenges (e.g. the classic "two masters" problem).

All in all, I prefer product-oriented teams over functional hierarchies.  Because product-teams put the emphasis on the product and customer, I think the resulting product reflects this focus. I would rather suffer the inconsistent application of technology across products than technically sound but inaccurately targeted functionality. Also, I think small product-oriented teams, when properly empowered, are able to innovate and deliver value faster than organizations that must negotiate across functional silos.

One last factor that contributes to my preference is the creation of leadership roles within the organization.  With a functional hierarchy, leadership roles are created in the functional groups only when they scale to an appropriate size that warrants an extra layer of management.  It is rare to add new functional verticals once the organization is fully realized, so new leadership opportunities don't tend to appear frequently with the creation of new hierarchies.  In a product-oriented organization, it is easy to spawn new products and product teams as the organization and product offering grows. Each product team is fully formed, so new opportunities for leadership are created across all functions as new teams spin up. This is an important consideration--especially in an organization with ambitious employees looking for leadership opportunities.

You Create Your Own Silos

No matter what organizational model you choose, you should accept the fact that you are in a sense creating silos. You might be creating functional silos, or you might be creating product silos.  You must be aware of the tradeoffs and shortcomings of the approach you choose, and put in place process to offset that which does not come naturally as an attribute of the organizational model. Choose wisely and be prepared to adapt--any organization must change as it matures and grows.