Cognitive Load and Configuration Management

Let’s talk about empowered teams – it sounds like a good idea because it is a good idea: a team is made up of owners who are empowered (with the authority and autonomy) to make decisions, stay unblocked, and deliver value. When thinking about team structures, happy teams are in control of their own destiny as much as possible – and do their best not to take on risky dependencies. Of course, there is a lot more to a high-performing team, but this is a key part of it.

A consequence of a self-reliant team is they can end up owning a lot more than can fit in someone’s brain – this can result in two types of work that many builders don’t want: Overhead and Toil. You can read about this in Google’s Site Reliability Engineering, but the short version is that toil isn’t “all the work you don’t want to do,” but it may be “manual, repetitive, automatable, tactical, devoid of enduring value, and scale linearly as a service grows.”

Configuration management often ends up in the “toil” category – slowing down a team and draining energy from all the parties involved.

The problem is that configuration management can start out simple, but in the end, becomes much harder than it needs to be. Getting this right is important. The challenge is to get it right without spending all your cognitive load in this area. A model for cognitive load in the tech space talks about three types of categories of cognitive load:

1. Intrinsic Cognitive Load
   Tasks in the problem space, like “do I need a space after a colon in this line in my YAML file”
2. Extraneous Cognitive Load
   Relates to the environment in which the task is done, like “how do I deploy this”
3. Germane Cognitive Load
   Relates to tasks that need attention directly in the problem space, like “how should these 2 services interact”

Simply put – try to reduce #1 and eliminate #2, leaving you time in your brain for #3. For almost every team, configuration management takes cycles away from your team for both Intrinsic Cognitive Load AND Extraneous Cognitive Load.

Cognitive load and toil can sap the energy out of your team – think about chasing down those “special” configuration values that work for a development environment but were supposed to be changed when you went to UAT. You finally find that one value which was missed, but rather than feeling good about solving the problem you think “I’ll never get that day back, what a waste of time.”

That’s NOT a way to have a motivated, empowered team.

The problem with configuration management is that you may think you have a configuration management tool when what you really have is:

• Configuration data in a lot of different places
• Multiple configuration editors/ways to manage your configuration data
• Multiple ways to move your configuration around within your environment

Usually there isn’t a configuration management tool with a full view of your data, which leads to a lack of confidence in the actual running configuration, delays in troubleshooting issues, slowdowns in your development velocity, and real customer-facing impact.

One of the things that I like about the CloudTruth vision is reducing toil and cognitive load on teams. Having one place to see what is really going on with your configuration, across environments, eliminates that Extraneous Cognitive Load. In addition, while you have the flexibility to edit your YAML files in notepad (if that’s your thing), you don’t need to. Instead, you can save that Intrinsic Cognitive load for something else!

With a DevOps mindset and the goal of keeping teams unblocked, many teams end up with more of their development days spent dealing with configuration management. They either spend most of their time with config management or they do a poor job with it and create tech debt that needs to be cleaned up down the road.

We are asking more and more of our teams today more than ever and many of them are at the breaking point. Don’t let configuration management issues push your team to the breaking point.