All too often, one of the first things a new leader does is alter her or his organization’s structure. To many, org charts and “moving boxes around” seems to be the main (if not the only) thing senior leaders do. Does it matter or is it just one of these vanity activities? What does success look like? How should one approach this seemingly “high stakes” task?

There are many philosophies around structuring teams, and it would be arrogant of me to put forth one as an absolute truth. There are many reasonable approaches, each optimizing for a different facet of an organization. Many of these focus on what is good for the business, but there are some that don’t – for example, some changes are driven by the politics or animosities/alliances in the organization. In my career I’ve tried to shy away from companies that focus on these dynamics at the expense of the “greater good” of the organization. It is important, though, to highlight that purely “selfless” decisions are exceedingly rare, so take the below with a small grain of salt.

Why does structure matter?

It is often said that “an organization ships its org chart.” It’s a deep insight that may seem obscure at first. All it means is that team structure deeply affects not just how an organization does the work, but also what work it delivers through the incentives and dynamics implicit in a particular structure. For example, a highly siloed organization will deliver a product whose implementation may be technically correct, but miss the goal. A highly vertical organization will deliver a disjointed product, with one offering seeming detached from others. An organization dominated by engineering may deliver a scalable solution that doesn’t solve a user’s problem; one where engineering doesn’t have enough of a say may evolve too slowly, burdened by tech debt; one that is driven by business stakeholders may offer an inferior customer experience at the expense of early monetization. It helps to be aware of this bias and course correct accordingly.

Hence, structure matters since it has real implications on the product and the offering. Just like almost anything in life, structure comes with trade-offs. Individuals brought more closely together work better and ensure fewer issues between them – but too much forced synchronicity slows teams down. Hierarchies between functions translate to certain aspects of the offering being more important than others. Someone has to manage the team, and their goals and objectives translate into what the group emphasizes and de-emphasizes.

A skilled leader is able to understand her or his organization and the company’s goals well enough to come up with a structure that magnifies the desired effects and downplays those to avoid.

The Principles

Structuring teams is highly dependent on the nature of the business, the near- and long-term objectives, the composition and abilities of the team, the team culture, and leader’s strengths and weaknesses, and many other factors. However, rather than throw our hands in the air, we can identify some principles that, when applied to team structure, are likely to yield positive results. In my experience these principles are:

1. There is no single “correct” structure for all organizations. Moreover, what is considered the “best” structure for a given organization may change over time, and – to throw an even bigger wrench – for a given organization at a certain point of time, there may not even be a single “best, right now” structure.

2. Team structure may need to change even if it hasn’t “failed” in any way. As a result, it’s much healthier to create a culture where change is good and “re-org” isn’t considered a taboo/dirty word, than to consider structure changes an indication of some sort of failure, or blame of the leaders in the old structure.

One organization I’ve been in made it a big deal to shift from a functional/silo structure to a vertical one. The shift was, by most measures, successful – key problems were addressed without significant new frictions created. Two years later, the company’s leadership team felt that we’ve reached a plateau that could most effectively be addressed by shifting to a functional structure; however, they dragged their feet because they felt that going back to the previous structure would be construed as a “failure”. This hesitation was misplaced – there was a time and place for a vertical structure, but relatively quickly this structure outlived its usefulness. After a short period of feeling apologetic, the leadership ended up celebrating its nimbleness and the fact that they sought the right answer that was free of misconceptions and biases.

3. Design for desired capabilities. What do you want the organization to be particularly well-equipped to do by the virtue of its structure? Does it need to ship fast? Does it need to be nimble? Does it need to work well across functions, or maybe offerings? Does it need to manage dependencies well, or is low defect rate critical? If more than one capability is needed, realize that the resulting structure will likely need to diffuse its energy. In brief, there usually is no free lunch.

