You know that feeling. You stare at a pull request. It's not complex. But your brain refuses to parse it. You close the tab. Open Twitter. Repeat.
That's not burnout. That's cognitive debt. And according to a growing chorus of CTOs, it's the new technical debt — worse, because you can't refactor your way out of it.
What the Hell Is Cognitive Debt?
Technical debt is when you cut corners in code. Cognitive debt is when you cut corners in understanding. Every time a developer skips writing a clear comment, uses a cryptic variable name, or piles another abstraction on a shaky foundation, they're not just making the code worse. They're making the next person who touches it dumber.
Dan McKinley, former CTO of several startups, puts it bluntly: “Technical debt is a problem of code. Cognitive debt is a problem of people. And people are harder to fix.”
The term has been bouncing around engineering circles for a few years, but it's hitting mainstream now. The reason? Remote work. When you can't tap someone on the shoulder, the cost of cognitive load explodes. Every unclear function, every undocumented assumption, becomes a speed bump that can take hours to navigate.
“The worst code isn't the code that's buggy. It's the code that makes you spend 20 minutes to understand something that should take 2.” — Nina Patel, VP Engineering at Finstack
The Metrics That Matter
Most engineering orgs measure velocity — story points, pull requests merged, deployment frequency. Those numbers can look great while the team is drowning. Cognitive debt doesn't show up in Jira. It shows up in the Slack message that says “Can someone explain what this function does?” It shows up in the 30-minute meeting that could have been a two-line comment.
Kyle Simpson, author of “You Don't Know JS,” argues that the industry has fetishized cleverness. “We reward the person who writes the most elegant, terse solution. But that solution often requires a PhD to understand. The real skill is writing code that a junior dev can read on a Monday morning.”
The numbers back him up. A 2025 survey by Gartner found that 47% of developers spend more time deciphering existing code than writing new code. That's almost half their day spent on cognitive overhead. If you're a CTO, you're paying for that — in salary, in slowed feature delivery, in turnover.
Three Signs You're Already Infected
1. Onboarding takes forever. If your new hires take longer than two weeks to ship their first meaningful change, your codebase has cognitive debt. It's not that they're slow. It's that the system demands they learn a million implicit rules before they can be useful.
2. Your best engineers are bottlenecks. When only the original author can safely modify a module, you've got a cognitive monopoly. That's not job security — it's a single point of failure. If that person wins the lottery, your product is frozen.
3. Code reviews are theater. If every reviewer just rubber-stamps pull requests because the mental effort to actually understand the changes is too high, you've got debt. Real review requires cognitive energy. If your team doesn't have it, they're just clicking “Approve” and hoping for the best.
How to Start Paying It Down
The first step is admitting you have a problem. Then: measure it. Track how long it takes a developer to understand a module before making a change. Track the ratio of reading time to writing time. If reading takes longer, you've got debt.
Next, bake cognitive cost into your definition of done. Before merging a pull request, ask: “Can someone unfamiliar with this code understand it in under five minutes?” If the answer is no, the pull request isn't done. It's not about dumbing things down. It's about clarifying intent.
Finally, invest in documentation that lives. Not the kind that sits in a wiki and rots. The kind that's as close to the code as possible — comments that explain why, not what. Architecture decision records. Runbooks. The stuff that saves the next person from spelunking through Git history.
There's a reason the smartest CTOs are talking about this. It's not a fad. It's the realization that code is, ultimately, a communication tool. And right now, most of us are terrible at communicating.
So here's the hard truth: your team's productivity problem might not be technical debt. It might be that your code is making them stupider. And that's a problem you can't lambda your way out of.
