Culture Is the Operating System: How Engineering Leaders Build, Scale and Renew Great Teams

If your culture only works when twelve people are in the same Slack channel, it isn’t a culture. It’s a group chat with payroll.

There’s a particular kind of magic in a five-person engineering team. Everyone knows everything. Decisions happen in the corridor. The codebase is small enough to hold in your head, and so is the organisation. Then you hire person number six, and the magic starts to wobble. As it grows further, by person sixty, the corridor has become a confluence of Slack channels, and somebody is seriously proposing that you “better start documenting your values.”

This essay is about that journey. The journey from the founding team’s handful of engineers to a mature organisation that still feels like a place where the best people want to stay.

A recent announcement at work impacted my life in a rather unexpected way. Mid July, 2026, the CEO of Kaluza, Stephen Fitzpatrick, announced that the organisation needed to make around 150 roles in the UK redundant. The company decided to close their office in Portugal too, which was always something I knew was coming as there were rumours. This was accompanied by other upcoming changes, like 3-days-a-week Return to Office mandate by January 2027, reduced sickness leave, and other things, including a performance-based culture. I still don’t clearly understand what that last one means as great performance is a result of certain ingredients that I’ll discuss later in the article. This announcement affects my role as my role is being made redundant. Anyhow, what struck me was how the culture of the company has evolved since the early days when I started, to what it is today. From inclusive to almost very exclusive. This prompted me to understand such cultural evolution at organisations and go on a reading spree intending to nail a playbook to evolve a good culture as a company grows. It’s written for people like me, in engineering leadership roles, as I have observed some to mistake architecture or team topology for culture and vice versa. I’ll borrow the best thinking from organisational research, translate it for software people.

The thesis is simple: culture is a leadership product, and you build it the way you build software — deliberately, iteratively, and with the occasional outage. - As illustrated in the cover image.

The journey at a glance

  %%{init: {'theme': 'base', 'themeVariables': {'fontFamily': '"Segoe Print", "Bradley Hand", "Comic Sans MS", cursive', 'primaryColor': '#fff6d8', 'primaryTextColor': '#1d1d1d', 'primaryBorderColor': '#3a3a3a', 'lineColor': '#4d4d4d', 'secondaryColor': '#eef8ff', 'tertiaryColor': '#f8efe7'}, 'flowchart': {'curve': 'basis', 'nodeSpacing': 28, 'rankSpacing': 40}}}%%
flowchart LR
    A["Startup<br/>0–20"] --> B["Scale-up<br/>20–200"]
    B --> C["Mature<br/>200+"]
    A -->|Founder behaviour| D["Culture by osmosis"]
    B -->|Systems & managers| E["Culture by design"]
    C -->|Renewal & dissent| F["Culture by migration"]
    classDef stage fill:#fff6d8,stroke:#3a3a3a,stroke-width:2px,color:#1f1f1f,stroke-dasharray:5 6;
    class A,B,C,D,E,F stage;
    linkStyle default stroke:#4d4d4d,stroke-width:2px,stroke-dasharray:6 6;

What I actually mean by “culture”

Before I go further, let’s define it. Edgar Schein, the MIT Sloan scholar who more or less founded the academic study of organisational culture, describes it at three levels (MIT Sloan):

1. Artefacts: the visible, audible stuff. Office layout, dress code, the fact that everyone uses Linear or Jira, the legendary story of the great production fire of 2023.
2. Espoused values: what the company says it believes. The mission statement, the principles doc, the slide that says “Own the outcome.”
3. Basic underlying assumptions: the unconscious, taken-for-granted beliefs that actually drive behaviour. “If I break production, my manager will help me, not punish me.” Or, darker: “Disagreeing in a meeting is career-limiting.”

The trap is that most companies obsess over levels one and two, i.e. the posters, the values on the internal wiki and the company website, while completely ignoring level 3. Schein’s point is that level three is where the real culture lives, and it’s mostly invisible to the people swimming in it. As he put it, these assumptions “determine behaviour, perception, thought, and feeling”. In software terms, the runtime that everything else runs on.

