The Challenge of Cognitive Load in Platform Engineering: a Discussion with Paula Kennedy

In a recent article, Paula Kennedy, Chief Operating Officer at Syntasso, shared her thoughts on the ever-increasing cognitive load being saddled onto development teams. She explains that the platform engineering approach is attempting to mitigate some of this cognitive load on development teams, but this may be coming at the cost of shifting that cognitive burden onto the platform teams instead.

Cognitive Load Theory (CLT), first coined by John Sweller in 1988, views human cognition as a combination of working memory and long-term memory. Working memory has a limited capacity and consists of multiple components that are responsible for directing attention and coordinating cognitive processes. Long-term storage, on the other hand, has an endless capacity for storage and works with working memory to retrieve information as needed. 

CLT was originally designed as a means to improve classroom instruction, but there are applications to software development as well. Sweller identified three types of cognitive load: intrinsic, extraneous, and germane. Intrinsic cognitive load is the effort associated with the task at hand. In a math class, this would be adding 2+2 or attempting to reduce a polynomial equation. In pedagogical terms, this is often viewed to be immutable. 

Extraneous cognitive load is produced by demands imposed on the individual doing the task from sources external to them and the task. It can include things like distracting information, poor instructions, or information being conveyed in a way that is not ideal. An example would be verbally providing someone the steps to configure a load balancer versus providing the steps in a written document. 

Germane cognitive load, as described in an article from Psychologist World, is: 

Produced by the construction of schemas and is considered to be desirable, as it assists in learning new skills and other information.

In cognitive science, a schema is a mental construct of preconceived ideas like a framework representing aspects of the world. While intrinsic load is viewed as immutable, it is desirable to minimize extraneous cognitive load and attempt to maximize germane cognitive load.

The focus on developer experience within platform engineering is a response to the heavy cognitive load placed on teams responsible for the full product lifecycle of development. Nigel Kersten, Field CTO at Puppet, explains that organizations, especially large enterprises, that implement fully autonomous DevOps teams may be optimized locally but at the expense of other teams:

That may do a good job at locally optimizing for that particular value stream team or that application. It doesn't optimize for the whole organization, you are creating cognitive load for your auditors, for your IT asset management folks, for all your governance issues around cost control and security. How do you switch from one team to another? All of these things become really, really complicated.

As the demands on development teams increase, we start to hit limits on the amount of information that can be processed. Heavy cognitive load can have negative impacts on the ability to complete a task effectively. As Kennedy notes:

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. 

These activities are extraneous to the critical tasks assigned to stream-aligned teams and therefore interfere with achieving fast flow on the essential priorities of the business. For stream-aligned development teams, shipping business value is the task that should have the bulk of the team's time and energy. Tasks like keeping up with new CI/CD tooling or the latest security threats are not, for most companies, directly critical to the product being sold. 

Evan Bottcher, Head of Architecture at MYOB, describes a platform as: 

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.

This is why the developer experience is so critical to a well-engineered platform. A platform that introduces extra extraneous load or is not a schema that promotes healthy germane cognitive load will in fact increase the cognitive burden on developers utilizing it. A platform that is not built with the end-user in mind, that does not appreciate their user journey, will not succeed in improving their delivery.

As Cristóbal García García, senior staff engineer at Amenitiz, and Chris Ford, head of technology at Thoughtworks, note:

You must never forget that you are building products designed to delight their customers - your product development teams. Anything that prevents developers from smoothly using your platform, whether a flaw in API usability or a gap in documentation, is a threat to the successful realisation of the business value of the platform.

With this lens of cognitive load theory, delight becomes a means of qualifying the cognitive burden the platform is removing from the development teams and their work to accomplish their tasks. The main focus of the platform team, as described by Kennedy, is "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."

She continues by noting the importance of paved paths, also known as Golden Paths:

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 of tools offered, reduce the cognitive load of too many options, as well as reduce technical bloat of the platform.

Applying cognitive load theory, paved paths are a means of increasing germane cognitive load by providing a schema for development teams to better understand the problem space they are working in.

In a recent tweet, Matthew Skelton, co-author of Team Topologies, echoed this sentiment and the value that good patterns to follow can bring:

What if the most important part of "platform engineering" is maintaining a high quality wiki with proven, empathic patterns for Stream-aligned teams to follow? 

Within pedagogy, there are numerous studies that show the benefits of providing worked examples to improve learning. As noted by Dan Williams, 

These steps provide learners with direction and support to create mental models of how to tackle a problem/task, or what ‘good’ looks like. Discovery or problem-based learning, on the other hand, can be burdensome to working memory due to learners having insufficient prior knowledge to draw upon to support their learning.

Paved paths and proven patterns help provide development teams with what good looks like from a holistic problem space encompassing areas like compliance and governance. As most development work mimics problem-based learning, the cognitive load on development teams is already very high. Paved paths, with associated platform tooling, simplify the problem space and reduce extraneous cognitive load. 

Kennedy does worry that in tasking teams with building this platform, we are not just spreading the cognitive load around evenly but instead pushing it down onto the platform teams. She notes that

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.

Kennedy wonders if, in addition to the current focus on developer experience, we should also be talking about and improving platform engineer experience. 