4. Consider the faultlines. Given an org structure, what are its weak spots? For example, a structure that’s highly siloed will likely find it difficult to pick up learnings across silos. Most often, you shouldn’t design around faultlines – structuring teams for absence of weaknesses often results in teams which are all-around mediocre. But you can be aware of where they are and pay attention to them, building in safety nets and mitigations. However, be aware of the hidden costs of these mitigations. It’s all too easy to convince yourself that you’ve built in a perfect protection against a faultline, only to realize that the protection itself has deprived the structure from its superpowers. For example, often, a structure that ships fast struggles to deliver in an environment full of dependencies. You can “solve” for this faultline by carefully managing dependencies, but it may well slow the team down to the point where this capability is lost.

5. Focus on results, not clean charts. Often, leaders are tempted to choose an org structure that is easy to describe on a slide. The boxes are clean, the lines and relationships sparse. In reality, human organizations are messy and don’t fall cleanly into structures. You need to build redundancy, account for defects and variance in output. The “simplest-looking” structure is often hardest to adopt. To make matters worse, org structures are path-dependent: teams bring their biases, scars and institutional memory into a theoretical structure and the resulting “real-life” organization will behave differently than it was intended. Instead of coming up with the most efficient-looking structure, consider establishing one that generates the most desirable results.

6. Don’t prematurely optimize for standards. Somewhat related to the previous principle, leaders constrain themselves by designing highly standardized organizations – a handful of teams, all following the same template, defining the same roles and responsibilities. If one squints hard enough, it’s possible to convince oneself that such a template exists, but in reality, a forced standard neuters many of the capabilities unique to a team. True, standards make management easier, but early on, it’s better to get an early “organization-capability fit” and worry about simplifying when teams are delivering on their commitments.

The Mechanics

How should one go about defining a team structure? The steps are fairly straightforward, though in my experience, many leaders jump to a specific solution before they fully understand what they are designing for and what issues they might run into. Let’s spell out some of these commonly-skipped steps.

• Learn from the existing structure, and (to some extent) from history. Why did the organization end up structured the way it is? Was it in response to some problem or opportunity? Has it been properly diagnosed/analyzed? Has the structure worked for what it was intended for? What’s working and what’s not working now? Furthermore – what was the structure before then? (A common pattern is to “go back” to a previous structure with hopes of that solving some problems, but companies and their circumstances are always changing so hoping to go back to something that used to work may no longer be a viable option).

• Identify the desired capabilities and success criteria. What are we solving for? Failure to think through this step often results in superfluous org changes – the leader gets to boast about how they restructured the team, but the impact of the change is unclear or negligible. As I mentioned before, it’s best to solve for what’s needed as opposed for the absence of what’s to be avoided.

• Identify the faultlines and methods to detect issues. Once you have a thesis around a structure that might create the capabilities you want, analyze your design for structural weaknesses. Where might communication or information sharing break down? Where are the bottlenecks? You might not be able to solve these issues without impacting your capabilities, so in the very least think about how you might discover when an issue occurs. Yes, organizations require constant vigilance!

• Define the team charters (mission, vision, objectives, results). It’s tempting to assume that everyone knows what a particular team’s role is just by looking at its name. But more often than not, terms are heavily overloaded and often mean very different things to different people. What does a Platform team do? Does it build technical infrastructure? Does it build the scaffolding for all services? Does it build specific services that are supposed to be reused across the company? It’s not so obvious. The charter should include the following:

  • Mission: Put simply, what are you here to accomplish?
  • Vision: Where do you want to end up? What is the north star? In what way do you want to alter the world?
  • Objectives: What will you seek to do? How will you know when you’ve succeeded? What does progress look like?
  • Results: What are quantifiable outcomes you want to see to convince yourself that you’re hitting your objectives?

   

• Define the team promises and interfaces. It’s easy to think of teams in isolation, but most teams have to interface with other teams to be effective. For each team, what does it promise to other teams, and what teams does it interface with – and what does it require from these teams?