So when I say “culture,” I don’t mean beanbags and free lunch, or coming to the office 3 days a week while you work from home the other days.

Even Netflix, of all companies, says it plainly: “what makes a fantastic workplace isn’t a great office or free meals and massages; it’s the people” (Netflix Culture Memo). Culture is the system of repeated behaviours, incentives, rituals, stories and trade-offs that determines what people actually do when nobody is watching — especially when the founder is NOT in the room.

For engineering leaders, that means culture is concrete, not fluffy. It lives in:

• How code review actually works (not how the README says it should).
• What happens when someone pages the on-call at 0300am.
• Who gets promoted, and what that tells everyone about what’s valued.
• How a bad idea gets killed, and whether the person who raised it now suffers from PTSD.
• Whether “we ship quality” survives a quarter when the board wants a number moved.

Essentially, if you want to know your culture, reading your values page won’t get you anywhere close. Attending incident post-mortems, town-halls, reviewing recent promotions, reviewing recent exit-interview feedback, etc. will teach you a lot. Those are your real artefacts.

The Culture Code: three skills that form the foundation of culture

Before I delve into the stage-by-stage playbook, I’d like to cover another piece of research that holds across all of them.

In The Culture Code, Daniel Coyle distils strong cultures into three skills: build safety, share vulnerability, and establish purpose (danielcoyle.com).

The crucial, counter-intuitive part is the middle one: vulnerability.

Leaders who admit a mistake first create the permission for everyone else to do so. That finding aligns well with Google’s famous Project Aristotle, which studied 180+ teams over two years and concluded that “who is on a team matters less than how the team members interact, structure their work, and view their contributions” — and that psychological safety was “far and away the most important” of the five dynamics that separated great teams from the rest (re:Work, Google).

So what that means is:

Values on a wall are not culture. They are interior decoration with ambition.

Keep that distinction in your back pocket. We’ll need it at every stage.

Culture as a layered operating system

  %%{init: {'theme': 'base', 'themeVariables': {'fontFamily': '"Segoe Print", "Bradley Hand", "Comic Sans MS", cursive', 'primaryColor': '#fff5d3', 'primaryTextColor': '#1d1d1d', 'primaryBorderColor': '#3a3a3a', 'lineColor': '#4d4d4d', 'secondaryColor': '#edf6ff', 'tertiaryColor': '#f9efe4'}, 'flowchart': {'curve': 'basis', 'nodeSpacing': 26, 'rankSpacing': 32}}}%%
flowchart TB
    A["Artefacts<br/>rituals, tools, office layout"] --> B["Espoused values<br/>mission, principles, slogans"]
    B --> C["Underlying assumptions<br/>fear, trust, dissent"]
    C --> D["Behaviours<br/>what people actually do"]
    D --> E["Outcomes<br/>quality, speed, retention"]
    C -. drives everything .-> A
    classDef layer fill:#fff4cf,stroke:#3a3a3a,stroke-width:2px,color:#1f1f1f,stroke-dasharray:5 6;
    class A,B,C,D,E layer;
    linkStyle default stroke:#4d4d4d,stroke-width:2px,stroke-dasharray:6 6;

The Startup: Founder & Leadership behaviour under pressure

In the earliest days, you don’t really have a culture programme. You are the culture. Whatever you do on a stressed afternoon is being carefully studied by your peers and first engineers, copied, and eventually laminated into “how we do things here.” This is fantastic when you think about it but also a hazard. This is why it is extremely important to be deliberate about what you model and who you partner with in the organisation in the early days.

  %%{init: {'theme': 'base', 'themeVariables': {'fontFamily': '"Segoe Print", "Bradley Hand", "Comic Sans MS", cursive', 'primaryColor': '#fff5cf', 'primaryTextColor': '#1d1d1d', 'primaryBorderColor': '#3a3a3a', 'lineColor': '#4d4d4d', 'secondaryColor': '#eef7ff', 'tertiaryColor': '#f8efe7'}, 'flowchart': {'curve': 'basis', 'nodeSpacing': 24, 'rankSpacing': 28}}}%%
