Micro Focus is now part of OpenText. Learn more >

You are here

You are here

How to reduce cognitive load and increase flow: 5 real-world examples

Matthew Skelton Founder and Head of Consulting , Conflux
Manuel Pais IT Organizational Consultant, Independent

Since our book, Team Topologies, was published, organizations around the world have begun adopting its principles and patterns. For many of those organizations, our book has provided a previously missing common language for team-based software delivery. That language can help your organization improve the effectiveness of  software delivery and accelerate time-to-value.

Our strong focus on a fast flow of change can help you rethink assumptions about team boundaries and responsibilities, replacing costly hand-offs with self-service APIs for things such as compliance and security checks. It also can help your organization reflect on and improve its situational awareness by better defining its business domains.

A primary theme is that you need to use "team cognitive load" as a key architectural and organizational design element. By using it to determine the size of services and applications, you can avoid an obsession with 20-line microservices and escape from the monolith quagmire.

Here are the approaches taken by four organizations and a consultant who followed this road:  Footasylum, PureGym, Uswitch, Wealth Wizards, and João Rosa at Xebia. They show how a combined focus on flow and cognitive load can help produce effective organizational dynamics for modern software delivery.

Platforms and flow at Footasylum

Footasylum is a UK physical and online retailer of sneakers and streetwear, with annual revenues of £260m and over 2,500 employees. In 2019, the company appointed a new IT director and began to transform the way that software was planned, built, and run, to better serve the needs of its customers and stores.

Moving away from project-based delivery where tasks were assigned to individual developers, Footasylum adopted our book's team-based approach to software. It identified separate business domains—e-commerce, retail electronic point of sale, customer experience, and ERP—and aligned teams to these streams of change.

Footasylum changed its older services team to a platform team, with the focus on reducing cognitive load on the new stream-aligned teams. With loosely coupled teams aligned to business domains, it could begin to build and release changes in each stream independently.

With the primary mission of the platform team to reduce cognitive load and increase flow within the stream-aligned teams, the platform team started to apply patterns such as "thinnest viable platform" to build the smallest amount of technology that would accelerate and simplify delivery in the stream-aligned teams.

For example, instead of building a full HTTP API for physical store location data, it simply provided a version-controlled static JSON file. It turns out that the data from physical shops rarely moves from one day to the next.

Flow and clear team interactions at PureGym

PureGym is the second-largest gym and fitness operator in Europe, serving approximately 1.7 million members from over 500 facilities across the UK, Denmark, Switzerland, and Poland. In the UK, most of its gyms are open 24/7, and technology plays a leading part in allowing members to join and manage their memberships, on both the mobile app and the website.

In 2015, PureGym brought software development in-house and began to build its own software for engaging members as part of a drive to provide a first-class digital experience for new and existing members. For the first few years, the PureGym teams focused on getting core functionality working.

Although the teams used good practices such as test-driven development (TDD), behavior-driven development (BDD), continuous delivery, metrics, and logging, over time its software became increasingly difficult to work with. All the functionality was contained in a single software monolith, and prioritization of features became more difficult.

In 2019, the teams began to use the Team Topologies concepts. In particular, the PureGym teams used "fracture planes" (such as change cadence, risk, and regulatory compliance) and team cognitive load to help decide where to divide up the software monolith. With loosely coupled, independent teams now responsible for the end-to-end delivery of changes in each of these streams, progress began to come more rapidly.

Figure 1. An interim high-collaboration phase for teams at PureGym; "MMG" is "Membership Management Gateway." Image by Richard Allen at PureGym; used with permission

PureGym used team interaction modes to explore exactly where the different service boundaries should be between teams and within the internal platform. Team interaction modes include collaboration, facilitation, or one team providing a service that another consumes.

This crucial step helped provide confidence that the boundaries were effective for achieving fast flow and limiting cognitive load. John Kilmister, principal software architect at PureGym, said, "We were able to adapt the way we work and create a working environment that has boosted team morale and increased our productivity as PureGym continues to grow.”

