Culture Debt Kills Faster Than Tech Debt

Someone would ask a question in a public Slack channel. Every so often a couple of people would start to answer. Then the manager would step in, say what was going to happen, and the thread would go quiet.

On its own, it looks like nothing. A decisive manager keeping things moving. But it was a team going quietly into debt, and the dead Slack thread was one of the interest payments.

You already know tech debt. You cut a corner in the code to ship faster, and you pay interest on it later in bugs, slow changes, and the one file nobody wants to touch. Culture debt works the same way, except the corners you cut aren't in the code. They're in the norms, the expectations, and the relationships that decide how people actually work together.

But tech debt is visible. You can see it, point at the file, write a ticket, argue about whether it's worth paying down. Culture debt is more dangerous because it gives you none of that. You don't watch it accruing. You see the symptoms, and by the time they show up, the debt has already compounded.

Let me tell you how a team I joined got there.

The reward was volume. The only thing that reliably got praised was pushing a lot of code. The manager was open about it...their whole framing of the job was being able to out ship anyone on the team. Everyone else stayed quiet. Nobody ever stood up and argued against quality. If you'd asked, the manager would have agreed that testing mattered and that quality mattered. Those things just never got prioritized. So over and over, what actually got rewarded (volume) quietly beat what everyone said they wanted. This didn't happen out loud. The reward silently won every time.

You can guess what that bought. Planning went first, so features shipped in half finished states and got abandoned there. Testing basically didn't exist. We had a QA person, but things slipped through constantly. Bugs were everywhere. Plenty of features barely worked, and some just didn't.

The human side hollowed out at the same time. People stopped speaking up in meetings. Those Slack threads kept dying. Engineers never got brought into conversations with other teams...one person owned every cross-team relationship. The few times I did talk to people on other teams, it was obvious none of them trusted what engineering shipped. The bugs, the missed timelines, the features that didn't solve their actual problem. They'd stopped believing us.

Why did it take hold? Because it was a small team. And on a small team, one person can be the entire culture.

There's no HR layer to buffer it, no competing management structure, no other org down the hall running a different norm. Whoever controls what gets rewarded sets the standard for everyone, immediately, with nothing to push back against it. At a big company a bad signal gets diluted across a dozen layers before it reaches you. On a small team there's nothing to dilute it. The manager valued volume, so before long, everyone optimized for volume.

The other reason it's so hard to catch is that every single corner disguises itself as speed. Skip the planning, we'll move faster. Skip the tests, we'll move faster. I'll just answer the question myself so we don't stall. I'll handle the cross-team stuff so the engineers can stay heads down and code. None of that announces itself as damage. It reads as hustle. And when you're small and underwater, hustle is exactly what you think you're supposed to be doing. You tell yourself you'll fix the culture stuff once you're bigger and have room to breathe.

So it stayed invisible for a long time. Where it finally showed up was the product...the bugs, the half-built features, the timelines that never landed, and the other teams who'd quietly stopped trusting what engineering shipped.

Trust is something that doesn't snap back. When it's gone, people leave...that part you expect. What you don't expect is that the ones who stay stop trusting the platform and stop trusting each other. Communication drops. Information gets hoarded. People get reluctant to back anyone else's idea. And the real conversations move out of the open and into private messages, where a decision made in public gets quietly downplayed or worked against. One missing norm, and you get all of that.

This is why I think culture debt kills teams faster than tech debt. Tech debt you can refactor on a schedule you control. Culture debt lives in trust, and trust doesn't refactor.

I got to watch the recovery too. That manager eventually left, and the team started climbing back out. The technical stuff came back first. Testing became the norm, planning got sharper, quality climbed. That part was almost mechanical...you decide to write tests, you write tests.

The human stuff took far longer. People learning to speak up again, to trust that answering a question in public wouldn't get them shut down, to believe a decision made in the open would hold. That took over a year. You can rewrite a module in a sprint. You rebuild trust one interaction at a time, and only if nothing knocks it back down in the meantime.

If you're leading a team, you can't ticket any of this, which is what makes it so easy to let slide. But there's one question that surfaces it early, and it's worth asking yourself honestly...”does what you actually reward match what you say you value?” Not the values painted on the wall, or included in some presentation. The ones that get praised in practice. If the only thing that earns praise is volume, your team already knows quality is optional...whatever the values page says.

And watch what goes quiet. When questions in a public channel stop getting answers, when nobody pushes back in a meeting anymore, when the same one person handles every hard conversation...that's the interest coming due.

That team didn't have worse engineers than anywhere else I've worked. It had a reward that quietly disagreed with its own values, and nobody noticed until it showed up in the product.