flowchart LR
    A["Founder behaviour"] --> B["Shared signals"]
    B --> C["Small rituals"]
    C --> D["High trust"]
    D --> E["Fast decisions"]
    E --> F["Low process<br/>high dependence"]
    A -->|risk| G["Heroics can become the norm"]
    classDef startup fill:#fff5cf,stroke:#3a3a3a,stroke-width:2px,color:#1f1f1f,stroke-dasharray:5 6;
    class A,B,C,D,E,F,G startup;
    linkStyle default stroke:#4d4d4d,stroke-width:2px,stroke-dasharray:6 6;

What to do

Hire for the slope, not for trophy

What exactly is “Slope”? It is a candidate’s rate of growth — how fast they learn, adapt and improve — as opposed to “trophy,” the fixed, static credentials on their CV: the degree, the brand-name employer, the job title. In a startup, the single most expensive mistake is hiring a toxic member into the founding team. Early hires - or founding team are those that develop into force-multipliers. Their behaviours, standards and expectations shape that of the next group of hires and so on.

This is where the test is not just about aptitude and competence but also about integrity and the will to learn fast. A shiny CV that has multiple world class companies listed as previous employers only tell me one thing - the person is great at interviews. The reality is that in a startup, especially in the early phase, it is all about experiments and uncertainty. Fundamentally it is about survival and ownership of outcomes. One toxic high-performer, can entirely destroy a startup. Their negative influence could repel the good members of the team thus causing more cultural damage what the startup can handle.

Make the “how we work” explicit before it has to be

Unwritten standards and expectations means you are opening the floor for interpretations. It is wishful thinking that everyone will just follow the good behaviours as the early team have done so far.

If you haven’t already, then please write down your engineering principles while the team/organisation is still small enough. Some starters that help any engineering team:

• Code review process
• How to do a release
• Quality standards and gates
• decision logs
• Post-mortem templates
• Solution design and review process

and so on.

I am not asking you to do this because an engineering leader is meant to be a process person. This is crucial because writing things down is how you find out whether they’re real and how they evolve. Schein would call this surfacing the assumptions before they fossilise (MIT Sloan).

Make this a habit for every new team process. That becomes your way of working and it evolves into your culture.

Model the vulnerability you want

Over the years, I have had the opportunity to work with people who admit and own their mistakes, but I’ve also worked with those who hide their mistakes or try and redirect the blame. But the impact that a leader creates by admitting their mistake is significant and often lasting. It is a power signal to the team that it is alright to make mistakes, so long as one learns from the mistake. That’s my rule.

We all make mistakes. But once we make one, we have to learn from it and take measures to prevent it from happening ever again.

Coyle’s research on vulnerability is unambiguous. The leader going first about what they got wrong and sharing what they learned is the best way to build trust and psychological safety (danielcoyle.com).

Reward truth-telling over heroics

What I have observed over my career working in smaller companies starting up, is that “hero culture” is prevalent. The person who pulls an all-nighter to ship a fix or migrate a legacy thing is celebrated even if it was completely avoidable. Nobody learns from a retrospective that the entire episode was avoidable had we done sufficient planning. If this is repeated often or even a couple of times, the team learns that heroics beat planning - the culture starts to evolve into - deploy now, fix later, we don’t have to time to plan.

I must stress that when there are genuine emergencies, such heroic efforts maybe necessary. In such circumstances, leaders must not fail to recognise the effort and thank the people involved using appropriate compensation and sufficient time-off to recover from the inconvenience. But it is important to be clear about the narrative. The accomplishment here is not that someone worked through the night but rather the fact that we were able to recover our systems from a difficult situation rather quickly.

So while you celebrate those who stepped up to handle emergencies, celebrate those who help prevent such disasters in the first place. So when releases are successful and incident free or uneventful, praise the team for the planning and execution that went into it - this is equally important. You get more of what you reward; this is not complicated.

The right incentives shape the culture more than any values poster ever will.

The starter kit

