Structure the Initiative

Organization structure is a major focus of organization design. We are not tackling that entire topic here: our focus is on how to structure the teams for your initiative, product, or program. Nevertheless, many of the issues and concepts of organization design apply at the initiative level.

In the panel on the right, under Organization Design Models, we summarize the models that we use. This is not to say that these models are better than others: you should use the models and approaches that are best suited for your situation. We selected these models based on their ability to cover the aspects that we find important for agility (leadership style, organizational culture, knowledge, and personal agency). The models provide a vocabulary for discussing issues.

Designing Just Enough Organization

At the beginning of any initiative people need to figure out who is going to do what. That is how you “divide and conquer”. But people also need to synthesize their ideas, align their approaches, resolve issues that arise, keep things moving, and keep each other informed. The behaviors involved in doing this reduce to collaboration, leadership, and informing each other. It really boils down to those core behaviors. But behaviors alone are not enough: structure is needed. By “structure” we mean agreements about how and when these behaviors will be performed and by whom.

To define an initial structure, you therefore need to answer these questions:

  1. What are the main categories of work that must be performed?

  2. What are the primary ways in which we will allow the work to be done? In other words, what workflows are envisioned? For example, some choices might be,

    1. Engineers fully integration test every change they design.

    2. A separate set of test engineers will perform integration tests on a recurring basis.

    3. Some combination of 1 and 2.

  3. What skills are needed to perform the work?

  4. What are the dominant sets of issues that are expected to arise? - That is, what categories do they fall into?

  5. What styles of leadership are needed to expeditiously resolve these issues with correct decisions?

These four questions form the foundation of how to design your organization; and remember: start simple and small. Add structure only as it helps—too much structure is as much a hindrance as too little structure.

For creative work such as product development, it is important to not rigidly prescribe the workflow (number 2 above). People need agency over how they work, because what is best for one person is not necessarily best for another. Within a range, allow variation; but conceptualizing the range is important. Talk through variations and situations in which people might prefer varied approaches.

Experiment, Empower, and Observe

Do not assume that you can set up a structure and be done with it. Treat the initial structure as an experiment. Decide what kinds of leadership you need, and then identify people who have that potential. Establish what’s important to you, and then empower them to figure out how to organize their own function.

One challenge is that some of the people who you choose as leaders might be new to you, and so you do not know how they will lead. To know, you have to observe firsthand, but you also do not want to interfere, micromanage, or crimp their style. Once they have shown that they are effective and aligned with the desired cultural norms, you can step away, but until then, it is important to observe: a bad leader can have a very negative effect on a team, and it is imperative to prevent that.

One way to observe without interfering is to maintain an open environment in which you establish from the outset a behavioral norm of talking across levels. By talking to everyone on a team, you can obtain a range of viewpoints. That is not foolproof however, as people sometimes are hesitant to share negative things about someone who has a lead role.

Another way is to pitch in to do some of the actual work on the team. That might sound unusual for someone who is effectively two levels up, but it is up to you to set norms, and pitching in across levels can be seen very positively. Elon Musk is known to show up and participate with teams, including looking at code, asking questions, and starting discussions. That is “Gemba on steroids”: he obtains a very clear view of the actual work that is being done, which provides insight into what kinds of leadership are occurring (or not occurring) on the ground.

Team Topologies—Kinds of Teams

For an organization that does business through a custom or highly customized technology platform, there are usually two critical dimensions of issues that arise:

  1. The customer needs—that is, the features, capabilities, and content intended for direct customer use.

  2. The needs of the teams providing number 1. In other words, tools, components, and platforms that are shared across the teams that develop the customer-facing products.

In their seminal book Team Topologies, authors Matthew Skelton and Manuel Pais shatter the Agile myth that all teams should be autonomous and self-contained. Rather, autonomy is a goal to strive for, not an absolute to start from. They define four primary types of team, and explain how these different types of team support each other. The types are:

  • Stream-aligned team

  • Platform team

  • Enabling team

  • Complicated subsystem team

A stream-aligned team is s focused on building what the customer needs. That’s number 1 in our list above. We will call these product teams.

