How to Build an Engineering Culture That Survives Growth: A Postmortem in Advance

Every team I’ve ever audited tells me some version of the same story: everything worked fine until we grew. And that’s accurate, as far as it goes. It just isn’t a defense. A culture that only functions at one headcount isn’t culture; it’s a side effect of a small broadcast domain. Nobody lost their values when the team doubled. The hallway stopped scaling, and nothing got written down to replace it.

So treat this the way you’d treat any other scaling problem. Stop asking people how the culture feels and go read the artifacts the team already produces: git history, CI retry logs, RFC threads, incident channels, exit interview notes, career ladder docs. The failure modes have names, and you can find most of them in an afternoon. That’s the whole method on this site — pull the evidence, name the mechanism, run a reversible experiment. No trust falls required.

What an engineering culture that survives growth actually means

Definition first, because “culture” is a word that absorbs whatever meaning the speaker needs at the time. An engineering culture is the set of defaults a team follows when nobody is watching: how decisions get made, how disagreement gets resolved, how bad news travels. A culture survives growth when those defaults still work after the people who created them are no longer in every room. That’s the entire test. Not whether the offsite was fun. Whether a new hire in a satellite office, six time zones away, makes the same call the founders would have made, for reasons the founders would recognize.

Most culture programs fail this test because they treat culture as a communications problem: values documents, culture decks, all-hands talks. Those are artifacts too, and I read them, but they record intent. The git history records behavior. When the two disagree, believe the git history. They usually disagree.

Symptom: “the culture was fine until we doubled headcount”

The complaint arrives as a people problem. The evidence usually says otherwise. Here is the standard deterioration timeline, with the mechanism doing the damage at each stage.

Stage 1: Osmosis (5 to 15 engineers)

Culture travels by proximity. Every decision happens in a room where everyone is present, or in the one channel everyone reads. Corrections take seconds. This feels like a strong culture, and it is one — with a single point of failure. The failure mode is a hiring plan.

Stage 2: Folklore (15 to 40)

Decisions start getting re-litigated. Not because anyone is being difficult — because the original context lives in one person’s head, and that person is on vacation, or on another team now. A decision that has to be won twice is a retry storm with human actors: repetitive, expensive, and it ties up your most senior people every quarter.

Stage 3: Deadlock (40 to 100)

Approval chains close into loops. Team A needs B’s sign-off, B is waiting on C’s security review, C is blocked on A’s architecture decision. Nobody in that loop is doing bad work. The wait-for graph simply has a cycle in it, and the org chart is the scheduler now. Conway said it first: organizations build systems that mirror their communication paths, and the law he described cuts both ways. Fix the paths or inherit the deadlock.

Stage 4: Normalization of deviance (100 and beyond)

The flaky test gets retried until it goes green. The alert that fires 400 times a day gets muted. The postmortem gets skipped because it’s a busy week, then a busy quarter. Diane Vaughan coined normalization of deviance studying the Challenger launch decision: each small deviation gets absorbed as normal, right up until the day it isn’t. Software teams run the same pattern on a shorter fuse and call it a busy quarter.

Contributing factors, read off the evidence

A postmortem doesn’t assign blame. It lists contributing factors. These are the ones I find most often, plus the artifact that convicts each one.

• Review concentration. git shortlog -sn shows one name attached to most of the merges. That’s a bus factor of one wearing a mentorship costume.
• CI retry storms. The pipeline passes on attempt three and everyone has quietly agreed not to notice. The team has stopped trusting its own tests, and honestly, it is right not to.
• Decision debt. RFC threads that end in “let’s revisit this in Q3” instead of a decision with an owner and a date.
• Blame-shaped incident language. “Who touched this” instead of “what did we not know.” Blameless postmortems aren’t a politeness ritual — they are how you keep the people holding the information willing to talk. Google’s SRE workbook makes the case plainly in its chapter on postmortem culture.
• A career ladder made of fog. The document says “impact” forty times and defines it zero times. Promotion becomes a vibes call, and the vibes are set by whoever is loudest in the room.
• PIP spikes after reorgs. Performance improvement plans cluster three months after a reorganization. Eight people do not independently get worse at their jobs in the same quarter. Read it as the org chart failing, not the individuals.

The audit: one afternoon, six pulls

You don’t need a consultant for this. You need read access and an afternoon.

1. Git history. Run git shortlog -sn --since='6 months ago' across your repositories. Who merges, who reviews, and how concentrated is the load? There’s a longer walkthrough in my guide to reading git history for team dysfunction.
2. CI retry logs. Count pipeline runs per commit. Retry-until-green is the most honest number in your build system. I keep a fuller walkthrough on reading CI retry storms.
3. RFC threads. Find the decisions that were made and then made again. Every reopened decision is evidence that the original had no owner and no expiry date.
4. Incident channels. Search the first ten messages of your last ten incidents for the word “who.” Count the hits. That’s your blame index, and you can watch it move month over month.
5. Exit interview notes. “Compensation” is what people say when the real reason would burn a bridge. Look for what the leavers had in common: same team, same manager, same quarter. Patterns, not people. There’s a fuller method in my notes on exit interview forensics.
6. PIP timelines. Plot them against org changes. Correlation isn’t causation, but a cluster is a confession.

