We Have More Important Things to Do Than Culture!

A few weeks ago, someone told me something that stopped me in my tracks. We were discussing the lack of team and company culture, and they said: “We have more important things to do! We first need to fix the processes and the systems before we can care about culture and these things.”

I’ve heard this in different variations throughout my career. Every time, it reveals the same fundamental misunderstanding: Culture is something you get to after the real work is done. A nice-to-have. A cherry on top once the org chart is clean, the processes are humming, and the product is stable.

That moment never comes. And the reason it never comes is often… culture.

Culture Drives the Work

Culture is not a benefit, an extra, or something you handle once the “real” problems are fixed. It shapes how the organization actually behaves.

Processes describe what should happen. Culture decides what people actually do, especially when things get uncomfortable. There will always be difficult situations: deadlines at risk, unclear requirements, leaders being wrong, or teams needing to compromise. Culture decides how people respond when the process stops being specific enough.

That is why culture work is part of execution. It affects whether it’s honest, fast, defensive, political, careful, or chaotic. Culture shows up in how code reviews are written, how deadlines are communicated, how failures are handled, and whether someone speaks up in a meeting or stays silent. No process is detailed enough to cover every decision an engineer makes in a day. Culture fills that gap. It scales in ways that you, as a leader, simply cannot.

Your “Process Problems” are Culture Problems

Most recurring pain points that engineering leaders fight look like process or systems failures on the surface. Often, they’re not. Here are four I’ve seen in almost every organization I’ve worked with:

Incident Response is Broken

You’ve written runbooks, set up PagerDuty rotations, defined escalation paths. Yet when something breaks, people downplay severity, hesitate to escalate, or quietly hope someone else notices first. That’s not a process gap. That’s a culture where raising the alarm feels risky.

The fix isn’t another runbook revision. It’s making honesty safe. Run your next postmortem about a leadership decision that went wrong, not an engineering incident. When the team sees leaders subjecting themselves to the same process, the signal is unmistakable. Pair that with a simple rule: anyone who escalates an incident that turns out to be a false alarm gets thanked, not questioned. Fear of overreacting kills response times faster than any missing documentation.

Delivery Keeps Slipping

Timelines are missed, scope creeps in silently, nobody flags it until it’s too late. The instinct is to introduce better estimation, tighter sprint planning, more check-ins. But often the real issue is that people don’t feel ownership over outcomes, or wait for permission instead of making decisions.

I’ve seen this pattern break when leaders do two things: First, make risk-flagging a rewarded behavior. Next time someone tells you early that a deadline is in danger, thank them publicly. Especially when the news is bad. You’re training the team on what gets rewarded. Second, push decision-making down. If a team needs your approval before adjusting scope, they’ll always wait too long to tell you scope needs adjusting. Give them clear boundaries and let them own the trade-offs within those boundaries.

Your Best People Keep Leaving

You can benchmark salaries, offer equity refreshers, throw in a learning budget. But if the day-to-day experience is blame, micromanagement, or apathy, people walk. A-players want to work somewhere they feel challenged, trusted, and respected. No perk replaces that.

Start with your 1:1s. Ask: “What’s one thing about how we work that you’d change if you could?” Then change one of those things. Visibly. Within a week. Do this consistently and you’ll learn more about your real culture than any engagement survey will tell you. Beyond that, look at what your org actually rewards. If promotions go to the loudest voices instead of the most impactful contributors, your best people will notice before you do.

Teams Operate in Silos

You restructure, introduce cross-functional squads, set up shared Slack channels. Nothing changes. Teams competing rather than collaborating, hoarding knowledge rather than sharing it: that’s cultural. No Jira workflow solves a trust problem.

What works is creating low-stakes situations where teams interact around real work. A shared demo session where teams present unfinished work to each other, not polished showcases. A rotating “office hours” where any engineer can ask questions to another team’s domain experts. A shared on-call rotation across service boundaries so people actually understand what other teams deal with. These aren’t big initiatives. They’re small, repeated touchpoints that build familiarity and trust across boundaries.

Every “system” and “process” fix you prioritize will succeed or fail based on the culture it lands in. OKRs, agile transformations, platform teams, new org designs: if the underlying culture resists it, it’s dead on arrival.

Leading Through Culture

If culture is this important, it can’t stay abstract. Here’s what shaping it looks like in practice.

Behaviors Over Values

Don’t announce “we value psychological safety.” That’s a poster, not a culture. Instead: the next time you’re wrong about something in a meeting, say so out loud. “I was wrong about the deadline estimate, here’s what I missed.” Do it once in front of the team and you’ve done more for psychological safety than a quarter of workshops.

Then make it structural. Sit down with your leads and write down the five behaviors you actually want to see. Not abstract values like “excellence.” Observable behaviors like “we flag risks the day we see them, not the day they become emergencies” or “we review PRs within four hours, and we ask questions rather than make demands.” Post them visibly. Reference them in retros. That’s how implicit norms become explicit agreements that people can actually hold each other to.

Hire and Fire

Culture is not what you aspire to. It’s what you tolerate. If someone is technically brilliant but consistently toxic, and you keep them because they’re “too valuable,” you’ve told your entire team what you actually value. That signal is louder than any all-hands presentation.

On the hiring side, stop treating culture fit as a vibe check. Build it into your interview structure. Ask candidates how they handled a disagreement with a colleague, how they gave critical feedback, or what they did the last time they were wrong about a technical decision. Listen for self-awareness and willingness to adapt. Technical skill without cultural alignment is a net negative at scale, because one person who undermines trust costs you more than the output they produce.

Your Rituals Shape Your Culture

Retrospectives, demos, 1:1s, standups: these aren’t just process. They’re the moments where culture is reinforced or eroded, every single week.

At your next retro, go first. Share something you would do differently. A retro where the leader is vulnerable builds a fundamentally different culture than one where everyone waits to see what’s safe to say. In code reviews, pay attention to tone. When you see a review that’s unnecessarily harsh, address it privately, the same day. When someone asks for help openly, recognize it. These aren’t minor details. They’re the building blocks that compound into “how things work around here.” The leaders who shape culture deliberately know that every meeting, every Slack thread, every PR comment is either reinforcing the culture they want or drifting toward the one they’ll regret.

The Honest Question

To anyone who says they have more important things to do than culture: look around. You already have one. It formed while you were busy “fixing” other things. And that unchosen, unmanaged culture is very likely the reason half of those “more important” problems exist in the first place.

Culture isn’t the work you do after you’ve fixed the organization. Culture is how you fix it.