The Continuous Organisation Design Playbook
The way we design modern organisations for agile delivery is akin to Football in the 1800s. Little strategy, but lots of mindless running around copying everyone else.
Over the past year, I’ve been invited to multiple organisations who were “doing the Spotify model”. When I asked one of them why, they were “not quite sure. I think it was one of the new executives who mandated it”.
Modern day football has evolved into highly-strategic gameplay. Managers look at their players and opponents, then choose the most effective style and formation, and adapt as the game unfolds.
Back in the world of agile organisation design, all we appear to have is… “Let’s do the Spotify model”.
In this post, I’m going to introduce you to some of the context-specific continuous organisation design strategies you can use to optimise for your business’ and customers’ needs, and the troubles you may run into if you don’t.
If you like this post and want to learn more, I’ll be talking about all of the topics in more detail at Lean Kanban France in Paris on the 29th November. I’d love to see you there.
Why Designing Organisations is Hard: Dependencies
One of the reasons we like to copy fashionable trends like the Spotify model is because designing organisations for agility feels impossible. There are so many factors to consider, it’s easy to just bury our heads in the sand and copy someone else.
Modern organisations need to move fast, continuously getting feedback from customers to fuel disruptive and sustaining innovation by practicing continuous discovery and delivery.
But there’s a problem — dependencies. Teams must collaborate and integrate their systems to deliver full service experiences to customers.
When designing organisations, dependencies and the resulting handovers are the biggest challenge. Handovers are where teams get blocked, where politics arise, where technical integrations need careful management, and where user experience can become fractured.
How we design boundaries and dependencies affects how innovative we can be, how rapidly we can deliver, how efficient our teams are, how motivated our people are, and how consistent our user experience is.
In constantly evolving competitive markets, customer needs are always changing. Organisations must continuously adapt.
Instead of running around copying Spotify, it’s time we started taking a more scientific and strategic approach to designing organisations.
Strategic Plays — Sociotechnical Architecture Patterns
A fundamental principle of designing digital organisations is recognition of the interdependence between people and technology.
When we change team boundaries and responsibilities, we must also re-align technical boundaries and responsibilities to avoid unexpected dependencies, and vice-versa.
As a result, organisation design is a sociotechnical activity. We cannot think about the organisation of people or the organisation of software systems in isolation. They are symbiotic.
Building Blocks
Our building blocks for organisation design are not teams or software components, they are sociotechnical contexts — boundaries that encapsulate a team, software components, and a specific responsibility.
We can align our sociotechnical contexts with a variety of existing constructs including user journeys, business processes, and products.
What we are trying to achieve drives the building blocks we choose. And what we are trying to achieve changes over time, so our design must evolve accordingly. The choice of building blocks is context-specific.
To learn more about the building blocks, how to discover them, and which are the most appropriate in your context, check out mine and Scott Millett’s free mini book Designing Autonomous Teams and Services (O’Reilly).
Sociotechnical Architecture Patterns
Building blocks can be combined in different ways. We can design where the dependencies and collaborations should exist using common patterns.
The patterns have organisational and technical pros and cons, and related implications. I will explain with a brief example.
When I was invited by a European TV broadcaster to advise on the redesign of a business unit, they outlined their scenario. Some of the primary considerations were:
- A need to experiment with more interactive forms of TV (competitors hold the advantage)
- Currently two legacy systems which are decades old
- The systems are owned by different teams based in different cities
- No in-house agile capabilities but a desire to innovate and deliver more continuously
I spent the next two hours discussing the changes I thought would be most effective. But I had to explain everything in precise detail, because there is no common language of organisation design patterns and plays.
Common patterns and plays do exist though. I could have condensed the 2 hour discussion into 5 or 10 minutes by beginning with “I would use the Enterprise Discovery Context pattern inside an Agile Culture Bubble”.
Sociotechnical Architecture Pattern: Enterprise Discovery Context
An Enterprise Discovery Context is a transitional play used in large organisations seeking a breakthrough innovation.
When to Use
When you want to innovate in an enterprise, but the new concept cuts across multiple existing teams, consider using an Enterprise Discovery Context.
Trying to coordinate multiple teams who each own a piece of discovery slows down the rate of learning. An Enterprise Discovery Context is a short-term solution that brings as many of the skills needed into a new temporary team to optimise for learning speed.
Organisational Considerations
Here are a few of the organisational considerations associated with an Enterprise Discovery Context:
- You are forming a short-term team combining people from existing teams, consider the feelings of people not invited, and the constraints of geographical locations
- The team is not judged on how much they deliver but how quickly they validate hypotheses
- Dependencies on other teams should be minimised
Technical Considerations
Here are some of the technical considerations associated with an Enterprise Discovery Context:
- Existing systems are unlikely to support the new use cases — short term solutions may be necessary (especially in regard to moving data between systems)
- Legacy infrastructure may be a bottleneck — consider using cloud services if possible
- Quality will be lower — build MVPs to validate ideas
Transitional Considerations and Combinations
When using an Enterprise Discovery Context you may want to consider the following evolutions and combinations:
- New contexts may arise from the result of discovery
- Next stage of evolution is to scale the concept — consider transitioning to Autonomous Contexts
- If this is part of a transformation initiative, consider combining with an Agile Culture Bubble
Sociotechnical Architecture Pattern: Agile Culture Bubble
A Culture Bubble is a play for introducing a new type of culture into one part of an organisation. It’s a classic strategy for implementing agile in small steps without doing a full-blown, organisation-wide agile transformation.
A culture bubble also has known implications and recommendations, for example it can create an “us and them” rivalry in the organisation, and it may be necessary to bring in outside help to initially train and support existing staff .
The ‘Continuous Organisation Design’ Cycle
To make sense of organisation design, think of it as a strategic cycle.
The model I use is based on Simon Wardley’s Strategy Cycle which he bases on the legendary five elements of Sun Tszu.
I’ll be exploring these ideas, more patterns, and case studies in future posts. In the meantime, you should start reading Simon Wardley’s Wardley Mapping book.
Let’s Write this Playbook Together
It’s time to improve the way we design digital organisations and you can play a key part.
Look for patterns in your organisation. Write blog posts and talk at meetups about them, and share insights you discover about existing patterns.
Let’s write this playbook together.
