By: Tom Henriksen
Team Cognitive Load is an interesting idea. I have heard other people discuss cognitive load and how it relates to developers; the team though is a new wrinkle to me.
Team Cognitive Load
Manuel starts by talking about how cognitive load from the individual perspective can affect each one of us. Then we look at teams who must juggle different aspects of the application.
Naming the problem is a big step. Manuel points out that many teams feel this pain. Now that we have a name we can begin to address this issue that teams face.
He outlines three types of cognitive load. The first is Intrinsic. This deals with the skills we need to understand. For instance, Java developers need to know how to write classes.
Extraneous cognitive load is the tasks around software delivery. A few examples Manuel shares are provisioning a resource, deploying and application, and monitoring an existing application.
Lastly, we have a Germane cognitive load. This is the business domain we must know. If our application is a banking system we need to understand how that works. This can have subtle changes for each company.
All of these factor into team performance. Potentially Manuel points out that teams can be overloaded. If this sets in, the team can take shortcuts that lead to quality issues.
Another aspect of the team being overloaded is demotivation. He shares how we must remember Daniel Pink’s book Drive,here he calls out three parts to motivating a team: Autonomy, Mastery, and Purpose.
We expect our teams to be autonomous. This is easier said than done. A team must have the time to make the decision. When numerous deadlines hang over them they may just quickly decide.
They also must have the pertinent information they need to make decisions. However, if the data they use to make a decision is outdated they will likely choose poorly. We need to ensure the team has the time and information to choose a solid path.
The way teams interact needs to be called out. Instead of just letting things happen we need to be intentional. If we let things happen in varying fashions this increases the team cognitive load.
What does intentional communication look like? When we create means of interaction, for instance, the build team needs to interact with the API team. Think about how that information should flow. Try to enable the communication so it doesn’t overwhelm the team.
Perhaps the team prefers to be contacted via Slack. Some teams want all changes to come in via Jira. Others may want teams to share them during certain meetings. Having just one way helps reduce the team’s cognitive load.
Manuel also shared that we need to limit the interaction. Contemporary software can rarely be made by one team. As a result, we shouldn’t have unlimited interaction with other teams. Similar to noise in a public space, this can be a distraction.
This can seem counterintuitive in that more interaction seems better. This can overwhelm the team and degrade performance. The level would probably be different for every team. So adjust as needed to the level the team desires.
The teams can come in various forms. One team type is the Enabling team. This is a team of experts in a domain. For instance, we might have a Test Automation Enabling team.
They would work with teams that need to improve their Test Automation. The engagement would be limited while they train the team and t hen coach them in the area to a level of competency.
Stream teams are aligned with the business. They produce software for the business needs. So if we start a new stream team they might need help from one of the enabling teams.
In conclusion, using these techniques can help teams thrive. Instead of overwhelming the team to do everything. We can focus them in one area. Therefore, we reduce the overall Team Cognitive Load.