We’ve said it before: automation saves time by eliminating rework and reducing inefficiencies. But what does your team do with that extra time? We also have to consider the team’s mental workload. What happens when their “cognitive load” becomes too heavy? And how do you fix it so that your people can focus on the work that really matters?
Let’s take the full-stack developer as an example. It’s a demanding role, requiring knowledge in a wide variety of domains. That’s not only very difficult, it’s also just a bad idea. Because honestly, no one can keep up over the longer term. Sooner or later, every full-stack developer will experience excessive mental workload.
What are the consequences?
The signs are easy to spot: developers who jump from topic to topic, rush from one thing to another and can’t see the forest for the trees. You see it in others who are busy all day yet get very little done because they spend their time dealing with minor issues. The result is loss of motivation and dwindling job satisfaction. If, as an employer, you don’t do anything about this the consequences are obvious: people burn out or leave.
How can you prevent excessive mental load?
The book Team Topologies by Matthew Skelton and Manuel Pais offers a blueprint for tackling this challenge. The authors explain how to optimally organize your business and technology teams. We’re focusing, of course, on IT teams.
According to Skelton and Pais, if the cognitive load for a single IT team proves too high because it has to handle too many different tasks, it’s better to split that team into several smaller teams, each focusing on a single domain. Spotify, for example, works this way. Behind the app, there appears to be one large team, but in reality, it’s a group of teams. One team is solely responsible for the player, another for the recommendations, and so on. Each team has a single responsibility, which it fully commits to. But the team always works within its defined boundary to minimize external mental burden.
Then you further reduce the external mental burden by automating as many tasks as possible, especially those unrelated to the team’s specific domain.
Isn’t that too much parallel work?
That’s definitely a risk. That’s why the authors of Team Topologies defined four types of teams. The stream-aligned teams focus on a single domain. The platform team provides the platform and auromation that combines all the separately developed components. Enabling teams know the technology used inside and out and enable the stream-aligned teams to develop new features. Finally, a complicated-subsystem team specializes in technology that the other teams don’t necessarily need to know in detail.
These different teams communicate with each other in three ways: enabling and facilitating, but also collaborating and using X-as-a-Service as much as possible. Each team builds its part of the solution, documents everything, and offers the result as a service to the other teams. If each team takes responsibility in this way, you accelerate delivery without the risk of excessive external mental burden.
First, shape your communication
We also need to briefly discuss Conway’s Law. This describes the relationship between an organization’s communication structure and the systems it designs. Simply put, Conway’s Law states that a system is modeled on the communication channels within your organization.
The authors of Team Topologies turn this on its head. They first look at communication and collaboration, which ultimately leads you to the IT architecture you need. If many things have to function independently, you encourage the use of X-as-a-Service. Or you encourage collaboration if you want developed components to be coherent. This way, you can keep your cognitive load under control at the same time.