The Problem of "Too Much"
Imagine a software developer named Alex. In 2010, Alex needed to know Java and SQL to build and deploy an application. That was a manageable mental load — like carrying a backpack with a few textbooks.
Today, to ship that same application, Alex must understand: Java, React for the frontend, Docker for packaging, Kubernetes for orchestration, AWS networking, Prometheus for monitoring, Terraform for infrastructure-as-code, and a growing list of internal tools and processes. That backpack is now a shipping container.
The problem isn't that Alex is less capable. The problem is that the industry has added enormous complexity without redesigning how teams are structured to absorb it.
Defining Cognitive Load
Cognitive Load is the total amount of mental effort being used in working memory at any given time. The term comes from educational psychology — specifically the work of John Sweller in the 1980s — but it maps directly onto software engineering.
There are three types of cognitive load relevant to engineering teams:
| Type | Definition | Example |
|---|---|---|
| Intrinsic | The inherent complexity of the domain you're working in | Understanding the business rules for loan eligibility |
| Extraneous | Complexity imposed by the environment or tools, not the domain | Figuring out why a Kubernetes pod is in CrashLoopBackOff |
| Germane | Effort that builds long-term skill and understanding | Learning how distributed tracing works so you can debug faster next time |
Platform Engineering's primary goal is to minimize extraneous cognitive load on application developers. Every hour a developer spends wrestling with infrastructure configuration is an hour not spent on the business problem they were hired to solve.
When a developer's cognitive load is exceeded, three things reliably happen:
- Delivery slows down: They spend more time figuring things out than building features.
- Quality suffers: Mistakes happen when people are overwhelmed and context-switching constantly.
- Burnout increases: It is exhausting to feel perpetually out of your depth.
The Platform Engineering Goal
A primary goal of Platform Engineering is to reduce extraneous cognitive load on application developers by abstracting away complex infrastructure tasks. The developer should be able to say "give me a database" and get one — without needing to understand VPC peering, IAM roles, or storage encryption settings.
But abstraction alone isn't enough. If you build a platform without thinking carefully about how teams are organized, you'll find that the complexity doesn't disappear — it just moves somewhere else, usually into endless cross-team meetings and unclear ownership.
This is where Team Topologies comes in: a framework for deliberately designing team structures to match the software architecture you want, with cognitive load as a first-class constraint.