Eight years of leading engineering teams taught me that culture is the one variable that determines whether everything else works. Process, tooling, and even talent matter less than I thought. Culture is what holds it all together or quietly pulls it apart.

That sounds like a platitude until you have watched a sound strategy stall for the second time. Then it stops sounding like a platitude.

The Pattern I Kept Seeing

Early in my career, I assumed engineering excellence was a problem of inputs. I believed that better processes, better tools, and better people would produce better outcomes. So I optimized for inputs. I rewrote ways of working. I introduced frameworks. I fought for senior hires.

The results never compounded the way I expected. A team would adopt a new practice, sustain it for a quarter, and quietly drift back. A great hire would arrive, raise the bar for six months, and then start matching the bar of everyone around them. Whatever I changed on top, the culture underneath would absorb it, neutralize it, or reshape it into something it could tolerate.

Why Strategy Loses

Strategy is a set of decisions made in a room. Culture is what people do when no one is in the room.

You can write the cleanest engineering roadmap in the world. You can define non-negotiables. You can put rituals in place. None of it survives if the culture says "good enough is good enough," or "we don't push back on each other," or "ownership is somebody else's problem."

I have written roadmaps I am still proud of. They identified the right problems and proposed reasonable changes. What was missing was a culture capable of executing them. The roadmaps assumed a level of ownership and accountability that the culture did not yet support, and no document can will that into existence.

A strong culture can execute a mediocre strategy. A weak culture cannot execute a strong one.

What This Looks Like in Engineering

Code reviews are an obvious example. Every team has a code review process. Every team agrees that code reviews matter. The actual quality of reviews, the willingness to push back, and the depth of engagement are cultural. A team where senior engineers approve pull requests in two minutes to unblock the queue has a culture problem rather than a process problem. Adding a checklist will not fix that.

Ownership runs even deeper. You can say every engineer owns their work. You can write it in a handbook. Ownership is what people do when something breaks at 6 pm on a Friday. It's whether they fix it, escalate it, or quietly hope someone else will notice. No process produces that behavior. Either the culture rewards it, or it doesn't.

The Hard Part

You need a critical mass of people who carry the culture with you, who model it without being asked, and who hold the line when you're not in the room. Without that coalition, the leader becomes a single point of failure, and the moment they ease off, the culture snaps back.

The second-order effect is on the leader. Without that coalition, your energy goes to supervision, reminders, and correcting drift. With it, your energy goes to ambition, growth, and momentum. The job is fundamentally different in each case, and the culture you end up with reflects which one you spend your time on.

That's why most cultural change initiatives fail. They're run as projects with owners, milestones, and end dates. Culture doesn't work that way. It's the slow accumulation of what people decide to do, day after day, when the choice is theirs.

What I Do Differently Now

I invest in the coalition before I invest in the plan. I identify the people who already carry the right mindset, give them visibility and authority, and build the change with them rather than for them. The plan matters less than the people who will hold it up when things get hard.

I name the culture I want explicitly. Vague aspirations like "we want a culture of excellence" don't change behavior. Specific commitments like "we don't normalize red" or "we own outcomes, not tasks" do. That's part of why we introduced engineering non-negotiables: a defined set of practices every project must meet, no exceptions. The engineering non-negotiables make the baseline visible. They make it clear what good looks like and what isn't up for debate.

What Cultures Do

If your engineering organization isn't delivering what your strategy says it should, the temptation is to revisit the strategy. Sometimes that's the right move. More often, the strategy is fine. The culture underneath is doing what cultures do. It absorbs, it neutralizes, it reshapes. Until you change that, every new plan will meet the same fate as the last one.

Culture eats strategy. Engineering is no exception.