I’ve worked in places where the fire never stops, and in places where the fire went out years ago. Neither is healthy. One will burn you out. The other will quietly let you rust.

These are two faces of the same problem: a culture that’s failing its people and its purpose. It’s not just the productivity of the company the suffers. It’s the toll on the people inside the company, and how those patterns get built in.


The Human Cost

Illustration of two developers chatting at an office water cooler. Both wear glasses and have short dark hair and beards. One developer in a red shirt listens thoughtfully, while the other in a dark blue shirt gestures with one hand and holds a paper cup in the other. Speech and gear icons float above them, suggesting they’re discussing code and technical work.

Some culture problems don’t show up in the stand-up — you only hear about them at the water cooler.

Firefighting culture
There was one release day I’ll never forget and not because it was a triumph, but because it broke me. The software was barely held together. I knew it was bad. Everyone knew it was bad. Leadership pretended it wasn’t.

I went into the office, my daughter in tow because she wasn’t at school that day. The whole place was chaos. Teams calls with the customer to explain issues. My team asking me for direction. The customer asking me for answers. I was the lead on the project, and I was the one in the middle of it all.

At some point my body just gave up. My daughter found me lying on the bathroom floor, head over a toilet. I went home sick. The only time in my entire career that’s ever happened and it left me feeling like I had failed. She told me later how crazy it was, how many people just kept asking me questions while I was breaking down.

It wasn’t just that day. There were nights I stayed up until 2 or 3 a.m., hand-holding the same system through its overnight data processing. If it crashed, I was there to catch it. Heroics were the only plan we had.

I didn’t realise until afterwards how much it had taken from me, how short-tempered I’d become at home, how the constant pressure had rewired my patience, runined my sleep, and wrecked my ability to just relax.


Stagnant culture
On the flip side, the damage is slower but it’s still just as damaging.

In one role I was largely isolated in my day to day work. I worked on an upgrade the business-as-usual team doesn’t even know is happening. They’ll have to support it one day, but for now they’re in the dark.

The work is scoped to the bare minimum to hit a budget and a deadline, and that’s the story for every project. I’ve heard of project managers telling teams not to do anything outside what’s on the ticket. After years of that, you get developers who only do exactly what they’re told.

The signs are everywhere. TODO comments from over a decade ago. Entire classes commented out for 15 years. Unit tests that failed, so they were just disabled. New projects built in the same outdated architecture and style as those from a decade ago, essentially baking in tomorrow’s tech debt from day one.

People come and go. Knowledge isn’t transferred; it’s lost. Everything is siloed and if you don’t happen to bump into the one person who knows what you need, you’re out of luck.

For a while, it didn’t matter to me personally. I could see the problems, but they weren’t “my” problem. Then I realised it had been almost nine months without a single line of my code in production. Every turn has another hold-up, and no one is pushing the work forward. And then there’s the inevitable code freeze looming until after Christmas, it’s entirely possible nothing I’ve done will ever make it out.

It’s not that people don’t care. It’s that the culture has quietly trained them to give up.


What Great Cultures Do Differently

The healthiest environment I’ve worked in didn’t have a magic methodology or a silver bullet. What they had was trust.

We weren’t billing by the hour, so delivery wasn’t a constant negotiation about time spent. We were treated as a fixed-cost team, the company paid X, we delivered Y. There was no incentive to pad hours or argue over scope. Instead, there was an expectation that we’d do our best work, and the trust to back it up.

That trust went both ways. The wider organisation trusted us to deliver. Local management trusted the team to make good decisions. When we estimated a project at three months, the response was essentially, “See you in three months.” Of course, we stayed in touch along the way, but it was collaboration, not micromanagement.

Transparency was part of the fabric. Early on, salaries were flat across the team. We knew what things cost. We knew the vision for the company and the goals we were working toward. That openness changed somewhat over time, but the foundation it built lasted.

Leadership was rooted in servant leadership. Teams hired their own members. Decisions were often made by committee, which wasn’t always efficient but did give people ownership and autonomy. Developers had the freedom to try new technologies, refactor along the way, and work on improvements without having to lobby for permission.

Almost everything was optional. If you were in a meeting and it wasn’t giving or getting value for you, you could leave and no one batted an eye. The organisational structure was flat. People were treated as equals. For a while, we even had the “20% time” model, and it actually worked. That time led to real improvements and internal projects.

Our local leader worked alongside us. He wasn’t a figurehead in a separate office, he was part of the team. The pace was a marathon, not a sprint, which made it sustainable. And for a while, my role was essentially to make other developers’ lives easier. Refactoring code, building tools, and sharing knowledge.

It wasn’t perfect. Retrospectives, for example, weren’t particularly useful but we were free to adapt our own processes. That autonomy mattered more than following any prescribed framework.


The Messy Middle

Most companies aren’t pure panic or pure petrification. They live somewhere in the middle — with pockets of excellence and pockets of dysfunction.

You can have a great team operating inside a struggling organisation. A strong local leader can protect their people from the worst of the chaos, or quietly make space for improvement work even when the broader culture doesn’t. Sometimes those teams thrive for years in spite of the system around them.

You can also have bad habits hiding inside an otherwise healthy company. A single high-pressure project run badly can burn people out, even when everything else is sustainable. A leader in one corner of the org can create a climate of fear or apathy that’s invisible to those outside it.

Culture isn’t uniform. It can shift from one floor to another, or even between two teams sitting side by side. That’s why “we have a great culture here” can be true and false at the same time.

And it’s why you can’t always see a culture from the outside. Interviews, careers pages, even conversations with current staff will only ever show part of the picture. You have to live in it to see where the good and bad actually sit and how much each one matters.


Practical Principles

Culture can’t be “fixed” overnight, but there are things you can do whether you’re leading a team or just trying to survive in one.

If you’re in a leadership role

  • Make space for improvement work: One story per sprint dedicated to tech debt was small enough to fly under the radar but big enough to chip away at the problems that bugged the team most.
  • Protect 1:1s: Treat them as sacred. Use them for open, honest discussions and make it clear when you’re sharing personal opinion versus company policy.
  • Be transparent: Tell your team what you know, what you think will happen, and whether you’re guessing or certain.
  • Filter the noise: Shield the team from unnecessary corporate theatre so they can focus on building.

If you’re an individual developer

  • Spot the red flags early: Aptitude tests with 15-second timers before initial interviews, an obsession with timesheets, or rules that forbid even small code improvements are signs you may not thrive there.
  • Make it better every time you touch it: Even if you can’t clean the whole codebase, you can leave each file a little better than you found it.
  • Value every voice: A junior developer’s fresh eyes can be as valuable as a senior’s deep experience.
  • Find allies: In toxic environments, the bond with your teammates can be the thing that gets you through.
  • Know when you’ve outgrown it: It could be pay, learning, role, or simply mental health. At some point, you just know it’s time.

Leaving isn’t easy. Walking away from a toxic environment was the best thing I’ve done for my mental health, but it was hard to feel like I was abandoning my team. Still, staying would have meant more of the same. No culture is worth trading your well-being for.


Closing

Whether the damage comes from constant fire or years of neglect, the result is the same: a culture that fails its people and its purpose.

Great teams aren’t an accident. They’re built on trust, transparency, a sustainable pace, and they fight to protect those things even when the pressure’s on.

The worst cultures don’t set out to be bad. They get there one choice at a time, in what they reward, what they tolerate, and what they leave to rot.

The question isn’t which face your culture has today. It’s whether you’re shaping it, or letting it shape you.