Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Why your team design is slowing your business down - and what to do about it

If you’ve seen a small piece of work take too long because it required input from  multiple teams, or if someone’s told you they don’t have the authority to run with an initiative, you have a problem.

 

And it’s not with your people. You can have even the very best talent with strong capabilities and skills, but, as pioneering management consultant Dr William Edwards Deming said, “a bad system will defeat a good person, every time.”

 

Dysfunctional team design is a common issue – something we see across many organizations we work with here at Thoughtworks. By applying a simplified operating model that aligns work to goals and customers, along with the Team Topologies principles developed by IT consultants Matthew Skelton and Manuel Pais, you can evolve your organizational team design into an agile system fit for the fast-paced digital world.

 

Here’s how.

 

 

Recognizing the need for change

 

The most common red flag that signals a dysfunctional team structure is when teams are working in silos and, as a result, optimizing for their own goals instead of the broader business priorities. For example, the tech team might be focused on improving a UX function only to find the marketing team has been focusing on an entirely different product launch with conflicting OKRs. Instead of aligning priorities, we often see one of the projects shelved, wasting immense effort. Alternatively, both teams work around the clock to make both initiatives happen, potentially leading to burnout and eventually talent attrition. The quality of work can also suffer. 

 

This inefficiency can take a very human toll. Both teams feel an increased cognitive load. Frustration over changing priorities, or a lack of connection to the purpose of their work, can lead to talent leaving the organization. 

 

Research shows siloed team structures can have a detrimental impact on customer outcomes, innovation, effectiveness, performance — and ultimately, profitability. We know collaboration requires teams to work together, with a common vision and collective goals. So why do most organizational structures make this so hard?

 

What’s even worse is when different teams adopt a range of potentially conflicting structures. One team may be using SAFe (Scaled Agile Framework), while others are playing with a Spotify-style squad variant and a few are sticking with a traditional project model. 

 

The truth is, there is no ideal ‘best practice’ team structure. It needs to be fit for your purpose – not one you’ve copied from another organization. 

 

Ultimately, the catalyst for change will arise when the organization decides it’s time to design for customer needs first. That means moving from a project mindset, focused on time, budgets and outputs, to a product mindset – which instead focuses on outcomes. 

 

You’ll then need to optimize your organizational design for value — not just break down the work and hand it over to teams. 

 

 

Flipping your thinking with a Simplified Operating Model

When Thoughtworks first looks at the work being done in an organization, and how it aligns with business goals and customer needs, we commonly observe an antipattern: the team structure and skills of its members tend to dictate how tasks are allocated. This means priorities depend on what’s possible with the available people and time. It’s a clear case of the tail wagging the dog.

 

To be effective, customer needs should instead determine the measures of progress and work required, as this diagram shows. Only then can the job of team design begin. The work that is prioritized should determine the skills needed, and the skills needed should determine the teams.

 

Learn more about the Simplified Operating Model

 

Left: The Thoughtworks Simplified Operating Model starts with the customer. Organizations optimize their operating models to maximize the value they create for customers, rather than designing work based on what their teams can do, and what they want to achieve for the business. Each element builds its own momentum, and allows work to cascade through.

Applying Team Topologies practices

 

According to Conway’s Law, “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” In other words, how your company is structured (its hierarchy and teams) will determine how work is allocated and executed. 

 

Skelton and Pais applied this thinking in Team Topologies, their approach to organizing business and technology teams for fast flow. It outlines four fundamental types of teams:

 

  • Stream-aligned teams focused on delivering defined value for a stream of work
  • Enabling teams that help close capability gaps and promote learning across teams, such as a DevOps Center of Excellence
  • Platform teams that provide shared services to increase reusability and reliability
  • Complicated sub-system teams, usually needed for specialized knowledge or niche work

 

As we’re focusing here on the shift to a Simplified Operating Model that starts with customer needs (i.e. value) we’ll now look more deeply into how you should structure stream-aligned teams. 

 

 

Designing teams around a value stream 

 

Value-stream mapping is a lean technique that helps you understand value from your customer’s perspective and figure out how to deliver it. It’s broader than customer journey mapping, as it also takes into consideration the steps which aren’t part of the direct customer experience but still essential to the process (such as corporate finance or marketing).

 

This approach can help you design teams around capabilities rather than hierarchy. Once you identify the core value stream, you can assess what else you need to make the work happen effectively. This includes things like the processes involved, and how teams can support the value stream work through shared services or specialized knowledge. In other words, as with our Simplified Operating Model, you design the teams around the work — and the work determines the skills that are required.

 

Let’s say you are building an ecommerce website. One value stream could focus on increasing customer awareness. What will you do to attract customers? Which teams and individuals will be involved to do so successfully? Then, what output will take you to the next step: how will you provide more information or value-add so that you can convert leads into orders? Here’s how we might map this value stream.

Value stream mapping example for building an ecommerce website. One value stream could focus on increasing customer awareness. What will you do to attract customers? Perhaps run marketing campaigns, add affiliate marketing, provide in-app adverts, build brand awareness. Secondly, identify which teams and individuals will be involved to make that successful? Perhaps the Marketing team. web page development team, content team, brand team. Then, what output will take you to the next step: how will you provide more information or value-add so that you can convert leads into orders?
Value stream mapping example for building an ecommerce website. One value stream could focus on increasing customer awareness. What will you do to attract customers? Perhaps run marketing campaigns, add affiliate marketing, provide in-app adverts, build brand awareness. Secondly, identify which teams and individuals will be involved to make that successful? Perhaps the Marketing team. web page development team, content team, brand team. Then, what output will take you to the next step: how will you provide more information or value-add so that you can convert leads into orders?

Agreeing on your team design principles

 

As your organization evolves, so will your team designs. They aren’t set in stone.

 

In Team Topologies, Skelton and Pais describe this work as gardening, not bricklaying. As the seasons change, you add some new crops or plants. Sometimes you need to weed; other times you need to add fertilizer. Similarly, as people change across the organization — as your culture and practices evolve, and as the external environment shifts — so too will the design of your teams. 

 

To ensure you create a sustainable team design framework, you will need guiding principles. Here are a few examples we have seen work within different organizations:

 

  • Empower teams to own the problem, and work on vertical slices from top to bottom

  • Customer trust is primary

  • Innovation through experimentation

  • Long-living teams

  • Teams that have the capacity and capabilities to deliver, independent of other teams.

 

 

Embedding agile team habits from within

 

Creating an agile team design framework is an ongoing process of change and adaptation – not a one-time transformation. However, once you build these practices you will start seeing benefits.

 

By focusing first on the thinnest slice of change you can make for one value stream, you can experiment. For example, with our ecommerce initiative you could identify one containable but significant ‘slice’ of customer awareness activity, like partnering with a social influencer to provide customer guidance. In this case, you would then need to bring in content, product and PR teams to ensure you have the right skills to achieve the outcome. 

 

When we see our clients design their teams around value streams, they typically end up with value-aligned teams who own initiatives end to end. They can execute effectively without interrupting the priorities of other value-aligned teams.

 

By following these practices, you can design a team model to suit your organization’s purpose, culture, and goals, and adapt to ongoing change. Ultimately, you can identify where value lies — once you do that, you can then align the work of your teams with what matters most to your customers. 

 

To learn more about Thoughtworks Organizational Team Structure practices and workshops, please get in touch. 

 

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Keep up to date with our latest insights