How we used Conway’s Law to create high-performing teams

Making sure domain knowledge resides in the collective, rather than individuals

Photo by Jason Goodman on Unsplash

“Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.” — Melvin E. Conway

The smallest unit is a team

It was 2020, when most of the world was in lockdown, that the leadership team for my portfolio realised the majority of our domain knowledge was residing where it shouldn’t: in the heads of key individuals, rather than our cross-functional engineering teams.

So when a new piece of work needed to be done, we had to come together and find out who knew the most about that area of the product, and then ask them to help. As you can imagine, it wasn’t the best way to allocate work, or to scale the number of teams working on our products and services. As well as this, to have such a high level of synchronous communication was really poorly suited to our new world of lockdowns and flexible remote working.

Most importantly, it opened us up to a whole barrel of risk. If one of these key individuals were to leave the company for any reason, all of that critical business knowledge would go with them.

Because no single team owned a specific domain, it meant that everyone was perpetually working on everything — and if everyone in the portfolio owns everything, it’s safe to assume that someone else at some point will deal with whatever the latest problem that crops up is. This is called the ‘bystander effect’, and it goes strongly against a personal adage of mine, which is “if everyone owns everything, no-one is accountable for anything.”

For the teams in our portfolio, there was an increasing sense of frustration. Engineers were feeling stretched and like they weren’t making a meaningful impact, product owners were finding it ever challenging to draw up their roadmaps, and it felt like there was no architecture pathway to work towards. Hero culture was rife and the risk of burnout was very real.

Because each team was working across the majority of components in our portfolio, it was difficult for them to feel they were doing work that mattered, or addressing technical debt. Their work was primarily reactive, with a reliance on individuals over teams. Something had to be done.

Using Conway’s Law to communicate as a team

Our leadership team started reading a book that was about organisational design, fundamental technology team types and their interaction patterns. It was titled Team Topologies by Manuel Pais and Matthew Skelton. At the beginning of the book, the authors refer to Conway’s Law, which simply put, means the architecture of a system is a reflection of the communication patterns between the teams that built it.

For example, if you have one large engineering team, you tend to build one large system (like a monolith). If you have distributed engineering teams with clear communication paths to each other, then each of those teams tend to build distributed systems that communicate with each other.

Conway’s Law has been around for a really long time, but Team Topologies uses Conway’s Law to define different types of teams, and how best to organise them based on the types of problems they are trying to solve.

One of the key takeaways of mine from the book was that the smallest unit in an organisation should be a team, not an individual. It resonated strongly with me — particularly because it reflected the challenge we faced: how do we create teams that have clear ownership of a particular domain, and were structured in a way that reflected the communication patterns we wanted to maintain?

More pressingly, how do we make sure that knowledge resides in teams rather than individuals?

The solution we found was to break apart the big, amorphous system that was our portfolio into smaller domains. Instead of allocating work to individuals based on their knowledge, we would give each team ownership of a domain and all the software components that went with it. In this structure, the entire life cycle of the products in the domain would be owned by a single team.

Resourcing and workforce planning decisions would be a whole lot easier, because when deciding which team would own a piece of work, we could easily say, ‘oh, it’s to do with our API product? Great, go and talk to the Platform API team.’ It shifted the onus from individuals and into team responsibility — after all, software delivery and accountability are team sports.

What does success look like?

Before we started restructuring our product engineering teams, we sat down as a leadership team and described the problems we needed to solve. Here’s what we came up with:

• We owned a lot of complex systems, which led to a high cognitive load among our teams. It was difficult for us to be an expert in everything.
• There were unclear expectations on how to support and maintain systems, especially those that were not being actively developed. This resulted in the aforementioned ‘bystander effect’.
• The lack of ownership in the product lifecycle meant we weren’t providing the best possible experience for customers.
• Collaboration and communication between teams was vital, but there was friction and bottlenecks which slowed us down.
• Individuals were subject matter experts, rather than teams. This led to a lack of accountability in the development process.
• Due to unclear ownership, the leadership team often took on ownership of outcomes, assessment of team workloads, distribution of work and delivery planning.

We spent some time thinking about our desired outcome. What did success look like for us? And what were the principles that mattered to us while designing our new team operating model? We came up with the following:

