You may have heard about Conway’s Law “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” I’m guessing you already had some inkling that how we organise our teams has implications for the shape of our software. It’s pretty normal to divide up teams by the parts of the system they’re responsible for. Most organisations can and do spin up new teams to match their ongoing initiatives.

So why might Conway’s Law be something to watch out for? Well, it’s not so much that our org chart impacts system architecture and that re-orgs are slow to execute. Communication actually happens between individuals within an organisation. The quality of communication is impacted by factors like location, personality and the medium of conversation (email, chat, in-person, etc). Even when there’s no barrier to talking, sometimes it’s hard to be heard in conversations with busy people or someone who has very different interests.

Taking this into consideration, our stated reasons may not be the real reasons, for code to be in one place over another. Our decisions about where to put code reflect what we know about the wider system. Under time pressure, we may also weigh convenience for ourselves over convenience for others in such decisions. Design decisions in the small can have an impact on the system in the large. Although an organisation usually plans around a “big picture” architecture, it’s likely that this view is being eroded by tiny transgressions made every day – over time the effect of Conway’s Law is that it becomes harder to make changes to the system.

As we move into a world that embraces Lean/Agile thinking, we want to be able to pivot and to make swift changes to a system, as we chase an evolving market. Conway’s Law makes this hard because the actual design produced reflects the reality of our communication structure. Simple changes end up touching more places than strictly necessary (like a scaled up version of the Shotgun Surgery anti-pattern). When the system needs to be changed, meetings ensue between people with vested interests in parts of the system who dig their heels in over who should do the work. The reason we worry about Conway’s Law is time, which costs money and a lot of painful meetings, in order to repurpose a system to fulfil different functions.

I believe it is possible to diminish the impact of change by working with Conway’s Law. We can work purposefully to create more fluidity in the “human layer” of our systems. We can build awareness of the wider system by gradually exposing people who work on the system to different areas of code. As XP practitioners, teams at Unruly follow the XP principle of Collective Ownership. All our code is developed in pairs and more recently mobs. To make this possible, we try to hire generalists over specialists and build opportunities in for developers to broaden their skills.

When we split into product teams, a few years ago, we wanted to create independent teams that could deploy changes to our products without waiting on another team. However, we were aware that the move to work as independent teams would likely to lead to divergence in coding practice, which might later make it hard to move people or code between teams. We deliberately chose to combat this risk by proactively offering the opportunity to all developers to rotate between teams. We regularly ask everyone if they’d like to switch team, what their preference on team and timing would be. Team moves are not guaranteed - it wouldn’t make sense to move everyone around at the same time. We don’t force anyone to move either, we find that’s not necessary. Having someone coming into your team from another team brings in new ideas and answering their questions can trigger existing team members to reconsider design decisions. In addition to longer rotations, we also have blocks of cross-team pairing days each month, dedicated to improving our infrastructure and UX across our systems.

Developer rotation

Following our experience with Developer eXchanges with other companies, we now do mini-exchanges between our own teams for shorter periods. All our new developers get to work in each of the other teams to help them build a broader sense of our codebase and user needs. We also do mini-exchanges with more senior developers, when a team is picking up a new area of code from another team, we send someone with the code to fill in the background about how it currently works. Mob programming is currently our favourite way of getting a team started on a new area of code.

By deliberately building mechanisms that allow all developers to work on code with another team, we find that we are more easily able to take on change in our codebase. It would be great to hear about other organisations who are taking Conway’s Law seriously and attempting to reduce the cost of change through applying XP principles.