Yesterday's article framed developer experience as a multiplier on delivery speed. Today's article is about the specific mechanism behind that multiplier: cognitive load — the total mental effort a developer spends holding a system in their head well enough to work in it. It decomposes cleanly into three kinds, and only one of them is worth paying for.
Intrinsic load is the complexity inherent to the problem itself — the actual business logic, the actual algorithm. This is the load you want developers spending their attention on. Extraneous load is everything else: which CI/CD pipeline to use, which base image is approved, where the logs live, how to get access to a database. None of that is the problem a developer was hired to solve — it's tax paid just to get to the problem. Germane load is the effort of building durable understanding — internalizing a pattern well enough to reuse it without relooking it up every time.
Note
Platform engineering's entire value proposition, stated in one sentence: remove extraneous load, protect intrinsic load, and make germane load cheaper to acquire. Everything a platform team builds should be justifiable against one of those three.
What high extraneous load actually looks like
"Which CI/CD pipeline do I use?"
"Which base image?"
"Which cloud account?"
"How do I monitor this?"
"Secrets — where?"
"Which network?"
"Who do I ask for access?"None of these questions are hard in isolation. The cost is that they're all live in a developer's head simultaneously, competing for the same limited working memory that should be reasoning about the actual feature. More decisions, more context switching, more time to ship, more errors, more frustration, and — this is the part that compounds — more burnout, because none of that effort produced anything anyone can point to as progress.
The same system, two cognitive load profiles
| Without a platform (high load) | With platform engineering (low load) |
|---|---|
| Every tool choice is a live decision | Golden paths make most choices once, in advance |
| Constant context switching between infra and code | "I focus on code. The platform handles the rest." |
| More time to ship, more errors | Faster delivery, fewer mistakes |
| Frustration, eventual burnout | Developers stay in flow |
The phrase "stay in flow" isn't a soft HR concept here — it's a direct consequence of load. Flow state requires enough spare working memory to hold the actual problem in mind continuously; every extraneous decision that intrudes breaks it, and getting back into flow after an interruption costs real, measurable time, independent of how trivial the interruption seemed.
Where the load actually goes when a platform absorbs it
Self-Service Portal → replaces "which tool, and how do I even start"
Golden Paths → replaces "what's the right way to do this"
APIs & Services → replaces "how do these systems fit together"
Templates → replaces "let me rebuild this from scratch"
Docs → replaces "let me ask someone and wait"
Guardrails → replaces "did I just do something insecure"Each row on the right is a question a developer used to have to actively hold in mind and resolve. Each row on the left is the platform absorbing that question permanently, so it never enters working memory at all.
The reframe that matters
"We can't eliminate complexity" is true — some complexity is inherent to solving hard problems, and a platform shouldn't pretend otherwise. What platform engineering actually does is relocate complexity: out of every developer's head, into the platform itself, built and maintained once by people who specialize in exactly that problem.
Measured, not just felt
The real-world numbers organizations report after seriously investing in reducing cognitive load — 2-3x faster delivery, 40-60% less rework, higher developer satisfaction — aren't abstract claims about morale. They're a direct arithmetic consequence of developers spending measurably more of their day on the 20% of decisions that are actually specific to their product, instead of the 80% that are generic infrastructure questions every team was independently re-answering.
This is also the through-line connecting everything this phase of the series has covered: platform engineering (Day 19) is a product, not a rename of DevOps; platform teams exist specifically to remove friction (Day 20); the platform has to be built and iterated on as a product, not delivered once (Day 21); developer experience is the lens for whether it worked (Day 22). Cognitive load is the mechanism underneath all four — the actual thing being measured when any of those other concepts are said to be working or not.
Tomorrow's article covers the concrete capability that does the most direct work against extraneous load: self-service, and why "developers can get what they need without waiting on someone else" is the single highest-leverage feature a platform can ship.
