Keymaker

What culture looks like when no one is watching

Engineering culture is how a team behaves when the manager is not around. Not the values on the wall or the process doc, but what people actually do when no supervisor is there to steer them.

It is a loose definition, and deliberately so. But it is a useful lens for seeing why culture matters, and why it cannot stay frozen.

Why it matters

Three things happen when a team’s behavior no longer depends on someone supervising it.

The team is convinced, not commanded

If a behavior holds in the manager’s absence, it is self-driven. Nobody is dictating how things should be done. The team works that way because it genuinely believes that is how the work should be done.

No single point of failure

We say “manager,” but the influential person could just as easily be an architect or a senior engineer. When a team’s behavior depends on one strong personality, that person becomes a single point of failure. When the behavior is ingrained in the team itself, that dependency is gone.

Predictability under pressure

A team’s mettle is tested in the hard moments: a customer escalation, a major outage, a critical task against the clock. A team with a strong culture handles these with high ownership and predictable behavior. The response does not hinge on a particular process or a particular person being present, and that predictability helps the whole organization.

Principles are rigid, actions are not

Notice that I have not said what the right culture is. That is intentional. What counts as good or bad engineering culture is highly subjective, and I am not trying to define it.

What I care about is a different nuance. The principles behind a culture stay fixed, but the actions that express them must be free to change.

From cheetah to elephant

I bootstrapped a team and was one of its first engineers. We ran like a startup. Work-life balance was not really part of the conversation. People were passionate about getting things done, about engineering correctness, about programming languages. And it worked: we became a high-performing team.

Then times changed. The product matured, and so did the team. “We clock in late-night hours” stops being a badge of honor once your team includes people with family commitments. As you grow, you also need a mix of mindsets: some people who are thorough, others who are fast and agile.

Cling to the original culture and two things happen. You cannot scale, and you cannot attract the different kinds of talent a growing team needs.

So the culture has to evolve. A young team is a cheetah: highly agile, highly flexible, optimized for speed. A mature team needs to become more like an elephant: calculated, usually calm, and clear about when to push hard and when to stay still.

A flowing river, not a stagnant pond

Culture should be a flowing river that adapts as times change, not a stagnant pond. There is a meta point here too: being willing to change your culture is itself part of your culture.

I often come back to a line commonly attributed to Peter Drucker: “Culture eats strategy for breakfast.” My reading is simple. Get the culture right, and executing on your strategy becomes easy.