• A one-page engineering principles doc.
• A decision log (so you can remember why you chose the thing you now regret).
• A blameless incident review template — used from day one, before you have incidents that matter.
• A hiring checklist that includes cultural signals, not just technical bars - mindset and not just the technical skill-set.

Stage 2 — Scale-up: from osmosis to operating system

Here’s the uncomfortable truth about scaling: everything that worked by osmosis now needs an explicit transmission mechanism.

What I have learned from experience is that at fifteen people or so, culture travels by overhearing. At a hundred and fifty, the people on the third floor have never met the founder or founding members, and “how we do things” is whatever their team lead says it is. This is the stage where most companies either institutionalise their culture or accidentally replace it with PowerPoint. You might be familiar with these presentations.

What to do instead to scale your culture with your organisation

  %%{init: {'theme': 'base', 'themeVariables': {'fontFamily': '"Segoe Print", "Bradley Hand", "Comic Sans MS", cursive', 'primaryColor': '#eaf5ff', 'primaryTextColor': '#1d1d1d', 'primaryBorderColor': '#3a3a3a', 'lineColor': '#4d4d4d', 'secondaryColor': '#fff5d8', 'tertiaryColor': '#f7efe5'}, 'flowchart': {'curve': 'basis', 'nodeSpacing': 24, 'rankSpacing': 30}}}%%
flowchart LR
    A["Founder absent from room"] --> B["Manager enablement"]
    B --> C["Decision rights"]
    C --> D["People systems"]
    D --> E["Standard rituals"]
    E --> F["Autonomy + clarity"]
    B -->|risk| G["Decision gridlock"]
    D -->|risk| H["Management theatre"]
    classDef scaleup fill:#eaf5ff,stroke:#3a3a3a,stroke-width:2px,color:#1f1f1f,stroke-dasharray:5 6;
    class A,B,C,D,E,F,G,H scaleup;
    linkStyle default stroke:#4d4d4d,stroke-width:2px,stroke-dasharray:6 6;

Convert values into systems

Patrick Lencioni’s argument in The Advantage is that “organizational health trumps everything else” and that health is built through four disciplines:

• build a cohesive leadership team
• create clarity
• over-communicate clarity
• and reinforce clarity through your people systems — hiring, onboarding, performance, rewards and firing (Table Group)

Apparently, the last one is what engineering leaders skip.

If your promotion process rewards “individual heroics” but your values page says “we win as a team”, your values page is lying and everyone knows it.

So as an engineering leader, make time to build the right people systems working with the relevant HR or people team members.

If you are a founder or a CTO, this is the time to hire a Head of People who can help you build these systems. The cost of not doing this is high: the best engineers will leave, and the ones who stay will be the ones who are good at navigating politics, not building software.

Introduce management without “management theatre”

Your first managers are usually your best engineers, promoted because they were good at something else and given no training in the new job. The result is either a micro-manager (they miss the code) or an absent landlord (they’re afraid to lead).

I follow this principle that Netflix uses. The framing is: managers should practise “context, not control” — give teams the context to make good decisions and the clarity to know what good looks like, then get out of the way (Netflix Culture Memo). Context-not-control is not hands-off; it’s actively coaching and stepping in only at the boundaries of ethics, material risk, and crisis. I swear by this approach, especially when I have more than one team to manage. I do not need to know every detail of everything that my team does because I trust my engineers to figure things out. In order to create leaders, I have to step back and let them make decisions, even if they make mistakes. What I must do is I have to be clear about the boundaries and the context, and then let them operate within that. This is how you build a culture of ownership and accountability.

Clarify decision rights before they cost you

One of the most reliably expensive scale-up ailments is decision gridlock — everything escalates to the founder because nobody knows who’s allowed to say yes. I love Netflix’s solution to this: the “informed captain” — for every significant decision, one person is responsible for the call, and they’re expected to “farm for dissent” first and “disagree then commit” afterwards (Netflix Culture Memo). The phrase to internalise is “highly aligned and loosely coupled” — clear on the destination, free on the route.

