Forget monoliths vs. microservices. Cognitive load is what matters.

The "monoliths versus microservices" debate often focuses on technological aspects, ignoring strategy and team dynamics. But instead of starting with technology, smart-thinking organizations are beginning with the team's cognitive load as the guiding principle for the effective delivery and operation of modern software systems.

Cognitive load applied to teams

When you apply the concept of cognitive load to a whole team, you need to limit the size of the software system on which the team is expected to work. That is, don't allow a software subsystem to grow beyond the cognitive load of the team responsible for it. This has strong and quite radical implications for the shape and architecture of software systems: Software architecture becomes much more "team-shaped" as you explicitly consider cognitive load as an indicator of supportability and operability.

The drive to minimize extraneous cognitive load also leads to the need to focus on developer experience and operator experience. By using explicitly defined platforms and components, your teams will be able to reduce their extraneous cognitive load.

Some organizations have even begun to use cognitive load as an explicit input into software architecture and system boundary decisions.

Why you should use team cognitive load to right-size microservices

In a world of "You build it, you run it," where the whole team is responsible for the successful operation of software services, it is imperative to remove unnecessary barriers to team ownership of software. Obscure commands or arcane configuration options increase the (extraneous) cognitive load on team members, effectively reducing their capacity for acquiring or improving business-oriented aspects (germane cognitive load).

Another typical example is waiting for another team to provision tickets for infrastructure or to update configurations. This interrupts the flow of the dependent team, again resulting in a reduction in the effective use of cognitive capacity.

Reduced team cognitive capacity puts a strain on the team’s ability to fully own a software service. The team is spending so much time dealing with complicated configuration, error-prone procedures, and/or waiting for new environments or infrastructure changes that it cannot pay enough attention to important aspects of testability or runtime edge cases.

Put another way, by ensuring that the cognitive load on a team is not too high, you have a better chance to enhance the supportability and operability of the software on which your the team is working. It can better own its services, because the team understands them better.

Three ways to reduce team cognitive load and improve flow

There is no magic formula for reducing cognitive load for teams, but having worked with many large organizations around the world (including in China, Europe, and the US), we recommend three helpful approaches: well-defined team interaction patterns, independent stream-aligned teams, and a thinnest viable platform.

You've likely heard complaints such as "Why should we have to collaborate with that other team?" or "Why doesn’t that team provide us what we need?" These are signs that the team interactions within the organization are ambiguous. In our Team Topologies book we identify three core team interaction modes to help clarify and define how teams should interact:

Collaboration: Working together with another team for a defined period of time to discover new ways of working, new tools, or new solutions.

X-as-a-service: Consuming or providing something "as a service," with a clear API and clear expectations around service levels.

Facilitating: Helping (or being helped by) a team to gain new skills or new domain awareness, or to adopt a new technology.

With these well-defined team interactions patterns in place, you can begin to listen for signals at the organization level for team interactions that are working well and those that are not, including problems with cognitive load.

For example, if a collaboration interaction goes on for too long, perhaps it's a signal that some aspect of the technology would be better provided as a service by a platform.

Similarly, if one team expects to consume a monitoring tool "as a service" but constantly needs to work with the providing team to diagnose problems, this could be a signal that there is too much cognitive load on the consuming team and you need to simplify the API.

2. Use independent, stream-aligned teams

It is increasingly common in large and small organizations to see small, cross-functional teams (with a mix of skills) owning an entire "slice" of the problem domain, from idea to live services. Such teams are often called product or feature teams.

But with the coming-of-age of IoT and ubiquitous connected services, we call them "stream-aligned" because "product" loses its meaning when you're talking about many-to-many interactions among physical devices, online services, and others. ("Product" is often a physical thing in these cases.)

Stream-aligned teams are aligned to the stream of change required by a segment of the organization, whether that's a line of business, a market segment, a specific geography, or a government service.

It is hugely important to ensure that stream-aligned teams can analyze, test, build, release, and monitor changes independently of other teams for the vast majority of their work. Dependencies introduce a substantial amount of cognitive load (e.g., waiting for other microservices or environments to be able to test, or not having microservices-focused monitoring).

Ensuring that stream-aligned teams are substantially independent in their day-to-day flow of work removes unhelpful extraneous cognitive load, allowing teams to focus on the intrinsic and germane (domain-relevant) aspects of the work. Part of this independence comes from being able to use an effective platform.

In larger organizations it's useful to align two or three teams in a close partnership when delivering large, complicated systems. That close relationship helps to avoid one team waiting on another.

Obviously, teams do depend on other services and associated teams for providing infrastructure, runtime APIs, tooling, and so on. But these dependencies don't block the flow of work of a stream-aligned team. Being able to self-service new test environments, deployment pipelines, or service monitoring are all examples of non-blocking dependencies. Stream-aligned teams can consume these independently as needed.

3. Build the thinnest viable platform

Stream-aligned teams should expect to consume services from a well-defined platform, but avoid the massive, unfriendly platforms of yesteryear. Instead, build the thinnest viable platform (TVP): the smallest set of APIs, documentation, and tools needed to accelerate the teams developing modern software services and systems.

Such a TVP could be as small as a single wiki page that defines which public cloud provider services other teams should use, and how. Larger organizations might decide to build additional services atop an underlying cloud or IoT platform, but those extra services should always be "just thick enough" to accelerate the flow of change in stream-aligned teams, and no thicker.

Avoid the frequent mistakes of the past, when internal platforms were bloated, slow, and buggy; had terrible user experience; and—to make matter worse—were mandatory to use.

A good platform acts as a force multiplier for stream-aligned teams, helping them to focus on core domain functionality through attention to the developer experience, ease of use, simplicity of tooling, and richness of documentation. In short, build and run the platform as a product or service itself, with stream-aligned teams as internal customers, using standard agile and DevOps practices within the platform itself.

The engineers at cloud communications company Twilio have taken this approach internally for their delivery squads. In a presentation at QCon in 2018, senior director of engineering Justin Kitagawa described how Twilio's internal platform has evolved to reduce the engineers' cognitive load by providing a unified self-service, declarative platform to build, deliver, and run thousands of global microservices.

Self-service over gatekeepers: Help dev teams determine their own workflow.

Declarative over imperative: Prefer "what" over "how."

Build with empathy: Understand the needs and frustrations of people using the platform.

This approach has enabled Twilio to scale to a customer base of over 40,000 organizations worldwide.

By reducing cognitive load, a good platform helps dev teams focus on the differentiating aspects of a problem, increasing personal and team-level flow and allowing the whole team to be more effective.

Lighten the load

Team cognitive load is an important dimension when considering the size and shape of your software system boundaries. By ensuring that team cognitive load isn't too high, you can increase the chances that team members will be able to build and operate services effectively because they will properly understand the systems they are building.

We recommend the use of three core team interaction modes to clarify the interactions between teams and ultimately help to reduce cognitive load. When used with independent stream-aligned teams and a thinnest viable platform, these team interaction modes will help your organization detect when cognitive load is too high in different parts of your systems.

Want to know more about cognitive load? Attend our talk, "Monoliths vs. Microservices is Missing the Point: Start with Team Cognitive Load,"at DevOps Enterprise Summit: London, which runs June 25-27.