This article is an excerpt from the Shortform book guide to "Team Topologies" by Matthew Skelton and Manuel Pais. Shortform has the world's best summaries and analyses of books you should be reading.
Like this article? Sign up for a free trial here.
What’s Conway’s Law? What’s an inverse Conway maneuver, and how can it help your teams succeed?
Conway’s Law states that a piece of software’s architecture mimics the structure of the team that produced it. Based on this, software engineers Matthew Skelton and Manuel Pais advocate an approach to software development that they call an inverse Conway maneuver.
Continue reading to learn about designing tech teams according to Conway’s Law.
Inverse Conway Maneuver
We’ll examine Conway’s Law and the inverse Conway maneuver to give you a better understanding of how it shapes Skelton and Pais’s approach to team design. Then we’ll look at the two main strategies they recommend for using Conway’s Law to build strong teams. Specifically, they recommend that you create autonomous teams and assign those teams the right amount of work.
What’s Conway’s Law?
Introduced by computer programmer Melvin Conway in 1967, Conway’s Law states that the software a team produces will mimic the structure of the team. For example, a team that is socially isolated from the rest of your organization might produce software that makes it difficult for members of different teams to share information with each other.
| Use Conway’s Law to Set Helpful Deadlines In addition to shaping the work output of individual teams, Conway’s Law also has implications for time management practices at your organization. The book that popularized Conway’s Law, Fred Brooks’s The Mythical Man-Month, argues that setting accurate estimates for how long a project will take actually helps speed the project to completion and improves product quality. When employees are given appropriate deadlines, they won’t make errors while rushing to finish, and they won’t have too much time to focus on unimportant distractions either. In accordance with Conway’s Law, appropriate deadlines allow them to produce software that is complete and polished but not burdened with unnecessary features, which in turn means your customers will be more satisfied, and your products will need less maintenance post-release. |
Because of the link between team design and software design that Conway’s Law implies, Skelton and Pais assert that the best way to improve the quality and efficiency of your organization’s software is to focus on team design. They refer to this approach as an inverse Conway maneuver.
Specifically, Skelton and Pais argue that, when you create organized teams with clear responsibilities, those teams will produce software that is sturdy, well-organized, and easy to use. The reverse is also true—when your teams are plagued by disorganization and communication issues, they will produce difficult, disorganized software.
(Shortform note: While Skelton and Pais argue that it’s best to use Conway’s Law to shape your workforce, recent research suggests that this isn’t always the case. Specifically, experts argue that, when you work with rapidly evolving technologies that you don’t yet fully understand, adhering to Conway’s Law can lead to your organization’s lack of knowledge becoming ingrained in its systems. In cases like these, experts recommend that your organization focus on seeking new knowledge from outside sources in order to stay up-to-date and avoid creating software based on dated beliefs.)
Now that we have a better understanding of Conway’s Law, let’s look at two strategies for taking advantage of its positive effects on your organization.
Create Small, Long-Term Teams
Based on Conway’s Law, your first priority should thus be to create strong teams that can operate autonomously, without having to refer back to management or other teams for guidance.
Skelton and Pais argue that autonomy is important because it helps your organization break up monoliths, which are large pieces of software that rely on a single interface and database of code to provide many functions. When teams aren’t autonomous and work too closely together, the software they create will be tightly coupled and rely on shared code, which means problems with that code will cause delays for many of your teams. By contrast, autonomous teams produce software that relies only on their own code, which makes it relatively immune to these kinds of problems.
(Shortform note: In addition to relying on their own code, autonomous teams may also create knowledge advantages that help your organization break down monoliths. In making your teams autonomous, be sure that each team includes individuals with knowledge of any core systems that are used in projects across your organization. This will limit their reliance on other teams, and over time will allow them to develop their own autonomous versions of these systems.)
To encourage autonomy, your team assignments should be long-term. Skelton and Pais note that newly formed teams may take as long as three months to develop an effective workflow. By contrast, teams that have more experience working together are able to hit the ground running on new projects.
(Shortform note: Not only do new teams take a while to hit their stride as a whole, but small changes within your teams can also impact efficiency. Some writers argue that the addition or removal of a single member on a particular team will destabilize the team and cause a drop in productivity. While you may sometimes need to move individuals around due to personal conflicts or other reasons, you should only do it when absolutely necessary.)
Additionally, long-lasting teams are more able to take ownership of their software projects. When one of your teams develops a product throughout its entire lifespan, it becomes an expert in that product. This encourages your teams not to opt for quick, sloppy fixes, as they know it’ll be their job to deal with the resulting chaos down the line.
(Shortform note: This relationship between autonomy and professional responsibility is not unique to software engineering. Studies in nursing have shown that increased autonomy increases ownership of patient care among nurses and increases overall job satisfaction.)
Furthermore, you should limit your teams to 10 or fewer individuals. Smaller teams increase autonomy by allowing your team members to better understand each other’s strengths and weaknesses. This deeper level of understanding helps your teams to be more efficient and self-sufficient. As evidence for this, Skelton and Pais reference Dunbar’s number, which is the biological limit on how many people human beings can deeply know and trust. Similarly, when grouping multiple teams together on a project, try to only involve at most two teams to avoid going past Dunbar’s number.
(Shortform note: While Skelton and Pais rely heavily on Dunbar’s number as evidence for the superiority of small teams, some studies argue that there’s no cognitive limit to the number of relationships humans can manage and that Dunbar’s number rests on weak scientific evidence. These studies note that Dunbar’s number is based on extrapolations from research on nonhuman primates, which may not accurately map onto human subjects. Not only this but in primates, group size was limited by factors such as predation and sexual competition, not cognition.)
Assign the Right Amount of Work
As with team size, the authors argue that you should limit team responsibilities so that individual teams don’t end up overwhelmed. Software products produced by teams that are overwhelmed and lack expertise reflect this via Conway’s Law. These products will lack polish, and they may include a variety of features that aren’t fully fleshed out.
To keep teams from getting overwhelmed, consider the cognitive load when assigning tasks, or the amount of mental energy the task requires.
To assign the right amount of work, the authors recommend two strategies:
1) Divide work along software boundaries. These are naturally occurring splitting points between different parts of a piece of software.
2) Assign work based on your organization’s long-term goals, not individual problems. Skelton and Pais note that your teams should focus on bigger, longstanding projects because those projects have the biggest impact on your organization’s overall success.
———End of Preview———
Like what you just read? Read the rest of the world's best book summary and analysis of Matthew Skelton and Manuel Pais's "Team Topologies" at Shortform.
Here's what you'll find in our full Team Topologies summary:
- How to set up your software development teams to work as efficiently as possible
- The four types of teams you should create as a project manager
- The three main ways your teams should interact with each other
