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.

What struck me was how the culture of the company I help grow has evolved since the early days. From an inclusive to almost exclusive culture. This prompted me to understand such cultural evolution at organisations and go on a reading spree, with the intention of nailing a playbook that would help evolve a good culture as the company grows. I hope I’ve got something close. Perhaps I’ll get the opportunity to try it out somewhere.

This is 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.

The evolution of an organisation at a glance

The stages of organisational culture evolution are:

• The Startup: Founder & Leadership behaviour under pressure
• The Scale-up: building systems and managers
• Maturity: renewing without repudiating

    %%{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 is “culture”

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.”

Most companies obsess over levels one and two 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. In software terms, it is the runtime.

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).

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, the best way to understand your organisation’s culture by going under cover is to:

• Attend incident post-mortems, town-halls
• Review recent promotions
• Review recent exit-interview feedback

The Culture Code and a note on Psychological Safety

In The Culture Code, Daniel Coyle distils strong cultures into three skills which I found are particularly insightful.

These are build safety, share vulnerability, and establish purpose (danielcoyle.com).

As highlighted in Patrick Lencioni’s Five Dysfunctions of a Team, forming a team requires members to be comfortable being vulnerable in front of their team members. Leaders who admit a mistake first create the permission for everyone else to do so.

Project Aristotle, spun by Google, 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.

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.

How the culture operating system actually runs

Leaders can’t edit assumptions directly — they can only pull levers that change what gets modelled, rewarded and made easy.

    %%{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': 44}}}%%
flowchart LR
    subgraph LEVERS["What leaders actually control"]
        direction TB
        L1["What you model<br/>(startup)"]
        L2["What you reward & promote<br/>(scale-up)"]
        L3["Decision rights, rituals,<br/>architecture (scale-up)"]
        L4["Dissent & gradual migration<br/>(maturity)"]
    end
    subgraph RUNTIME["The runtime — what actually runs"]
        direction TB
        U["Underlying assumptions<br/>Is it safe to fail? To disagree?"]
        B["Behaviours<br/>what people do when nobody's watching"]
        O["Outcomes<br/>quality, speed, retention"]
    end
    subgraph SURFACE["What you can see"]
        direction TB
        A["Artefacts<br/>rituals, tools, office"]
        V["Espoused values<br/>the poster on the wall"]
    end
    L1 & L2 & L3 & L4 ==> U
    U --> B --> O
    O -->|"stories & incentives<br/>reinforce"| U
    U -.->|shows up as| A
    V -.-|"weak unless<br/>backed by systems"| U
    classDef surface fill:#edf6ff,stroke:#3a3a3a,stroke-width:2px,color:#1f1f1f,stroke-dasharray:5 6;
    classDef runtime fill:#fff4cf,stroke:#3a3a3a,stroke-width:2px,color:#1f1f1f,stroke-dasharray:5 6;
    classDef lever fill:#f9efe4,stroke:#3a3a3a,stroke-width:2px,color:#1f1f1f,stroke-dasharray:5 6;
    classDef zone fill:#fffdf7,stroke:#6b6b6b,stroke-width:1.5px,color:#1f1f1f,stroke-dasharray:3 4;
    class A,V surface;
    class U,B,O runtime;
    class L1,L2,L3,L4 lever;
    class LEVERS,RUNTIME,SURFACE zone;
    linkStyle 0,1,2,3 stroke:#1d1d1d,stroke-width:3px;
    linkStyle 4,5,6 stroke:#4d4d4d,stroke-width:2px,stroke-dasharray:6 6;
    linkStyle 7,8 stroke:#8a8a8a,stroke-width:1.5px,stroke-dasharray:2 5;
  

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

If you don’t know the original reference - checkout the following:

• https://www.youtube.com/watch?v=2D94XuQ377U
• https://danielcoyle.com/the-culture-code/

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. But this only tells 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.

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. I learned this the hard way when transitioning from engineer to engineering manager. As an engineer, I held assumptions that made me believe a lot of the ways of working were obvious. This is an easy assumption to make when having worked most of your career in one mature company. But as I took on more engineering leadership challenges, I found out that writing it down encourages discussion and evolution.

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. Schein would call this surfacing the assumptions before they fossilise (MIT Sloan).

Make this a habit for every new team process - that’s your way of working and that 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. At the same time, 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” can be 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.

This might sound eerily familiar to anyone who has worked in a high-delivery-pressure startup environment.

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.

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.

If you are a founder or a CTO or among the founding engineering leaders, 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.

Context not control

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 practice “context, not control”. What that means is to 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.

Decisions and Accountability

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 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 don’t talk about.

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.

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.

A fictional 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).

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 found 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).

A good way to measure culture is to look at it from the behavioural, structural and outcome oriented perspective.

Behavioural: Measure voluntary attrition rate, internal mobility, promotion rate parity, focus time vs meeting time, PR turnaround, code review quality and tone and absences like sickness leave

Structural: manager to IC ratio, time to hire and time to get a decision to hire, % of decisions that need escalation beyond a certain level.

Outcome oriented: retention of high performers, % of effort that goes into building new things or innovating, etc

Perception matters too and that is quite often covered by the eNPS and other types of survey. This is a good signal to leaders on what they might need to focus on.

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:

• 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