However, choosing the right informed captain is a skill in itself, and one that requires a culture of psychological safety to work. If the captain is afraid to hear dissent, or if dissenters are afraid to speak up, the system fails.

Intentional design of rituals

Culture is carried by rituals — standups, demos, retros, incident reviews, the Friday demo. The trick is to keep the ones that carry meaning and ruthlessly retire the ones that have become cargo cult.

As an example: a retrospective that nobody acts on is worse than no retrospective, because it teaches the team that speaking up is pointless.

Katzenbach’s research on culture change makes the point sharply: “focus on a few critical shifts in behaviour” rather than trying to transform everything at once, and “integrate formal and informal interventions” — don’t just publish a new process and hope (Cultural Change that Sticks - Katzenbach, Steffen & Kronley, HBR, 2012).

Watch the architecture, because it shapes the culture

This is the engineering-specific insight that the business books miss.

Conway’s Law — the observation that a system’s architecture tends to mirror the communication structure of the organisation that built it — means your team topology can drive your culture, writ in code (Team Topologies).

If you want autonomous teams, you need service boundaries that permit autonomy. If you want a blameless culture, your architecture has to make failures recoverable rather than catastrophic. DORA’s multi-year research programme is unambiguous on the link: in 2022 they found “the biggest predictor of an organisation’s application-development security practices is cultural, not technical,” and as far back as 2014 that “DevOps is a cultural shift, not just technical practices” (DORA).

The scale-up health check

• Can a team ship a change to production without asking three people for permission?
• Do your last five promotions tell a consistent story about what you reward?
• Does a new engineer know how to disagree with their manager within their first week?
• When was the last time you removed a meeting, rather than adding one?

If you can’t answer these quickly, your culture is now running on folklore, and folklore doesn’t scale.

Stage 3 — Maturity: renewing without repudiating

Apparently this is the hardest stage. The company is successful, the founders are wealthy, the original engineers are now Staff-and-above, and somebody in a town-hall has just said the words “we’ve lost our startup culture.” The instinct is to panic — to launch a culture-change programme, hire a Head of Culture, and print new values onto the wall of the new, bigger office. Hold your horses.

How to renew culture without betraying the people who built it

  %%{init: {'theme': 'base', 'themeVariables': {'fontFamily': '"Segoe Print", "Bradley Hand", "Comic Sans MS", cursive', 'primaryColor': '#f8efe6', 'primaryTextColor': '#1d1d1d', 'primaryBorderColor': '#3a3a3a', 'lineColor': '#4d4d4d', 'secondaryColor': '#eef7f0', 'tertiaryColor': '#fff4d6'}, 'flowchart': {'curve': 'basis', 'nodeSpacing': 24, 'rankSpacing': 30}}}%%
flowchart LR
    A["Legacy people"] --> B["Legacy behaviours"]
    B --> C["Old incentives"]
    C --> D["Dual-running rituals"]
    D --> E["Guardrails"]
    E --> F["New norms"]
    F --> G["Renewed culture"]
    A -->|protect, don't erase| H["Real IC track"]
    D -->|with dissent| I["Farming for disagreement"]
    classDef mature fill:#f8efe6,stroke:#3a3a3a,stroke-width:2px,color:#1f1f1f,stroke-dasharray:5 6;
    class A,B,C,D,E,F,G,H,I mature;
    linkStyle default stroke:#4d4d4d,stroke-width:2px,stroke-dasharray:6 6;

Don’t declare war on the people who got you here

The classic, tragic mistake at maturity is to treat the early engineers as “legacy”. The implication being that they’re the problem. Katzenbach’s first principle of culture change that sticks is to “honor the strengths of the existing culture”: “every culture is the product of good intentions and has strengths; put them to use” (Cultural Change that Sticks - Katzenbach, Steffen & Kronley, HBR, 2012). People who survived the founding era aren’t obstacles to the new culture; they’re its custodians. The behaviours that need to change are not the same thing as the people, and conflating the two is how you lose your best early talent to a competitor who’ll treat them better. However, I have seen companies that deliberately express the desire to change their culture. In this case, they will inevitably get rid of some of the early team, by treating them as legacy. If this is deliberate, so be it. Maybe that is the right decision for the company based on their context.