A platform team, on the other hand, is focused on building the components that are intended to be shared by all of the products. It is the core of the business platform, and is number 2 in our list. It is usually built on top of cloud services and other components provided by third parties. As an example, it might include a set of cloud accounts, security policies, enterprise-maintained services for deployment, a single-sign on service, and more. It might also include, for example, core microservices that are designed to provide data that is often needed by many of the organization’s products.

An enabling team is a team of experts who help other teams, and so it falls under number 2 in our list. Sometimes they are referred to as a “center of excellence”, although that term often has other meanings. The members of an enabling team spend a lot of their time staying current and trying new tools, and even more of their time helping other teams. They might help by pitching in, or help by teaching and coaching. The latter is preferred if the knowledge is transferable.

A complicated subsystem team also falls under number 2. It is a team of experts whose purpose is to build things that only they can build. They generally have knowledge that is not transferrable to non-experts. An example is a machine learning team. Another example is a group of embedded system engineers.

As Skelton and Pais say in their book, “All teams should move toward one of these four magnetic poles.” These are patterns—not templates to adhere precisely to. Every situation is unique. It is perfectly reasonable for a team to have some experts and some generalists. But these patterns are very effective and should serve as a kind of default.

The kinds of teams you have should be closely aligned with your product architecture. Most teams should be of type 1: building product features. But if there are many products that interoperate, or features that affect each other, then there probably need to be shared components. Shared components can be maintained collectively by the product teams, or a separate set of teams can be established to maintain one or more shared components. We will discuss that below.

You also need to decide what enabling teams to create, if any, and if you should create a platform team to maintain a shared common set of tools or foundational platform on which many products depend. There is no formula for doing that, but some guidance is provided below. We also recommend starting simple with regard to a platform team or a complicated subsystem team: be skeptical about the need for either of these kinds of team until the need becomes clear.

Enabling Teams

It is important to have a strategy for keeping the many teams in sync with regard to how they do their work. For example, if each team picks its own tools, then they will have a hard time working on each other’s product designs. Also, giving people tools that are all set up can empower them to do more. For example, if a team does not know how to run performance tests, then giving them a very easy to use self-service tool for running a performance test can enable them to do that on their own, rather than waiting for a separate group to run those kinds of tests. That approach also helps to standardize how it is done.

It is often the case that tools have a learning curve, and there are preferred ways of using them. Instead of defining “standards” that everyone is expected to know about and read through, it is often more effective to have a team of experts teach and coach product teams on using tools and using them in the preferred way. Netflix does that by providing a Site Reliability Engineer (SRE) to each product team, to instruct them in how to use Netflix’s tools. The SRE belongs to a team of SREs who maintain their expertise at a high level. In the taxonomy of Team Topologies, it is an enabling team.

Platform Teams

For products that are built using cloud services, the cloud services provide a rich technical platform that has most of what the developers need. However, because it is so rich, it can be used in myriad ways, potentially leading to chaos if no one is coordinating how the platform tools should be used. In addition, it is usually beneficial to centralize some things. For example, if an organization uses Amazon Web Services (AWS), the organization obtains one or more root accounts, and from each root account they create many product level administrative accounts. Those are then used by teams to create user accounts for the developers. In addition, security policy objects need to be defined within the AWS system, and that is a very complex undertaking. There is more as well: the region architecture needs to be defined, and the organization will also probably want to decide which AWS services is uses and how, since there are significant cost implications.

Centralizing all that into an infrastructure team usually makes sense - a Team Topologies platform team.

Such a team might go farther: they might even build some of their own tools. Netflix does that. So does Amazon - that is how AWS was created! But when doing that, be cautious: once you create your own tool for others to use you need to maintain it as an actual product. If you don’t maintain it well, you will become a bottleneck, and the tool will quickly become a problem.

Shared Component Teams

If there are shared components, some of them are likely to be complicated. Also, if a shared component has a defect, it affects multiple products, and so shared components are high-risk and should therefore have higher test coverage and perhaps be maintained by a smaller group of people. The goal is to preserve the ability to rapidly make changes but also manage the risk and complexity of a shared component. Shared components often suffer from cohesion “drift” - over time, they become muddled and their internal consistency degrades - they become “spaghetti code”. For that reason, shared components need more technical oversight when changes are made to them.

