Photo by Charlie Firth on Unsplash
Tech is a very fluid and changing world, but one of the most lasting truths in technology is Conway’s Law.
Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.
“How do committees invent?“, Melvin Conway
What does Conway’s Law actually mean?
Conway’s Law asserts that systems built by multiple teams or by committee will inevitably end up structured along organisation lines.
But why?
A small team working around a shared desk has a very low cost of communication, which allows communication to be rapid, unceremonial (“hey Bob, what’s this mean” vs finding a slot in a calendar and setting up a video call) and personal.
Small (2 pizza) teams intimately learn not only the tangible output of their team-mates but also the intangible or indirect output of their local colleague group. They know when someone’s in a bad mood because they disengage or type more vigorously, they know if Teri disagrees with an idea because she visibly flinched when it was proposed.
Communication in a single team is so rich and comprehensive it’s essential that teams are carefully designed to form cohesive, productive, effective and functional units – not just a collection of individuals pulling in different directions.
Now add a second team into the mix. Even if they’re sitting around a desk that’s right next to the first team there’s an automatic reduction in communication quality, even if it’s slight. The second team likely has separate stand-ups, has a different leader with a different leadership style, tolerance to play and failure and different standards against which to measure end of year performance.
The two team cultures will be, however slightly, different.
And therein lies the brutal, beautiful truth in Conway’s Law.
What is a Team?
I’ve mentioned before that the best description of “team” I’ve heard is:
“Everyone necessary to deliver an increment of product”
“Why agile fails in large organisations”, Mike Cottmeyer (Leading Agile CEO)
If you look at how software development teams have traditionally been organised, you’ll note they don’t fit the above description. (Arrows showing the typical direction of dependency, i.e. releasing front-end functionality relies on back end functionality being built first, back end business logic relies on data persistence to be designed and implemented before being releasable – also note data and BI teams have a cyclic dependency on back end teams to complete their work so they know the data structures they will be receiving into their analytics systems).
Delivering a new feature requires at least three different teams to work on their piece of the puzzle, the “axis of change” is top to bottom. This is a coordination overhead, it requires at least three teams to have a synchronised gap in their backlogs to collaborate on ideation and design.
Subtle, minute shifts in the design over time as new knowledge is gained can cause misalignment in the final solution, requiring rework, potentially harming trust. It’s not uncommon for “them and us” relationships to form between these different disciplines, especially when one team blocks another.
So what does Mike Cottmeyer’s description of a team imply? Here are my thoughts (yours may differ):
- Decision makers are inside the team (leading to team autonomy)
- A team needs to be a cross-section of disciplines / specialists (again leading to autonomy while also minimising handovers and cross-team coordination)
- The team is empowered to make changes, but is also entirely responsible for those changes (ownership)
There’s a constraint I want to propose here too, which is from my own experience and not directly driven by Mike’s presentation, that’s the implication:
- A team works almost exclusively in the same area of the overall product.
You can have empowered, cross-disciplined teams with in-team decision makers and still have terrible, poor-quality products if the team isn’t the right team for the job.
What is “The Right Team for the Job”?
Not all teams are created equally, and context matters (another lasting truth in technology). But there are two key factors to bear in mind when designing teams:
- Domain expertise
- Problem-personality fit
Teams need to be have, or be given time to build, expertise in a certain area (domain) or areas. By “certain area” I don’t mean “Salesforce” or “CRM”, I mean a smaller part of the product that can fit inside their head, that they can understand deeply and can make changes to, fully knowing the impact and blast radius of that change (which enables effective testing of those changes, leading to high confidence releases).
The types of people in a team also need to be aligned to the types of problems they’re trying to solve. It’s essential that those responsible for designing team structures understand if the work is novel, enhancement, maintainence or protection, because each requires very different people.
I’ve another blog in the works that goes into much more detail about problem-personality fit but think about the results you’d see if you assigned an excitable junior developer to maintain a mission-critical service under Six Sigma methodologies. It likely wouldn’t end well.
Conclusion
Many of you might be thinking that this is a rewrite of my Shortcut to Continuous Delivery blog and you’re kinda right, however, it is important to understand the different perspectives.
Naming things correctly is important. Note the use of the term “Delivery Team” in the title, for me this is the ideal name for a cross-disciplined team empowered, informed, involved and capable of delivering product.
“Development Team” seems too focused on the coding, “Feature Team” (where a team can touch any part of the product in order to deliver a cross-cutting piece of functionality) has its own shortcomings, best articulated by Sam Newman:
With wholesale adoption of feature teams, all services can be considered shared. Everyone
“Building Microservices“, Sam Newman
can change every service, every piece of code. The role of the service custodians here
becomes much more complex, if the role exists at all. Unfortunately, I rarely see
functioning custodians at all where this pattern is adopted[.]
So a final definition for the ages (and SEO):
A Delivery Team is:
A small, cross-disciplined group of similarly-driven people, with expertise in the specific area to which they are assigned, empowered and capable to make end-to-end changes and responsible for the effects of their changes.
Me
The benefits of this approach:
- Few, if any, handovers or cross-team coordination
- Low cost of communication throughout the entire delivery cycle
- Clear ownership, responsibility and purpose
- A common mission leading to autonomy and automatic alignment towards shared goals
- Well understood boundaries of change, allowing for effective testing
- Effective testing leads to higher confidence when releasing, enabling tremendous business agility
- Business agility and high confidence releases enables Continuous Delivery.
If you thought the concept of Microservices architectures came out of nowhere, you’re probably now seeing that they were a by-product of people seeing the benefits of, and moving to, domain-centric delivery teams.
Microservices were just Conway’s Law in action, responding to the change in organisational structure.
I’ll leave you with this simply brilliant rewording of Melvin Conway’s law:
If you don’t want your product to look like your organisation, change your organisation (or your product).
“Building evolutionary architectures“, Rebecca Parsons (Thoughtworks CTO)