Give your veterans a real future

Early engineers often leave not only because of money, but because they lose influence, autonomy, or a meaningful technical future. The only path forward can seem to be “become a manager”, which many of them don’t want and shouldn’t have to want. Build a serious individual-contributor and technical-leadership track — with the pay, influence, and respect to match — and you reduce a major retention risk while signalling that technical excellence remains valued. People stay where they can do the best work of their lives and keep growing.

Renew the rituals, don’t freeze them

A mature culture calcifies when its rituals become performative — the retro that’s been run the same way for five years, the town hall nobody asks questions in. Lencioni’s discipline of “reinforce clarity” is not “engrave it in stone”; it’s “keep embedding it in the systems that govern daily life” (The Healthy Organisation). The systems change as the company changes; the principles don’t have to. I think this is where continuous improvement matters. I align and agree with Netflix’s view: they work to constantly improve its culture, “not preserve it” (Netflix Culture Memo).

Separate “legacy people” from “legacy behaviours”

This is the single most important distinction at maturity. An early engineer who still deploys the way they did in 2019 isn’t a problem person — they’re responding rationally to the incentives and architecture you built. Change the architecture, i.e. change the incentives, and the behaviour follows. Punishing the person while leaving the system intact is both unfair and ineffective.

Farm for dissent

The bigger the organisation, the more filtered the truth becomes on its way to the leader. I have experienced this many times over in a scale up. Netflix’s practice of “farming for dissent” — actively seeking out disagreement, especially from people lower in the hierarchy — is how you keep from ruling a mirage (Netflix Culture Memo). Pair it with Edmondson’s insight that psychological safety is built “team by team,” not by edict from the top (Berkeley Haas). A psychologically safe executive team is not the same as a psychologically safe organisation; you have to build it where the work happens.

How to renew culture like a migration, not a rewrite

A good culture change looks like a zero-downtime migration, not a rewrite-from-scratch. You don’t take the old system offline and then start praying and hoping things will get better.

  %%{init: {'theme': 'base', 'themeVariables': {'fontFamily': '"Segoe Print", "Bradley Hand", "Comic Sans MS", cursive', 'primaryColor': '#fef0cb', 'primaryTextColor': '#1d1d1d', 'primaryBorderColor': '#3a3a3a', 'lineColor': '#4d4d4d', 'secondaryColor': '#edf8f0', 'tertiaryColor': '#f7efe5'}, 'flowchart': {'curve': 'basis', 'nodeSpacing': 30, 'rankSpacing': 38}}}%%
flowchart LR
    A["1. Run both in parallel"] --> B["2. Add guardrails"]
    B --> C["3. Cut over gradually"]
    C --> D["4. Keep rollback path"]
    A -->|pilot one team| E["Learn from evidence"]
    E -->|scale what works| C
    classDef migration fill:#fef0cb,stroke:#3a3a3a,stroke-width:2px,color:#1f1f1f,stroke-dasharray:5 6;
    class A,B,C,D,E migration;
    linkStyle default stroke:#4d4d4d,stroke-width:2px,stroke-dasharray:6 6;

What you do instead is:

1. Run both in parallel. New behaviours and old behaviours coexist while people learn.
2. Add guardrails. Make the new way easier than the old way — tooling, defaults, and prompts that nudge toward the desired behaviour.
3. Cut over gradually. Move one team, one practice, one ritual at a time. Prove it works, then expand.
4. Keep the rollback path open. If a new ritual isn’t working, you can revert it. This is a feature, not a failure.

An exaggerated example of a culture migration: from “blame the deploy” to “blameless review.”

Picture a hundred-and-fifty-person engineering org, five years old, still running its incident process the way it did at fifteen people: whoever shipped the change that broke production writes the postmortem, alone, and reads it out to a room that’s already decided whose fault it was. It worked when the founder wrote most of them herself. Now it means every incident review is a trial, engineers quietly stop deploying on Fridays, and the best people avoid touching the scariest parts of the codebase — exactly the parts that most need attention.