It is common today that organizations maintain shared core microservices that are used by many products. These services are usually off-limits to feature teams, and can only be changed by a dedicated set of teams who maintain those core services. That protects the services, but impedes agility. Making that work well requires a high level of technical collaboration between the core services team and the product teams that use the services. It comes down to technical leadership: the people who lead the design of the core services should be ever-aware of which products are using the services and how, and should make an effort to stay abreast of how others would like to use the services in the future.

identify the kinds of teams that you need: what customer feature-oriented teams (“stream aligned”) do you need? What enabling teams might help them?

Do you need a platform team? In the early days of a product, it is often best to delay differentiating between platform and customer-facing features: if you decide too early what the “platform” is, you risk spending too much effort on platform features that end up not being important. A platform is sometimes best created through refactoring later, but it depends on how clear and validated your technical vision is.

Do you need a complicated subsystem team? That is, a team of experts who need to build something only they can build? That is probably the easiest question of all: if you need such people, you probably know it.

It does not end there: the Team Topologies model is actually incomplete. There is often need for a team of experts who don’t actually build anything. An example is a legal team. Another example is a usability or product design team. Yet another example is a security team. These teams can provide coaching to a degree, to transfer some of their knowledge to stream-aligned teams, but for the most part they need to do the work themselves. However, they should operate in a collaborative way, rather than as a silo that has an input queue: nothing will slow things down more than having to wait for another group to process your requests. Instead, a group of experts should assign someone to act as a part time “extended team member” who you can contact individually as needed. Thus, they act as a kind of case manager for each team they support. Identify any teams of experts that you might need.

Organizing Many Teams

There is also the issue of how to aggregate the teams. Do you put them under an engineering manager, or do you put them under their respective customer domain?

The best structure for an organization depends on many things. Two opposing situations are:

  1. A company with a few products whose technology strongly overlaps.

  2. A large company with diverse products serving different markets.

For the first case, it makes sense to have a structure that closely mirrors the value streams. We will discuss that below. For the second case, the McKinsey Helix model might be best.

A McKinsey “Helix” Approach

A Value Stream-Oriented Approach

In a value-stream-oriented approach

A Value Stream-Oriented Approach

What to Do: Design Your Own Approach

Setting up teams is not easy. Our advice is to start small and simple, but always be thinking forward. The sub-steps at the top of the right panel walk you through the journey of creating teams and supporting structures. This is not something that is “cookbook”, and that is why we view these steps as an experiment in which you are learning and adjusting.

It might be necessary to mix-and-match the team patterns that we have discussed, so that, for example, some initiatives or products use one approach, and other initiatives or products use another approach. Or, some elements of each approach might be combined: for example, one might create some teams that are owned by a product manager, but have some additional teams that are provided by a capability manager. The latter might be, for example, for surge needs. Or there might be some teams that support certain internal products or core platforms that are used by multiple product areas. See Team Toplogies in the right panel.

Sub-Steps

These steps guide you through setting up teams. View this as an experiment, in which you are always observing, measuring, and adjusting.

  1. Define the key capabilities that are to be developed initially, to attain a minimum viable product to test with users. Remember that this should remain fluid.

  2. Define the value streams that are needed. Be cognizant of internal product value streams that converge on multiple customer-facing products.

  3. Identify external partners that will contribute to the value streams.

  4. Identify outcome-oriented metrics (OKRs) that indicate the effectiveness of each of the capabilities, as well as the minimum overall product.

  5. Decide on Team Structures, including teams of teams, and horizontal structures.

  6. Identify the kinds of leadership each team or structure will need.

  7. Identify people who are good candidates for those leadership kinds. Do not define fixed roles to fill: remember that people define their own role. Instead, think if terms of who can provide the types of leadership that you need. Some people can provide a mixture.

  8. Decide on an approach for observing the leadership style that is being used by each individual.

  9. Identify the shared accountability that is needed for each capability, spanning the teams and organizational structures. Identify also final decision-makers for each important capability.

Important Cross-Team Leadership Roles

Key Role: Transformation Leader

Key Role: Agility Change Agent (formerly Agile Coach)

Case Study: BBC WebCore

People-First

Define a people function that is strategic. See Engineer the Knowledge.

Agile PeopleOps Framework

Organization Design Models

Team Topologies

Value Stream Structure

McKinsey Helix Model