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

Cover image attribution: The bonsai pruning person illustration is an AI-generated artwork, created from a prompt.

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 wobbles. By person sixty, the corridor has become a confluence of Slack channels, and somebody is seriously proposing that you “document your values.”

This essay is about that journey — from the founding team’s handful of engineers to a mature organisation that still feels like a place the best people want to stay. It’s written for engineering leaders, because we are uniquely placed to mistake architecture for culture and vice versa. We’ll borrow the best thinking from organisational research, translate it for software people, and try to make you laugh in the places where the alternative is crying.

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.

What we actually mean by “culture”

Before we go further, let’s define what we mean by 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 “We move fast and fix things.”
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 — the posters, the values, the away-day flip charts — and then completely ignore 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” — they are, 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 or where you want to work on the remaining days. 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 isn’t 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 3am.
• 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 survives the experience.
• Whether “we ship quality” survives a quarter when the board wants a number moved.

If you want to know your culture, don’t read your values page. Read your last three incident reviews, recent three promotion packets, or if you have access to, read the recent exit interview notes. Those are your real artefacts.

The three skills every culture runs on

Before we 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 bit is the middle one: vulnerability doesn’t come after trust; it comes before. Leaders who admit a mistake first create the permission for everyone else to do the same. That finding rhymes 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).

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.

Stage 1 — Startup: culture is founder behaviour under pressure

In the earliest days, you don’t have a culture programme. You are the culture. Whatever you do on a stressed Tuesday afternoon is being carefully studied by your first engineers, copied, and eventually laminated into “how we do things here.” This is both a superpower and a hazard.

What to do

Hire for slope, not for trophy

Google’s researchers expected to find “the perfect mix of individual traits and skills” — “one Rhodes Scholar, two extroverts, one engineer who rocks at AngularJS, and a PhD.” They were, in their words, “dead wrong” (re:Work, Google). “Slope” 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 a wrong early hire, because early hires are force-multipliers — they shape the next ten. Hire for learning speed, integrity, and craft over a glittering CV that won’t survive contact with ambiguity. And a hard-won truth worth internalising early: one toxic high-performer does more cultural damage than five mediocre ones will ever make up for in output.

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

Write down your engineering principles while they’re still small enough to feel silly. A one-page “how we do code review here,” a decision log, an incident review template. Not because you’re a process person, but because writing things down is how you find out whether they’re real. Schein would call this surfacing the assumptions before they fossilise (MIT Sloan).

Model the vulnerability you want

If the founder never admits a mistake, nobody else will either, and your incident reviews will become works of fiction. Coyle’s research is unambiguous: the leader going first — “I got this wrong, here’s what I learned” — is the single most powerful signal you can send (danielcoyle.com). It costs you nothing and buys you the one thing every early team needs: psychological safety.

Reward truth-telling over heroics

The default failure mode of a startup is “hero culture” — the person who pulls the all-nighter to ship the broken thing is celebrated, and quietly the team learns that heroics beat planning. Celebrate the person who prevented the outage instead. You get more of what you reward; this is not complicated, and yet. 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 “first ten hires” checklist that includes cultural signals, not just technical bars.

The first process is usually invented five minutes after the third person says, “I thought you were doing that.”

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

Here’s the uncomfortable truth about scaling: everything that worked by osmosis now needs a transmission mechanism. At fifteen people, culture travels by overhearing. At a hundred and fifty, the people on the third floor have never met the founder, 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.

At scale, culture is what happens when the founder isn’t in the room.

What to do instead to scale your culture with your organisation

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 (Table Group)

The last one is the one 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. Change the system, not the slogan.

This is an investment and if you are an engineering leader who has been there and done that, you’d know this and will 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”

This is the hardest part. 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). Netflix’s framing is useful: 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.

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. Netflix’s answer is 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. Committees slow you down and dissolve accountability; an informed captain does neither. 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.

Design your rituals on purpose

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

Culture and capability are the same problem seen from two sides.

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

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. This is almost exactly the wrong move.

Maturity is not the enemy. Unexamined bureaucracy is.

What to do to renew culture without betraying the people who built it

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.

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 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” (Table Group). The systems change as the company changes; the principles don’t have to. Netflix’s own framing is pointed here: the company says it works to constantly improve its culture, “not preserve it” (Netflix Culture Memo).

Preserve the principles; renovate the practices.

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, change the incentives, and the behaviour follows. Punishing the person while leaving the system intact is both unfair and ineffective.

Farm for dissent, especially at the top

The bigger the organisation, the more filtered the truth becomes on its way to the leader. 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

This is where the engineering metaphor pays off. 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.

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 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 backsliding or correct course” (Cultural Change that Sticks - Katzenbach, Steffen & Kronley, HBR, 2012). In other words: instrument your culture the way you instrument your services. You measure deployment frequency and change-failure rate for your software. What’s the equivalent for your culture — and who’s looking at the dashboard?

The culture refactoring playbook

Here’s the whole thing in one table. Pin it, print it, or ignore it until your next reorg.

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. The job is to apply the same craft to the people.

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

Additional Reading by some of the authors cited above

• 5 enduring management ideas from MIT Sloan’s Edgar Schein - timeless wisdom for organisational management

Other essays that are related

• Building High-Agency Software Engineering Teams