I first read Team Topologies in 2022 and was immediately impressed. It connected with me similarly to two great works by Gene Kim: The Phoenix Project and The Unicorn Project. All three of these books (two of them novels but could be written about almost any modern company) connect at a human level with what we’re trying to achieve when we build software.
Team Topologies has fundamentally reinforced my view of a human-centred approach to software delivery. It provides an approach where we systemically remove major impediments to software flow (through to customers) and aligns the organisation to do what it does best.
Team Topologies is a game-changer. It shows how organisations can re-imagine team structures aligned with architectures suggested by Conway’s Law. Interestingly it’s also not confined to working just with software delivery. Matthew Skelton, talking at the first-ever Fast Flow Conference in London recently, shared how many other industries are aligning their teams in Team Topologies fashion to provide more stream-aligned approaches to service delivery.
Fundamentally though, Team Topologies shows how software architects and engineering leaders can best serve their organisations and customers by supporting team change and participating in the core delivery streams. Aligning the whole organisation around the flow of features towards customers, bringing clear business benefits.
Alignment of teams with value streams also has architectural value, allowing techniques such as Domain-Driven Design and emergent architectures to become more prevalent – allowing us to be flexible in our architecture as much as in our code as much as in our organisation.
As we become more aligned with business goals as an organisation, we actually get more opportunities to selectively apply other best practice techniques where need them in our software delivery. Stream-aligned teams, working with autonomy and in psychologically safe environments are free to experiment. Our advantage comes through experimenting safely.
What about Enterprise Architecture?
Conway’s Law tells us how application architecture mimics organisational structure. Taking a human-centric approach means admitting we don’t know what we’re building when we start. This has a significant impact on the way we approach building software. Admitting we don’t know something in advance is immensely freeing. This can also be very personally very difficult for many software or enterprise architects to admit to themselves and others. In a context where the ‘architect’ is seen as all-knowing and all-seeing – Team Topologies throws away the idea of omniscience. Team Topologies explicitly tells us that we’re inevitably going to get it wrong at an individual level but as a team, with the right approach, we can excel. Because another core message of the book is that the team approach is the only approach, this means that the individual doesn’t take the blame for any one decision.
Having this more flexible approach to application engineering means any enterprise architecture function must reconsider what that role means to the organisation. While there will always be a need for long-term IT planning, with the arrival of software-configured networks and flexible application infrastructure, a competitive advantage for an organisation resides in its ability to innovate. Major decisions still need to be made about platforms and providers, but we should always do this with an eye to flexibility.
Modern Software Leadership
CTOs, Engineering Leaders and Enterprise Architects can all benefit from understanding the fundamentals of a Team Topologies approach by engaging with the teams that know best what the customer needs.
Admitting that, as leaders, we don’t know everything is also immensely freeing. By having a flexible attitude to what success looks like, but being fiercely stream aligned as an organisation, we can make decisions quickly and effectively to respond and react to changing market conditions.
By continuously challenging our teams and each other to improve, delivering more to our customers, and predicting their needs, we bring an organisation closer together through IT and software delivery. These themes and many case studies are shown in the Team Topologies work and further explored through other important books such as The Value Flywheel Effect (David Anderson et al) and Sooner, Safer Happier (Jonathan Smart).
But thanks to Manuel Pais and Matthew Skelton and Team Topologies, we have a manual, a blueprint that will allow us to design an organisation without needing to feel that we’re getting it wrong. Essentially it tells us there is no wrong unless you’re not aligning to provide customer value. This simplifies our work as leaders in some ways but also makes us have to be much more hands-on as engineers. We must understand teams’ pain to adapt quickly to changing customer needs.