We obsess about technical debt in our codebases. Refactoring, paying down shortcuts, cleaning up legacy code. But there's another kind of debt that's harder to see and just as costly.

When your team keeps solving the same problem the same way, that's cognitive debt accumulating.

Cognitive debt happens when teams become so homogeneous in how they think that they can't see alternative approaches. They optimise the same patterns, miss the same blindspots, and solve problems through the same mental models over and over.

It's like technical debt, but instead of messy code, it's messy thinking. And it compounds.

How I Learned This

I went from exhibiting art internationally to working as a designer, then UX engineer, software engineer, and eventually team lead.

Early in my role as a software engineer, my team built robust forms and pages showing large volumes of data. The engineers kept adding more information, because that meant better interface for them.

Users hated it. They found the pages overwhelming. Key highlights were buried in noise of all possible numbers.

The key question that was missing: "What decision are people trying to make right now?"

Eighty percent of the time, the answer was: "Get the trends and get on with my day"

We reorganised the entire interface around that single question. Same data. Different hierarchy. Adoption jumped.

The engineers were brilliant. They understood the technical requirements perfectly. But they all approached the problem the same way: show all the data, users will figure it out.

I saw it differently because of my design background. I asked a different question first. Not "what can we show?" but "what are people trying to do?"

That's what I mean by cognitive debt. When everyone on a team has similar backgrounds, they develop similar blindspots.

I've seen teams of backend engineers build their own UIs. They knew the system inside out. They used it daily without issues. Users were completely lost.

The engineers' defence: "It works fine. We use it."

Exactly. You use it. Because you built it. You know where everything is. You understand the mental model. Your users don't.

This isn't about intelligence. Everyone on that team was smart. It's about having only one way of thinking about problems.

What Different Backgrounds Actually Bring

When I started as a software engineer, I thought I needed to catch up on CS fundamentals. I was constantly aware of what I didn't know.

What I eventually noticed: there were things I could do that many CS graduates couldn't.

I could ship features users actually wanted because I'd done user research. I could run workshops that didn't make people zone out. I could give feedback that improved work without destroying confidence because art school critique training is brutal but constructive. I could build interfaces that felt intuitive because I thought about use-case before technical feasibility.

I wasn't behind. I had different tools. The team needed both types of thinking.

Former teachers understand how people actually learn, not just how to explain things. Designers think about whether something is confusing before thinking about whether it's technically possible. Project managers see dependencies and workflow issues that pure technical thinkers often miss.

The Warning Signs

Same problems keep recurring across different projects. Solutions feel repetitive even when the context changes.

I've noticed new hires with different backgrounds struggle to contribute their perspective - or worse, they stop trying after a few months. The team starts dismissing approaches as "not how we do things here." Everyone agrees too easily in planning meetings, not because the solution is obviously right, but because everyone's thinking about it the same way. User feedback consistently surprises the team.

I've seen all of these at various points. Sometimes I've been the problem.

What's Helped

When I hire now, I look for what thinking we're missing, not just what skills we need. I've learned to actually pause when someone suggests a different approach instead of immediately evaluating it against how we usually do things.

When someone says "users won't understand this," I've learned not to dismiss it as non-technical. There's usually a real disconnect there worth investigating.

I've spent a lot of time translating between how designers organise information and how engineers do. Both approaches have value. The tricky bit is understanding when to apply each. Sometimes you need to show all the data. Sometimes you need to hide most of it. Depends what decision someone's trying to make.

In interviews, I've stopped asking "How would you implement this algorithm?" and started asking "Walk me through how you'd approach this problem if you'd never seen it before." I'm not looking for the right answer. I'm looking for how people think when they don't already know the answer.

I also ask "Tell me about a time you had to solve a problem outside your area of expertise. What did you do?" because that reveals more about how someone works than asking about technologies they already know.

I ask "Tell me about a process that frustrated you and how you'd change it" because different backgrounds notice different problems. Someone from teaching might spot issues with how we onboard people. Someone from logistics might see workflow problems we've stopped noticing.

What I'm Still Learning

I still catch myself thinking "we should do X" before I've asked if there's another way to approach it. I still sometimes dismiss ideas too quickly because they don't fit how we usually work.

But I'm getting better at noticing when the team is stuck in a pattern.

Technical debt slows you down. Cognitive debt keeps you solving the wrong problems. And it's much harder to refactor how a team thinks than it is to refactor code.

I'm not saying hire artists to build databases or that technical skills don't matter. I'm saying when your entire team thinks about problems the same way, you've built a blindspot into your architecture. And those compound over time.