Whose cognitive load is it anyway?

You may have come across the term “cognitive load” recently. With an increasing number of tools, frameworks, and methodologies to choose from, along with the evolution of “DevOps” and the mantra “you build it, you run it”, we’ve seen a huge increase in cognitive load on the developers tasked with delivering customer-facing products and services.

Recently there has been a focus on improving “DevEx” (developer experience) to make this process easier. We’ve seen the rise of “paved paths” or “Golden Paths”, aiming to make it simpler, safer, and faster to get code into production and reduce cognitive load. But, if cognitive load is reduced for these application developers, has it gone away or is it now someone else’s cognitive load?

Cognitive load theory first began to be researched in the late 1980s by John Sweller and can be defined as:

“The cognitive load involved in a task is the cognitive effort (or amount of information processing) required by a person to perform this task.” (Reif, 2010)

The problem with too much cognitive load, as explained by De Jong in 2010, is that:

“Cognitive load theory asserts that learning is hampered when working memory capacity is exceeded in a learning task”.

In other words, if we have too much cognitive load, the amount of information we can retain and process hits a limit and we struggle to complete the tasks we’re working on. This is an on-going struggle for anyone trying to navigate a complex technical landscape. New tools are released every day and keeping up with new features, evaluating tools, selecting the right ones for the job, let alone understanding how these tools interact with each other and how they might fit into your tech stack is an overwhelming activity. 

As well as all these technology choices, we’ve also seen changes in ways of working which have meant learning new practices, such as “DevOps”. The DevOps movement began back in 2009 and can be defined as:

“The Devops movement is built around a group of people who believe that the application of a combination of appropriate technology and attitude can revolutionise the world of software development and delivery.” (Patrick Debois, 2010).

The movement arose in response to problems that organisations were seeing when they had teams of developers and operators working in silos and not collaborating. This can happen when developers are responsible for writing code and then “throwing it over the wall” to the operations team. Operators are responsible for keeping code up and running, often on-call, and asked to triage code that they didn’t write and may not understand. 

In this model, developers and operators are able to focus on their specific domain which, particularly for developers, means reduced cognitive load. But the teams are siloed with different incentives: Devs want to ship more features, Ops want to keep things stable and reduce risk. There is little empathy, little collaboration, and the tension and friction means progress to deliver value to customers is slow. DevOps has arisen to solve these challenges, with developers being asked to take on more responsibility for not only writing the code but also running it.  And if you’re part of a team that is being asked to use the newest technologies and follow DevOps practices, that sounds like a lot of cognitive load!

One trend that we’ve seen emerge to try and tackle this is the focus on “developer experience” (DevEx). James Governor from Redmonk defined this as:

“Developer Experience is about creating an environment in which a developer can do their best work. DX is the context in which developer productivity can be unleashed, in which individual needs can be successfully balanced with those of the engineering team.”

We need to ensure that developers have everything they need to do their best work. This includes the tooling, the abstraction levels, the automation and the self-service experience so that the developers in turn can focus on delivering value to customers. In other words, DevEx is about reducing the cognitive load on developers to enable them to go faster. 

One way to do this is to follow the organisational design as described in the Team Topologies book by Skelton & Pais. They describe having a platform team, whose responsibility is to collaborate with and provide a self-service platform for the Stream-Aligned Teams, or developers. 

In the book they include this definition of a platform by Evan Bottcher:

“A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.”

A platform can be a huge complicated system or it could be a small set of APIs that gives developers access to just enough components needed to deliver code. Whatever the platform is, we need to make sure it provides a delightful developer experience. In my team’s experience, the best way that we know of to ensure this happens is to treat the platform as a product.

The platform team must apply a product mindset to the platform. This could include defining a product strategy, using iterative development, frequent releases, gathering feedback from development teams and stakeholders. The platform team focuses on providing “developer delight” whilst avoiding technical bloat and not falling into the trap of building a platform that doesn’t meet developer needs and is not adopted. If done well, we see feedback such as these quotes from the Puppet State of DevOps reports:

“Application teams want to use the product because it has been built to meet their needs and it makes it easy for them to get their work done”. 

“done right, the internal platform helps organisations to scale DevOps.”

But an internal platform as a product offering all of the tools that developers need is not quite enough. There are other business concerns such as compliance and governance which need to be considered and this is where Golden Paths come into play. By offering Golden Paths to developers, platform teams can encourage them to use the services and tools that are preferred by the business. This helps to streamline the number tools offered, reduce the cognitive load of too many options, as well as reduce technical bloat of the platform.

These Golden Paths can build in guardrails that the business requires, such as compliance, security scanning, monitoring and more. All of these concerns can be incorporated into these Golden Paths so that developers know if they follow them, they have fewer gates to hurdle and they can get to production faster and will be supported.

So how do all of these parts come together? We know developers have a lot of tools and practices that they are using to get the job done. We know that to reduce their cognitive load, they need a good developer experience on a self-service platform and that experience could include Golden Paths to make the journey to production as smooth as possible. But has the cognitive load disappeared?

Unfortunately not! The challenge we’re coming across is that cognitive load is shifting on to the platform team. These teams have become responsible for providing the developer experience, but with many tools that need to be incorporated, as well as other concerns such as compliance and governance, they face huge cognitive load. This is typically a team that is underinvested in and yet they are responsible for providing the platform that is supporting the delivery of customer value.

So in answering the question “whose cognitive load is it anyway?”, please consider that shifting all the burden on to the platform team is not reducing cognitive load, it is just moving it somewhere else. And one more question: in addition to developer experience, shouldn’t we also be thinking about platform engineer experience?

*This blog post is based on a talk of the same name at PlatformCon 2022. Watch the full recording here.