A senior engineering leader decides this has to change, but doesn’t send a memo announcing “we are now blameless” and hope the culture obeys. Instead:

• Run both in parallel. She picks one team — the payments team, who’ve had the worst of it — and asks them to trial a new format: the reviewer facilitates, the person who shipped the change co-writes the timeline rather than defending it, and the write-up ends with “contributing factors,” not “root cause.” Every other team keeps their existing process for now.
• Add guardrails. She builds the new format into the incident tool itself as a template, so the blameless structure is the path of least resistance, not an extra step someone has to remember. She sits in on the first three reviews herself and models it: “I approved that deploy without asking enough questions — that’s on me too.”
• Cut over gradually. After six weeks, the payments team’s reviews are visibly more useful — more contributing factors surfacing, more systemic fixes shipped, fewer repeat incidents. She shares the write-ups (with names softened) at the engineering all-hands, not as a mandate but as evidence. One team adopts it that month because they want the same outcome. Three more follow over the next quarter.
• Keep the rollback path open. One team tries it and finds the new format too heavyweight for their smaller, lower-stakes incidents. Rather than forcing it, she works with them to build a lighter variant — same principle, less ceremony — and that becomes the template others use for minor incidents. The rollback isn’t abandonment; it’s data that feeds the next iteration.

Eighteen months later, the org-wide postmortem archive shows a different pattern entirely: repeat incidents are down, “contributing factors” sections with multiple names and systemic causes rather than one name and a typo, and — the tell that it’s really landed — junior engineers volunteering to write up their own incidents instead of dreading the summons.

Nobody declared culture change. She migrated one behaviour, on one team, with a working example instead of a slogan, and let the results do the recruiting for the next team’s buy-in.

Katzenbach’s closing principle is “measure and monitor cultural evolution” — “otherwise you can’t identify regression or correct course” (Cultural Change that Sticks - Katzenbach, Steffen & Kronley, HBR, 2012).

The culture refactoring playbook

At a high level, the pattern is consistent. The operating mechanism changes with the stage of the company, but the underlying principle stays the same: make the culture legible, then make it repeatable.

A closing note on measurement

Engineering leaders love a metric, and the culture industry has obliged with a glut of vanity ones — engagement-survey scores, eNPS, “number of values workshops held.” These measure activity, not culture. DORA’s research points at the better signal: the sociotechnical system itself. Their finding that culture is “the biggest predictor” of security practices, and that transformational leadership “fosters a culture of high performance,” tells you where to look (DORA). Don’t measure whether people feel engaged. Measure whether bad news travels fast, whether failures are recoverable, and whether the people who built the place are still building it three years on.

Those are your real culture metrics. Everything else is a dashboard with ambition.

Where to read deeper

This essay leans on a small number of foundational works. If you want to go deeper — and you should — here’s the reading order I’d recommend, with why each matters for an engineering leader:

• The Culture Code — Daniel Coyle. The fastest, most practical introduction to how cultures actually get built. Read it first (danielcoyle.com).
• Organizational Culture and Leadership — Edgar Schein. The academic cornerstone. Dense, but it’s the source nearly every other book quietly borrows from (MIT Sloan).
• The Advantage — Patrick Lencioni. The pragmatic operating model for a “healthy” organisation (Table Group).
• HBR’s 10 Must Reads on Building a Great Culture — including Edmondson on psychological safety and Katzenbach on change that sticks (HBR).
• The Netflix Culture Memo — free, short, and more useful than most books. Read it for the principles, then ask which of them would break your company (jobs.netflix.com).

Culture is the operating system your organisation runs on. You can let it accumulate as cruft, or you can treat it like the system it is — observe it, design it, test it, refactor it, and keep the bits that still work. Your engineers already know how to do this with code. Your job as an engineering leader is to apply the same craft to the people.

That’s the whole essay. Now go and check on your last three incident reviews.

Other related essays

• Building High-Agency Software Engineering Teams