• Aligned autonomy: Teams feel empowered to confidently make autonomous decisions to maintain and continuously improve the systems they own within a framework of guidance, standards and strategic direction set by the wider team and Xero.
• Accountability: Ownership and what it means is clearly understood by each team. Teams hold themselves accountable for delivering to this commitment and responsibility.
• Cognitive load: Teams own systems that are within their cognitive capacity to understand and deliver on.
• High engagement: Teams feel engaged with, and proud of the customer problems they solve (and know the value they deliver to Xero).
• Expertise and mastery: System knowledge is held by the team and not an individual. Similarly, outcomes are allocated to a team and not an individual.
• Continuous improvement: Teams continuously improve their delivery practice and operational maturity.

Measuring teams’ cognitive load

One of the most important problems we needed to solve was team cognitive load. If we wanted knowledge to reside in teams and not the heads of individuals, then the team needed to have that knowledge in the first place, which meant there was a risk of overloading them with too much information.

It was important to us to have data to indicate if our changes had helped, so we sent out a survey to everyone in our portfolio to get a baseline for how we were tracking.

Our survey asked questions about whether they felt overwhelmed with the amount of information their team owned, or whether individuals felt like they had to go outside their team for permission to work on things they knew would be meaningful to customers. The results were interesting. Some teams had a really high cognitive load — with a large number of older legacy components that needed to be maintained.

To help with this, we got a product and engineering representative from each team into a workshop to talk about their pain points in the current operating model, and what they believed success looked like. The outcome of the workshop indicated that our wider team’s idea of success strongly aligned with leadership’s vision.

The next challenge was to consider Conway’s Law, and restructure teams based on what we needed our architecture to look like in the future.

This was an intentional step for us — we knew organising our teams based on our future architecture was likely to cause friction, given the current architecture didn’t resemble that future state. So, teams would have to work on the same components together and coordinate the changes themselves.

The gift of domain ownership

This upfront friction is the very same thing that would encourage the teams to help build this vision out, given they had the ownership of it from its infancy. Suddenly, we were truly cross-functional at a leadership level. Everyone was working closely together, aligned to the same outcomes.

We considered everything we knew about our pipeline of work, our upcoming roadmap and long-term strategic priorities. The architects drew up the intended future architecture state using this information, and together we came up with six product domains that made sense from an engineering, product and architecture perspective. For each domain, we noted down the business purpose and the software components that would be owned within it.

Like magic, it was all there — a strong product, engineering and architecture vision for our portfolio. We presented all of this to our teams and gave them every opportunity to share their thoughts. We knew different people preferred different methods of feedback, so we offered a number of safe options, from anonymous forms to AMA group sessions.

At the time, we had six teams. And conveniently, we had designed six domains. All we had to do was work out which team would own which domain (this process included a speed dating-style delegation!). While good fun, in the end, it was our leadership team who voted on which team they believed would be best suited to each domain, and from there, we handed over the reins.

The sense of instantaneous ownership was palpable, and we knew that this had been a long time coming.

So… did it work?

Three months later, we repeated our original survey to see how the teams’ cognitive load had changed as a result of the project. Some teams were still finishing up pieces of work that were in flight prior to the new ownership, but for most, the level of cognitive load was surprisingly good, considering.

One team still had a pretty high cognitive load, which was an indicator that we needed to split that domain into more than one team. We went back to our principles and got the cross-functional leadership team to agree on the responsibilities in the split, then discussed it with the team and got their feedback, just as we did the first time around. It all went really smoothly, and has validated the importance of regular cognitive load surveys.

Future-proofing our teams

When we started this piece of work, the outcome we were working towards was about getting knowledge out of the heads of individuals. But what I feel that we’ve actually done is create high-performing, autonomous teams that take ownership of their work.

When big projects come into our pipeline, it’s now easy to assign them because we know who owns those components or domains. Each team can invest in continuously improving the health of their components, because they are the subject matter experts of their particular domain and understand what their high-value work is.

Our teams are less reactive because they have the headspace to focus on observability and addressing tech debt early, so their roadmaps are now more data-driven and outcome focused. They understand their customers and have the domain knowledge to determine what experiments to try, and the risks and effort associated with them.

I highly recommend this approach for building high-performing teams, for a number of reasons.

Your teams can focus on building beautiful products thanks to a clear product vision, a defined target architecture, and clear domain boundaries. You’re creating systems that reflect where you want to be in the future, not just necessarily where you are today — and finally, you can stay true to your principles, while empowering teams to do the best work of their life.