Setting Team Norms That Actually Hold

A few years ago I inherited a team with a wiki page titled "Engineering Norms." It had eleven bullet points, a nice header image, and not a single line anyone actually followed. People merged straight to main on Fridays. Code review was a rubber stamp. The on-call rotation existed on paper but in practice one senior engineer answered every page because everyone else had quietly opted out. The norms were beautiful. They were also fiction.

I've since concluded that most teams don't have a norms problem. They have a norms-that-hold problem. Writing the rule is the easy part, and it's the part everyone pours their energy into. The hard part is making the rule survive contact with a bad sprint, a departing tech lead, and the one person who decides it doesn't apply to them. That's the part nobody puts on the wiki.

Norms Are Not Values

The first mistake I see is confusing norms with values. A value is "we care about quality." A norm is "no PR merges without a green CI run and one approval from someone who didn't write the code." The value is a feeling. The norm is a behavior you can observe on a Tuesday afternoon and say, unambiguously, whether it happened or not.

Values are cheap because they cost nothing to hold. Everyone is in favor of quality, collaboration, and ownership in the same way everyone is in favor of being healthy. Norms are expensive because they constrain what you do when you're tired and the deadline is tomorrow. If a norm doesn't tell you what to do at 6pm on the day before a release, it's a value wearing a norm's clothes, and it will not hold.

So the test I apply to any proposed norm is simple: can I imagine the exact moment it will be inconvenient, and does the norm still tell me what to do in that moment? If I can't picture the inconvenient case, I haven't written a norm yet. I've written a poster.

Write Fewer of Them

That wiki page with eleven bullets was doomed by arithmetic. Nobody holds eleven behaviors in their head, so in practice a team of ten people each remembers a different subset of three, and the overlap is roughly zero. You end up with the illusion of shared norms and the reality of ten private ones.

I now cap active norms at somewhere between four and six. Not because there aren't more good behaviors worth having, but because a norm only counts if the whole team can recite it without looking. When I ran this experiment with my last team, I asked six engineers separately to list our norms. The four we'd deliberately kept short, everyone got. The two we'd bolted on later, three people had never heard of. That told me exactly which ones were real.

Fewer norms also forces a useful fight. If you can only have five, you have to argue about which five, and that argument surfaces what the team actually believes matters. The eleven-bullet list avoids the argument, which is precisely why it's worthless. The constraint is the feature.

Every Norm Needs a Because

A norm stated as a bare command invites lawyering. "Always write a test before merging" gets you engineers hunting for the technicality that exempts their case. A norm with its reason attached survives edge cases because people can reason from the intent instead of the letter.

Compare "always squash your commits" with "we squash so the main branch history reads as one logical change per commit, which makes reverts and bisects sane during an incident." The second one tells you what to do when squashing would actually hurt clarity, because now you know what you're optimizing for. The rule is downstream of the reason, not a substitute for it.

A norm without its reason is a rule you'll defend even when it's wrong. A norm with its reason is a rule you'll bend correctly when it matters. I want the second kind on my team, always.

This matters more in regulated fintech than most places. We have controls that genuinely cannot bend, and we have conventions that absolutely should. If your team can't tell the difference, they'll either treat everything as sacred and grind to a halt, or treat everything as negotiable and eventually violate something that lands you in front of an auditor. The reason is what lets people sort the two apart.

The First Violation Is the Whole Game

Here's the uncomfortable truth: a norm becomes real the first time someone breaks it and something happens. Not something dramatic. Just a visible, consistent response that says the norm is load-bearing.

The failure mode is the senior engineer who merges without review because they're the senior engineer and it's fine, this once. Everyone watches. Nobody says anything, because who's going to tell the staff engineer no. And in that silence the norm dies. Not loudly. It just stops being a thing people do, because the most credible person on the team demonstrated it's optional. I've watched a code-review norm evaporate in exactly one incident like this, and it took months to rebuild.

So the norms that hold are the ones where the response to a violation is calibrated and predictable:

• The first time, someone names it plainly and without drama, usually in private, and usually framed as "hey, did the CI thing not work for you?" rather than an accusation.
• The response is the same regardless of seniority, which is the entire point and the hardest part to actually pull off.
• If it keeps happening, the conversation escalates from "did you know" to "we agreed to this, what's getting in the way," which is a different and more serious talk.
• If the norm itself is the problem, you change the norm openly instead of letting people quietly ignore it.

