How to design an organisation and its teams?

In the fast-paced arena of business, crafting a winning organisational and team design is more akin to composing a symphony than following a rigid blueprint. It is definitely not a one shot activity. Don’t try to get all the details right. Rather, create a good enough starting point from which you can evolve. An agile mindset will prove most valuable.

In this exploration, we delve into the intricate dance of factors shaping effective organisational and team design, unearthing hidden gems that can redefine success.

General considerations

Strategy

The organisational design should support the strategy. Depending on the chosen strategy (Product leadership, Customer intimacy, Operational excellence – cfr Treacy & Wiersema), different trade-offs need to be made.

Culture & Maturity

A design that works for a smaller organisation that has been experimenting with autonomous teams might not be suitable for a large multinational that has mostly operated in a more traditional, hierarchical way. Organisations, like individuals, go through stages of maturity.

As an example, the ‘Spotify model’ seems to have a somewhat higher overhead. It worked very well for Spotify, because they had to support their growth. And for their growth, they needed to attract lots of junior profiles. It also worked because at that time, the organisation was not too large. When trying to copy this model, you need to take this context in consideration.

The organisational design should grow along with the organisation. Creating too big of a disruption might result in too many people being lost, which might cause significant damage to deliver value. Aligning the team design with the existing culture can enhance cohesion and efficiency. We don’t want to say you can’t be ambitious. Just take into account we are dealing with people here, not machines. If a more radical change is required, approach this in smaller steps, so the organisation can evolve more smoothly. Creating a scalable structure as a starting point offers a clear advantage in this perspective.

Nature of the work

The nature of the work also impacts how you can set-up your organisation. Running a 5-shift operations in a manufacturing site is a different endeavor than designing a new operating system, which is yet completely different than running a University.

Buurtzorg – founded by Jos de Brink – is one of the flattest organisations one can imagine: teams operate autonomously. They providing care at home to elderly individuals, people with disabilities, and chronically ill individuals. They strive to combine personal care and efficiency. Using their organisational model as a footprint might not work that well when you are trying to develop an electric car.

Span of Control & size of a team

Amazon’s Pizza Rule, suggesting that if a team cannot be fed with two pizzas (> 6 persons), it’s too large, is a myth. While team size is important, it’s not a one-size-fits-all rule. Several organisation have been successful with rather small teams (6 or less). That said, many others struggle because such small teams often imply more hand-overs and dependencies. Within Scrum, the recommended team size is 10 or less. The reason is that the number of communication channels increases exponentially with size. That said, there are enough examples of large teams (15 – 30 team members) that have been very successful., probably because they had all the skills within a team. Factors such as complexity and interdependence play a role in determining the optimal team size.

The span of control refers to the number of subordinates a manager oversees. Striking the right balance is crucial. A manager with a manageable span can focus on individual employee growth, providing mentorship, guidance, and tailored opportunities for development.

Geographic distribution

A company that operates globally might benefit from regional hubs. This is a common strategy for manufacturers. Supporting teams across the globe in their operational excellence efforts is hard to manage from headquarters alone. The reason is time zones and the amount of travel required. In such a context, remote tools are just one part of the equation and physical presence remains a necessity.

Managing both the build & run dimension

An organisation needs to balance routine operations (run) and improvement/innovation. If teams are responsible for both activities, mechanisms need to be put in place to prevent that the urgence of daily operations always wins from long-term initiatives.

In a DevOps team, this is achieved through the fact that good code simplifies the life of the team. In larger organisations, the simpler option is to dedicate a team to the upstream development work, without any operational responsibilities.

A more extreme version to foster a culture of intrapreneurship can be achieved by incorporating innovation pods within the organisation. A famous example is ‘Skunk works’.

Customer Focus & responsiveness

Organisational and team design should revolve around delivering value to the customer. Teams need to act on customer needs without navigating a complex organisation to make a simple decision.

More in general, everyone in the organisation should have opportunities to get in dialogue with customers so to improve the service they deliver.

Decouple product groups

Organisations that have coupled product groups (tightly intertwined systems, processes, and policies) tend to struggle to adapt to evolving contexts.. Loser coupling enables an easier exploration of alternative options and easier decisions to pivot. Additionally, it reduces switching costs.

Coupling of products within the same product group should be tight. This allows for operational efficiencies.

Flow

Efficient flow within a team involves managing hand-overs, dependencies, and effectively dealing with priority calls. Less hand-overs increases flow. A swim-lane diagram is a great tool to visualise hand-overs.

The best teams check how they can effectively reduced dependencies.

A streamlined flow minimises bottlenecks and ensures that the team operates smoothly. End-to-end process teams (aka stream-aligned teams) are the ideal state. An additional benefit is that such a structure creates a very transparent cost structure, reducing the complexity of cost allocation.

In the pursuit of flow, inevitably, there will be a trade-off with resource utilisation, i.e. high resource utilisation will result in lower flow and vice versa. Both Agile and Lean acknowledge that the indirect cost of delays mostly exceeds the cost of the labour ‘inefficiency’. Therefore, they both recommend to design for flow efficiency first, and then improve resource efficiency while maintaining flow.

Learning organisation

Creating a ‘learning organisation‘ is a vital for organisations to remain competitive and to enable junior people to master their profession. Teams that share knowledge and experiences are better equipped to adapt to changes and challenges.

Learning is the reason why most traditional organisations group people in functional silos. Within these silos, team members do similar work. This creates more resilience in case someone is not available (due to holidays or illness, for example).

It is important to establish mechanisms for knowledge transfer. This could be on-the-job training, pair programming, Communities of Excellence, internal ‘Universities’.

Fluid structures

According to ‘The Liberators‘, there is no scientific evidence whether stable teams are better or worse than fluid teams. The fact is that every change in a team (a new member or someone leaving) will impact the dynamics.

In general, there seem to be 2 approaches:

In a project organisation, team members flow to projects to create temporary teams.
In product organisations, new features flow to stable teams.

Simplicity

When faced with multiple options, one should choose the simplest / least complex organisational design. (Simplicity Axiom). The reason is that simpler processes and systems are more manageable and easier to navigate.

Specific considerations

These considerations do not apply for every organisation

Conway’s Law

Conway’s Law states that the design of a system reflects the communication structure of the organisation that produced it. Understanding this law can help in designing teams that result in a better architecture and design of software products.

X as a Service

Adopting an ‘X as a Service’ model involves providing services on-demand. This approach requires a high investment. Once achieved, it enhances flexibility and responsiveness, contributing to a more dynamic organisational structure. And it is easily scalable.

Strategic Partnerships

Explore the potential for strategic partnerships within your team design. Collaborations with external entities can bring in fresh perspectives, resources, and opportunities for growth. This is the basis for ‘Open innovation’ in which one connects with external parties to outsource part of the innovation.

Conclusion

Organisational and team design is a nuanced process that requires a comprehensive understanding of various factors. By embracing a dynamic nature of business and adapting team designs accordingly, one can ensure that the organisation remains agile and resilient in the face of ever-evolving challenges.