Action items: six reversible experiments

Each experiment below has a success signal and a rollback condition. That’s the part most culture programs skip, which is why most culture programs fail: all commit, no rollback.

1. Put expiry dates on decisions. Every significant decision gets a short record: what was decided, why, who owns it, and a revisit date. The revisit date is the trick. It ends the quarterly re-litigation, because the decision can be reopened — on schedule, by anyone, with the original context attached. Success signal: fewer reopened RFCs. Rollback: drop the practice after a quarter and see whether the retry storm comes back. It will.
2. Break approval deadlocks with a default. Take the three most-looped approvals in the org and add one rule: five working days with no substantive objection, and the owner’s call stands. A deadlock is a wait-for graph missing a timeout. Add the timeout.
3. Quarantine flaky tests instead of retrying them. A test that passes on the third attempt isn’t passing; it’s gambling. Quarantine it, make the quarantine list public, fix the test, and watch the list shrink. If the list grows instead, you’ve learned something about the team’s relationship with bad news.
4. Cap review load, then check the logs. Set a soft weekly cap on reviews per person. A month later, run git shortlog again. If the concentration didn’t move, the cap was theater, and now you know that too.
5. Rewrite the career ladder in observable behavior. Replace every “impact” and “excellence” with something you could show a stranger: designs reviewed, incidents led, decisions documented and not reopened. Ambiguity in a ladder isn’t flexibility. It’s a buffer for bias.
6. Change the exit interview question. Stop asking why they’re leaving. Ask: what did this team keep misreading about how work actually gets done? The answers get less polite and far more useful.

Misdiagnoses: what the evidence gets called instead

Every mechanism above has a personnel-shaped alias. Review concentration becomes “our senior engineer doesn’t delegate.” Decision debt becomes “we need better alignment.” Deadlock becomes “engineering is slow.” A blame index becomes “one or two bad apples.” The misdiagnosis is expensive because it triggers the wrong treatment: coaching for a structural failure, a reorg for a documentation failure, more hiring for a throughput failure. You would not rename a deadlock “insufficient ambition” and expect the process to unblock. Don’t do the equivalent to people.

What a culture that survives growth actually looks like

Boring, mostly. Decisions that stay decided until their revisit date. A CI pipeline the team trusts enough to block a release on. Incident channels that read like diagnosis instead of deposition. A career ladder a stranger could apply to real work. None of it photographs well for the about page. All of it compounds.

The test I use is simple. Can a new hire answer “how do we do this here?” by reading, without asking one specific person? If yes, the culture lives in the artifacts, and it will survive the next doubling. If no, it lives in heads, and heads are portable.

FAQ: engineering culture that survives growth

Can you measure engineering culture without a survey?

Yes, and the measurements are better, because artifacts don’t perform. Six numbers cover most of it: review concentration from git history, retry-until-green rate from CI, reopened-decision count from RFC threads, blame index from incident channels, PIP-to-reorg correlation, and the recurring pattern in exit notes. A survey tells you what people think is safe to say. The logs tell you what happened.

What’s the first artifact to pull if I only have an afternoon?

CI retry logs, then git shortlog. A team that retries its tests until they pass has already told you the feedback loop is broken and the deviance is normalized. Those two pulls take twenty minutes and usually explain half the symptoms people keep describing as interpersonal.

When should a founder stop reviewing every pull request?

Earlier than feels right. A founder review bottleneck looks like quality control right up until it becomes a hiring ceiling and a bus factor of one. If your name is on most of the merges, you aren’t raising the bar. You are the queue.

Does hiring for “culture fit” work?

It selects for sameness, which reads as harmony and behaves like monoculture. Fit-based hiring quietly builds a team that agrees with itself, which is great for lunch and terrible for incident reviews. Hire for the artifacts you want: people who write decisions down, review generously, and refuse to retry broken things until they look whole.

How long does fixing this take?

The audit is an afternoon. The experiments need about a quarter before the signals are readable. The deterioration you’re correcting took years, so a sprint won’t do it — but the first artifact pull is free, and it usually changes the very next meeting you’re in.

One last thing. Culture failure gets narrated as personal failure: the difficult engineer, the underperformer, the manager who couldn’t scale. The artifacts usually tell a different story, one where the same three mechanisms — deadlock, retry storms, normalized deviance — chew through perfectly competent people. Pull the evidence before you write the performance review. The system is confessing. Read the logs.