That last point is the pressure valve. A norm people are quietly breaking is telling you something. Either it's wrong, or it's too expensive, or it never had a real because. Fix it in the open or kill it. Don't leave zombies on the wiki.

Make the Right Thing the Easy Thing

You cannot willpower a team into a norm that fights the tooling. If your norm is "always run the linter before pushing" but the linter takes four minutes and isn't wired into anything, people will skip it, and they'll be right to, because you've asked them to be slower for no visible benefit. The norm loses every time it competes with friction.

The best norms are the ones you barely have to enforce because the path of least resistance already leads there. A pre-commit hook that runs the fast checks. A CI gate that blocks the merge button so "no untested code on main" isn't a promise, it's a mechanism. A PR template that asks the three questions you'd otherwise nag about. When I moved a team from "please add a rollback note to risky deploys" to a deploy tool that literally would not proceed without one, compliance went from maybe half to universal overnight. Not because people changed. Because the friction moved.

My rule of thumb: for every norm, ask whether a machine can hold it instead of a human. If yes, let the machine do it. Humans should only be responsible for the norms that genuinely require judgment, because judgment is the one thing you can't automate and the one thing that burns people out when you make them spend it on things a script could handle.

Borrowed Norms Rarely Fit

There's a strong temptation to copy the norms of a company you admire. Someone reads about how a famous engineering org does trunk-based development with feature flags and no long-lived branches, and wants to adopt it wholesale by Monday. I've done this. It went badly.

The norm that works at a 300-engineer company with a mature flagging platform and a dedicated release engineering team is not the norm that works at your twelve-person startup. The behavior was an adaptation to a specific environment, and you're importing the behavior without the environment. It's like buying the medicine without the diagnosis.

Steal the reasoning, not the rule. Ask why they do trunk-based development, decide whether that why applies to you, and if it does, invent the version that fits your actual constraints. The teams I've seen succeed with borrowed norms always translated them. The ones that failed cut-and-pasted them and then wondered why the shoe didn't fit a foot it was never measured for.

Norms Decay, So Revisit Them on Purpose

Even good norms rot. The team grows, the tools change, the thing the norm was protecting against stops being a threat. A norm designed to prevent a specific 2019 outage can quietly become a tax that new engineers pay without anyone remembering why. I once found a mandatory two-hour manual QA pass that existed entirely because of a bug fixed three years and one whole rewrite earlier. Nobody had questioned it. It was just the way things were done.

So I put norms on a schedule. Roughly once a quarter, twenty minutes in a retro, we read our own list out loud and ask two questions of each one: is this still true, and are we actually doing it. The gap between those two answers is where all the interesting problems live. A norm we're not following is either dead or being violated, and both need a decision. A norm we're following that's no longer true is friction we're paying out of habit.

This ritual does something subtle. It makes the norms feel owned rather than imposed. A rule you reviewed and re-ratified last month is a rule you're bought into. A rule some manager wrote two years ago is a rule you resent. Same words, completely different relationship to them.

You Set Norms by Living in Them

The single most powerful lever I have on team norms is not the wiki, the retro, or the tooling. It's what I do when a norm is inconvenient for me specifically. If I've said no unreviewed merges and then I merge my own hotfix at midnight because I'm the CTO and I can, I've just taught everyone that the norm is a status symbol, not a rule. Seniority buys you out of it. That lesson lands harder than anything I could write down.

So I ask for reviews on my own code even when it's a one-line change and even when it's slower and even when the reviewer is three levels junior to me and visibly nervous about it. Especially then. The discomfort is the demonstration. People believe what leaders do under mild inconvenience far more than anything they say in an all-hands. That asymmetry is either your best tool or the reason your norms are quietly fiction. There is no third option.

Conclusion

If I had to compress all of this into one instruction I'd give a new engineering manager, it would be this: stop trying to write better norms and start paying attention to the moment each one gets tested. The norms that hold are not the well-worded ones. They're the ones that had a real reason, that the tooling made easy, and that survived the first time someone with power found them inconvenient. Everything else is a poster. And a team can always tell the difference between a poster and a rule, no matter what the wiki says. They're watching what happens on Tuesday, not what's written on the wall.