The Small Things That Build Engineering Culture

One of the most expensive engineering problems I've encountered wasn't a production outage.

It wasn't technical debt.

It wasn't even a bad architectural decision.

It was a flaky test.

Not because the test itself was important. In fact, nobody could remember why it existed.

The problem was what happened afterwards.

Over time, the test failed often enough that we stopped trusting it. We would rerun the pipeline and call it a day. We stopped paying attention to failures. Eventually, a red build no longer meant anything.

Nobody decided this would happen. It just did.

Yet within a few months, an entire team had collectively learned the same lesson:

A failing build is just noise.

At that moment, the flaky test stopped being a technical problem.

It became a cultural one.

The Problem Isn't Awareness

We like to believe broken things stay broken because nobody noticed.

That's not what happens.

Not because they didn't care.

Because the sprint was full.

Because fixing a flaky test doesn't ship a feature. Features are what get rewarded.

Nobody decided the flaky test should stay broken. But nobody decided it should get fixed either. And in the absence of a decision, the default wins.

The broken things stay broken because the system has no mechanism for caring about them.

Sprint planning doesn't have a ticket for "make the team's daily experience less painful".

Performance reviews don't reward "fixed the thing nobody complained about loudly enough".

Roadmaps don't include "stop wasting 20 minutes every deploy".

So the flaky test stays.

The deploy script stays.

The broken onboarding stays.

And the team learns, quietly, what the organization actually values, regardless of what's written on the wall..

What we are actually teaching

Here's the uncomfortable part: you're already building culture.

You're just not choosing what you're building.

Every broken thing your team tolerates is a lesson.

A flaky test nobody fixes, teaches engineers that quality is negotiable.

A painful deploy process that nobody owns, teaches them that their time isn't valued.

An onboarding experience that wastes weeks, teaches new hires what standards to expect, and those standards are lower than you think.

I call this cultural debt.

Cultural Debt

We talk a lot about technical debt.

I think cultural debt can be more dangerous.

Technical debt accumulates when we take shortcuts in software.

Cultural debt accumulates when we repeatedly tolerate.

Individually, these problems seem minor.

Collectively, they teach people what standards actually are.

The danger is that cultural debt compounds.

A slow deployment process doesn't just waste time.

A broken onboarding experience doesn't just frustrate new hires.

Eventually, people stop believing improvement is possible.

Eventually, people stop expecting things to be better.

This is no longer a technical problem.

It is a cultural one.

But here's the part nobody talks about: the same mechanism works in reverse.

If culture can be shaped by small tolerances, it can also be shaped by small improvements.

A flaky test teaches engineers that quality does not matter.

Fixing it teaches them that it does.

A broken onboarding process teaches new hires what standards to expect.

Improving it teaches them that high standards matter.

Culture accumulates through small experiences, whether we intend it to or not.

The question is what those experiences are teaching.

One Small Thing at a Time

I used to think leadership was primarily about vision.

Setting direction.

Inspiring teams.

Painting the big picture.

But the biggest cultural shifts I've witnessed came from something much simpler.

Fixing the things people had given up on.

The broken script.

The manual process.

The recurring deployment issue.

The dashboard nobody trusted.

Something interesting happens when enough of these small fixes accumulate.

People start paying attention.

They start noticing that things are getting better.

They start trusting that things can improve.

Not because of a speech.

Not because of a new initiative.

Because they have seen evidence.

Trust is rarely built through declarations.

It is built through accumulated experience.

Excellence Is a Byproduct

Most organizations chase excellence directly.

I've never seen that work particularly well.

The best engineering teams I believe weren't those obsessed with excellence.

They were obsessed with eliminating friction.

They fixed things.

Constantly.

Small things.

Boring things.

Unimportant things.

And also.. quietly.

Over time, those small improvements accumulated into something that looked like excellence from the outside.

That accumulation is how good culture is built.

Not through a manifesto.

Not through a values statement.

Not through a transformation program.

One small thing at a time.

Technical debt slows systems down. Cultural debt changes what people believe is normal.

The first can usually be measured. The second often goes unnoticed until it is deeply embedded.

By then, the problem is no longer the flaky test, the broken onboarding flow, or the painful deployment process.

The real problem is that people stop expecting those things to improve and start accepting them as normal.

And once that happens, you're no longer fighting technical debt.

You're fighting culture.