• Define the team member roles and responsibilities. This is where most people land, but if you do all the above work, the roles and responsibilities flow pretty naturally from the setup. Think of the desired, viable roles and responsibilities – your team may not yet possess all of them, and over time it may grow to be more than what you specify, but if you had to describe a reasonable team that should be able to meet its objectives, what would it be?

• Document everything. Less of a step and more of a guiding principle. Too often to leaders make leaps in their head and arrive at a resultant structure, without much documentation/justification. This makes it difficult to assess how well the team structure works – it’s hard to do root cause diagnosis. It’s time-consuming, but documenting the team charters, interfaces, roles and responsibilities creates clarity which is so needed early in the team’s existence.

• Try the structure out – and iterate! No plan survives first contact with reality. Set a norm that these structure will evolve and that changes are not just inevitable, but welcome. Then monitor how the team is doing and be prepared to continuously improve the design until you hit a plateau. Many leaders feel a sense of ownership of the structure they advocated for, and they avoid the hard truth when the team structure doesn’t quite meet its expectations. Instead, they should openly point out the gaps and design solutions around them.

An Aside: Why Matrix structure are dangerous

I believe that one of the most common mistakes leaders make is adopting matrix structure solely because, in their view, they are “the best of both worlds”. Instead, I think they are complex, finicky, and fraught with second-order consequences. What they supposedly give you in added flexibility, they make you pay for in management burden, lack of clarity and propensity for confusion.

What are matrix structures? Most traditional structures define a single line of accountability. For example, in a horizontal structure, the team members (e.g. QA engineers) are accountable to the functional leader (e.g. the QA leader) who sets the goals and evaluates the team members’ performance. The downside of these single-line structures is that it’s difficult to account for other constituents. In our example, the QA engineers may be incentivized to build great QA frameworks, but they don’t feel as accountable to the business unit which needs the work done. Many structures define “dotted lines” as a way of signaling that these other constituents’ objectives matter, and matrix structures take this concept to its logical conclusion. They purport to solve the multi-constituent problem by creating dual accountability: in our example, both to the functional QA leader and to the business unit leader. A shorthand for matrix structures is a table with one line of accountability represented with row headers, and the other with column headers. A particular team member, represented by a cell in the middle, is therefore dual-accountable.

Many engineers-turned-managers love matrix structures. They seem to be the technocratic solution to a hairy human problem. Why can’t we have it both ways? The reality is that matrix structures gloss over the real complexities arising from having dual accountability. They push the burden of having to tie-break conflicting goals to the individual contributors; they give each of the two constituents partial information about the person’s contributions, thus creating an opening for things slipping through cracks (one leader assuming the other leader is auditing the outcome; both leaders putting too much on a person’s plate, etc.). They create confusion around performance management (what if one leader thinks the individual’s performance is stellar and the other thinks it’s subpar?).

Granted, matrix structures are not universally bad; with carefully designed and maintained “organization infrastructure” and constituents and individuals who are used to being a part of the metrics, they can work very well. But just like a professional camera they often result in worse outcomes in the hands of those who aren’t experts.

Real-life Team Structures

With that out of the way, what are some common team structures? Remember that structures should be chosen to solve the key challenge (or seize the key opportunity) in the organization so there is no “right” answer (and each option has its drawbacks), but there are structures which are commonly seen in organizations, and it may be helpful for you to try some of them on for size to see if they work in your circumstance.

• Functional (horizontal) split is a common way to organize teams. Simply put, team members who perform a particular function (e.g. software engineers, QA engineers, project managers, data engineers) are all grouped together. This structure has many advantages – the leader of such a team is able to help their team members grow their skillset; the team has a common vocabulary and team members can often support/stand in for one another (e.g. in case someone is sick). There is deep sharing of context relevant to each person’s specialty. But it also suffers from excessive siloing – team members focusing too much on their craft and not enough on the business goals; too many dependencies across teams, especially for complex projects that need to bring together many functions, which tend to slow down delivery.