InfoQ sat down with Kennedy to discuss the articlein more detail.

InfoQ: By shifting the burden to the platform engineers you state that we are in fact pushing the cognitive load down as opposed to spreading it out evenly. This feels like we may be creating a new problem in attempting to solve our current predicament on application engineers. How do you propose we ensure we are not overloading our platform teams?

Paula Kennedy: There has been a lot of buzz and focus over the last few years on improving Developer Experience or “DevEx” to make it easier for developers to deliver and to reduce their cognitive load. Unfortunately, this cognitive load has not gone away and often is just shifted to others to manage, such as the platform engineers. 

In order to help ease this burden, I would love to see the emergence of people talking about the Platform Team Experience and how we can improve it. Whether Platform Teams are managing cloud providers, running an off-the-shelf PaaS, or have built their own platform on top of Kubernetes, I think there need to be more resources and tools that we can provide to these Platform Teams to make it easier for them to curate the platform that enables their organisation. With the increased discussion on the topic of platform engineering, I’m very excited to see what patterns and tools emerge to help solve this challenge. 

InfoQ: You note that the platform team is "responsible for providing the platform that is supporting the delivery of customer value" yet is typically underinvested in. Why do you think this is? What can platform teams do to correct this?

Kennedy: In my experience, Platform Engineering has often evolved organically instead of a Platform Team being formed deliberately, and we’ve seen this occur in at least three ways. 

Firstly, where organisations have embraced the culture of DevOps and enabled teams to autonomously deliver their software to production, these DevOps teams end up managing platform-level concerns without any additional resources. 

Secondly, some organisations consider any internal platform to be the responsibility of the infrastructure team, viewed as just another infrastructure cost to be minimised. 

Lastly, I’ve seen organisations bring in a vendor-supported Platform-as-a-Service expecting this to solve all internal platform challenges and require minimal maintenance as everything is ready “out of the box” - which is not the reality. 

In all of these cases, there is no understanding of the skills and resources needed to manage the internal platform, leading to underinvestment.

Thankfully we are seeing more resources and experiences being shared on the benefits that Platform Engineering and Platform Teams can bring. Team Topologies is a book that I recommend frequently as it provides a vocabulary to describe how the flow of value across an organisation and into the hands of end customers can be enabled through having clear team responsibilities and reduced friction across teams. 

In Team Topologies the authors advocate for having a Platform Team supporting multiple Stream Aligned Teams, and these teams should collaborate to understand each others needs and build empathy, whilst driving towards an X-As-A-Service model, where the Platform Team ensures that the Stream Aligned Team can self-serve the tools and services that they need. With more examples of the value that Platform Teams bring to the software delivery lifecycle being shared publicly, companies are starting to recognise the importance of investing in this team to ensure they have the right skills and tools to support the wider organisation.

Platform Teams can also take steps to demonstrate their value internally by considering metrics or Key Performance Indicators (KPIs) that are important to their organisation and how their work contributes to improving these. This could look like running a value stream mapping exercise, identifying where there is waste or duplication, and demonstrating how the Platform Team can offer a centralised service to improve this. 

If regulatory compliance is a critical concern for an organisation, the Platform Team could drive close collaboration with compliance teams and application teams to create friction-less paths to production with compliance steps built in, ensuring that software is delivered faster and compliantly. Internal metrics or KPIs are heavily context-specific, but by aiming to measure what is important to the business, a Platform Team can demonstrate value as well as improvements over time.

InfoQ: You mention that DevOps, in attempting to correct issues arising from the siloing of Dev and Ops, has led to developers being saddled with more cognitive load. The Platform Engineering paradigm is attempting to deal with this by pulling part of that load onto a self-service platform that handles much of the burden of getting code into production and supporting it. Are we not at risk of just re-introducing the silos that DevOps was attempting to break down?

Kennedy: The term “DevOps” means different things to different people and even though it’s a term that has been around for more than a decade, it still often causes confusion. Personally, I like to refer to the definition from Patrick Debois, back in 2010:

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.

At its core, the DevOps movement is absolutely about reducing silos, increasing communication and empathy between teams, as well as improving automation, and striving for continuous delivery. For me, having an internal Platform Team is just a natural evolution of DevOps, especially DevOps at scale. 

Members of the Platform Team are responsible for their internal platform product, and they need to both develop this platform to meet the needs of their users (the application teams) as well as operate the platform day to day. 

For the software developers focused on delivering features to end customers, they are responsible for developing their software as well as operating it using the self-service tools supported by the platform team. In this model, everyone is doing “DevOps’ i.e. everyone is developing and operating their own software. But for this to really work well and avoid the potential for more silos, there is a significant cultural component to be considered and this is the mindset shift for the Platform Team to treat their platform as a product.

I’ve talked about this a lot over the last few years but depending on how the Platform Team has evolved within an organisation, this can present a huge challenge. When treating the internal platform as a product, this includes understanding user needs (the application teams), delivering in small batches to seek feedback, providing a high-quality user experience to delight developers, internal marketing and advocacy of the platform, and much more. Where platform teams embrace this mindset, we’ve seen significant benefits, as evidenced by industry research such as the Puppet State of DevOps Report 2021: “Not every platform team is automatically successful, but the successful ones treat their platform as a product."