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.
How can you keep teams from getting overwhelmed? What’s the “right” amount of work?
In Team Topologies, Matthew Skelton and Manuel Pais show you how to set up software development teams to work as efficiently as possible. Basing their approach on Conway’s Law, they recommend that you assign teams the right amount of work.
Continue reading to learn two strategies for team workload management.
Team Workload Management
The authors argue that you should prioritize team workload management so that individual teams don’t end up overwhelmed. When you give teams too many things to think about at once, productivity and quality suffer. This drop in quality occurs because your teams can’t become experts in any one area when they’re forced to divide their attention among many different tasks. 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 and don’t work as well as they could have if work had been more appropriately divided.
(Shortform note: When it’s time for you to determine exactly how much work a team can handle, consider how long each team member has been with your organization. Some argue that seasoned employees can accomplish two to three times as much work as new hires in the same time frame. Being mindful of these limitations can help you appropriately adjust your expectations for new employees and veterans alike.)
To keep teams from getting overwhelmed, consider the cognitive load when assigning tasks, or the amount of mental energy the task requires. The authors argue that more complex problems create a greater cognitive load on a team compared to relatively simple problems, so even your strongest teams can probably only handle one or two complex problems at a time.
(Shortform note: In your effort to reduce cognitive load on your teams, it may also be worth considering the environment your teams work in. Specifically, studies have shown that excessive noise in the office increases cognitive load and negatively impacts performance. To avoid these negative effects, consider creating quiet workspaces within your offices, making use of “do not disturb” signs, and establishing clear rules around noise levels in the office.)
The authors recommend two strategies for team workload management.
Strategy #1: Divide Work Along Fracture Planes
If you’re struggling to break down software into the right size pieces for your teams, Skelton and Pais recommend looking for fracture planes. These are naturally occurring splitting points between different parts of a piece of software.
(Shortform note: Skelton and Pais’s suggestion to look for boundaries to break software into smaller pieces is based on the assertion that monoliths will always slow your organization down. However, some authors believe that under the right conditions, monoliths can function just as efficiently as microservices. These authors argue that boundaries within a monolith that allow teams to take responsibility for their own projects can also be an effective way to assign work to your teams.)
One possible boundary you can use to break up software projects is the different domains of your business. For example, an airline includes many domains, such as logistics, booking, and rewards programs. By decoupling your booking software from your logistics software, you enable the teams in charge of each service to evolve their software toward the more specialized needs each service requires.
As Skelton and Pais note, the rate of software change is also a natural software boundary. When simple, flexible products and complicated systems that change more slowly develop together, the complicated system will limit the simple one’s progress. By splitting these areas into different domains, the teams responsible for each project are free to work at the pace that best suits their project.
(Shortform note: In addition to considering business domains and rates of change as software boundaries, experts recommend that you examine your current software architecture and look for problem areas that bottleneck the progress of multiple teams. By identifying pieces of software that many teams depend on and breaking them down so that each team has control over the software it needs, you can help free your teams from wait times and increase their autonomy.)
Feel free to try to identify the most natural set of boundaries for your organization. It may be one of the types listed here, or it might be something you come up with yourself. Any set of boundaries will work so long as they help your teams to operate autonomously without being overburdened.
(Shortform note: The most natural sets of boundaries you can use to divide up projects are often the skill and experience levels of your teams. Rather than looking to software boundaries to assign work, this approach suggests you look at your human resources first and adapt each team’s workload to be a good fit for their capabilities, ensuring that no team is assigned problems it isn’t equipped to handle.)
Strategy #2: Assign Work Based on Organizational Goals
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. By contrast, when teams are frequently reassigned based on short-term problems, they can become overwhelmed, which leads to production delays.
For example, suppose your company wants to release its new exercise-tracking app next month. However, the team in charge of the new app’s web features gets pulled away during the final stretch to fix bugs in the old version of the app. Ultimately, because this team wasn’t able to focus on the more important task, the release of your new app gets delayed another month.
(Shortform note: To ensure that your organization is looking at the big picture while remaining flexible enough to respond to problems as they occur, it may be helpful to divide your workforce between these two ideals. Many organizations promote experienced engineers into a software architecture role, in which they’re less responsible for writing code and instead focus on overseeing the long-term development and success of an organization’s software projects.)
———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