Using Kubernetes to limit cognitive load at Uswitch

Uswitch is the UK's leading home services price-comparison website. The technology department has used a team-based approach to software delivery since 2010, with excellent results. Initially, teams were substantially independent, focused on different products (such as mobile phones, energy, or broadband).

These teams had the freedom to build their own supporting infrastructure stack in AWS. This provided much-needed speed and allowed teams to move at their own pace.

However, over time, the underlying infrastructure code—different for each team—became an increasing burden. Teams spent too much time on low-level infrastructure aspects and not enough time on solving customer-facing problems.

In 2018, Uswitch decided to introduce a platform abstraction layer (in this case, Kubernetes) to limit the cognitive load on customer-focused, stream-aligned teams and improve the flow within these teams.

Over the next two years, more teams moved onto the new internal platform and saw benefits from improved delivery speed. By mid-2020, the team with the highest revenue (and most maturity) decided to move to the new platform, and the migration was complete.

Figure 2. Team interactions for the internal platform at Uswitch. Image by Paul Ingles at Uswitch; used with permission

Crucial to the success of the platform approach was to treat the internal platform as a product. This included having a strong focus on developer experience (DevEx), using agile techniques such as MVP, and making the platform optional to adopt.

That's right; no team was forced to use the platform. Instead, the platform group had to persuade teams to adopt the platform due to its compelling features and usability.

Limiting cognitive load with well-chosen boundaries at Wealth Wizards

Wealth Wizards is a UK-based company providing financial advice with a strong focus on well-being. The technology division is currently building a SaaS platform, which will allow the company to provide regulated, automated financial advice to everyone, regardless of circumstances.

Launched in 2009, the Wealth Wizards' offering became increasingly successful, and ti added many new products and features. But by the middle of 2019, the software had become difficult to work with, and software releases came to a halt. Although the code was modular and based on microservices, the service boundaries were not well aligned to the flow of change, making changes difficult and error-prone. A new approach was needed.

Fortunately, the Wealth Wizards teams began to apply some of the ideas related to Team Topologies. "Now we could form a model on how to solve not only our immediate cognitive load problems but also our potential scaling problems in future," Richard Marshall, Wealth Wizards' CTO, wrote in a blog. "We quickly identified the problems we were seeing and the most appropriate solutions to help us reduce cognitive load and deliver faster."

How one consultant improved reliability by reducing cognitive load 

João Rosa is a Xebia consultant who helps large organizations improve their software strategies. By combining Team Topologies with context mapping, which provides a high-level view that helps developers make strategic decisions. Rosa has found a way to explore the cognitive load on teams building and running software. By identifying areas with high cognitive load, teams could then explore the likely operational complexity and therefore typical reliability characteristics of the software.

"In my experience, taking a look at how the teams interact and how we lay out our solutions is a great start to discover and improve service reliability qualities, before changing the technical aspects," Rosa said.

If the flow of change crosses multiple teams, it's likely that the resulting software will have reliability problems, because there are hand-offs and internal system boundaries, and these hand-offs usually result in an increase in problems. "If the responsibilities of the teams are aligned with the bounded contexts, and the teams work toward the most beneficial interaction modes, it improves the system reliability," he said.

Try it yourself

You can use the ideas and patterns in Team Topologies to help improve the flow of change and to reduce cognitive load on teams building and running software systems. As these early results show, having clear language and heuristics for these organizational and architectural patterns can be very helpful.

We would like to thank Paul Martin and Andy Norton from Footasylum, John Kilmister and Rich Allen from PureGym, Paul Ingles and Tom Booth at RVU/Uswitch, Richard Marshall at Wealth Wizards, and João Rosa from Xebia for contributing their stories to this article.

Want to know more? Attend our talk, "Team Topologies in Action: Early Results from Industry," at DevOps Enterprise Summit—Virtual. The conference runs October 13-15, 2020.

Keep learning

Read more articles about: App Dev & TestingDevOps