• As a special case of the above: Frontend / Backend is widely used split for engineering teams. In addition to optimizing for growth and skill-building, this division often follows the natural system boundaries – e.g. for web-based systems, between the Web frontend and backend services. This creates a simple interface which any frontend or backend engineer has experienced regardless of team structure. I’ve seen this structure work well at low scale; when the respective teams grow, there is a drive for each team to further specialize (e.g. the frontend team starts developing custom frontend frameworks; the backend team builds generic scaffolding for services), often because they spend a lot more time surrounded by their own functional problems, and not enough time surrounded by the business problems they are solving.

• Vertical split is the converse – a way to organize teams regardless of function, so that everyone working on a specific goal is a part of the same team. Vertical teams are hyper-optimized around the business goal – the whole team works on the same objective, and gets to celebrate when it’s complete. If a new function is needed, it can just be added to the team, instead of the organization needing to build out a brand new team representing this function. The obvious downsides include potential underuse of some functional representatives (since a vertical team needs a least one full-time member for each function it requires), much less functional management support (one manager can’t offer as much contentful mentorship to members of multiple different functions), and less redundancy should, say, one functional representative be unavaialable.

• Frontier / Scale teams are an intriguing way to structure based on the nature of the work being done. Frontier teams build first versions of the software, often hitting dead ends and scapping the work they did. Scale teams come in after the work has been proven out and when it’s time to scale it out. Note that the scale teams don’t just “clean up” tech debt-ridden code. They rewrite existing systems to account for new non-functional requirements that often come with scale. It may seem that frontier teams do more exciting work, but they often need to get to “good enough” and frequently have to abandon their project. Similarly, scale teams can plan their solutions better since the requirements are known and there is less pressure to be “in the market”. The benefit of such a split is that it speaks to the innate abilities of the team members – for example, some engineers love tinkering and getting features out while others like to build software that lasts. The downside of this structure is that it often devolves to the frontier teams writing sloppy code, and the scale teams over-engineering the solutions!

• Variant: Experimental / Stable teams. A special case of the above is a structure where some teams are tasked with running experiments, whereas others create stability. Not every “frontier” initiative has to be an experiment, but if we further narrow the definitions, the experimental teams are even more specialized, able to think of their work in terms of A/B tests, and having internalized the fact that most of the work they will do will be thrown away.

• Plaform / Product teams. Another common structure looks at who the stakeholder is. Product teams see the business stakeholders are their stakeholders (they essentially build technology for the business users and the customers), while platform teams see other engineering teams are their stakeholders (they build technology for other teams). Most companies have some sort of a platform team, even if they have adopted a different organizational style overall. The benefit is better specialization – some engineers are just drawn to platform-like projects, while others love to build software for people to use. The downside are dependencies and prioritization difficulty – the platform team often has no way to assessing what’s more important than what. Moreover, while the platform teams think of other teams are their stakeholders, in reality the business owners are the stakeholders, directly for product teams and indirector for platform teams. Platform teams often forget that and they end up not building the software that the product teams need.

A useful exercise is to ask yourself: for a given actual organizational structure, what would happen (good and bad) if you changed it to one of above? You will quickly see that the challenges are rarely technical in nature; instead, it’s the people you need to contend with!

Closing

Let’s go back to the question posted at the start: does team structure matter? Yes, but not in a way that many leaders see it. There are team structures that are more suited to certain goals; and there are real downsides to structuring teams in certain ways. We saw, specifically, that matrix structures are often overkill for what the teams are trying to do – their “second order downsides” outweigh the potential benefits. The key insight is to design your team in a way that speaks to the actual challenges or opportunities, focus on creating capabilities rather than avoiding problems, and be explicit about each team’s mission, objectives, interfaces, and responsibilities.

Most importantly, don’t assume that your design will be right and will last forever – be open to iterating on the team structure, and create a culture where structure changes (when reasonably executed) are welcome as a way to solve the evolving challenges the company is facing.