Enterprise clients demand trust, certification, and predictability. But behind every SOC2 badge and compliance checklist, there's a simple truth: you can't certify culture. This is a story about what happens when organizations mistake rules for behavior — and how real engineering culture can't be installed, only grown. "Culture eats strategy for breakfast." — Peter Drucker The Audit We were going through yet another audit — SOC2, ISO, ISA, DEFIS, you name it. All the things enterprise clients expect to see before signing a six-figure deal. It wasn't about survival. It was about trust and prestige. Those certificates were the company's social currency — a way of saying, "We belong here. We play at this level." The engineering unit had over a hundred people, half of them developers. Until recently, everything ran on conversation — Slack threads, hallway agreements, "we'll fix it later" promises. There were no formal reviews, no real processes, no repeatable rituals of quality. Then the compliance wave arrived. Twenty-three policies. That's what I counted in our Confluence space by the end of the first week. "Incident Flow." "SLO Policy." "Change Management Policy." Each with its own Slack announcement. I checked a few — no reactions. Not even an emoji. Just links floating in the void. The policies weren't the problem. The problem was the Jira tickets that would appear on my team's board without warning. "Update CI/CD pipeline per new Security Policy." "Complete Change Request Template for last deploy." Each document spawns more documents. Each template spawns more tasks. It went on for months, not weeks. Half a year, maybe more. At first, people believed this would help. That, finally, with all these new policies, the chaos would settle down. That structure would bring relief. But week after week, it started to fade. Excitement turned into fatigue. Threads in Slack that once buzzed with ideas became one-line acknowledgments — a thumbs-up, a quick "ok," then silence. Soon, even those stopped. Every few days, someone would post another "updated version" of a document — a new checklist, a revised template — and it would just hang there. No reactions, no comments, no discussion. People weren't rebelling. They were disengaging. They didn't argue — they just stopped caring. They quietly adjusted to the fact that the new rules didn't make their work any better or easier. So they did what people always do when faced with irrelevant control: they complied just enough to stay out of trouble — and ignored the rest. By the time version "policy_v12_final_FINAL.pdf" landed in Confluence, no one even opened it. Not out of defiance, but out of exhaustion. They'd learned that nothing in those files would change what really mattered. It felt like that scene in Harry Potter where Filch keeps hanging new decrees from Umbridge. Every day, another rule. Every week, another compliance requirement. And everyone just walking past them, eyes down, doing what they were going to do anyway. The rules weren't the point. The circus was exhausting. Where I Came From My first companies were raw startups. No process. No documentation. No one even said the word "culture." We just built things. Sometimes brilliantly. Sometimes terribly. But I didn't know that something deeper was missing. Then I joined a team where culture actually existed. A Head of Engineering who didn't enforce — he cultivated. No slogans. No orders. Just quiet consistency. He lived what he expected others to do — lead by example. "You should graze in the pasture and shit code," he told us once. "My job is to become unnecessary. The less you see me, the better." He never gave straight answers. He asked questions. He let us hit walls so we'd learn to build our own doors. When we proposed something, he'd either reinforce it or plant doubt — not by pointing out the problem, but by asking questions until we found it ourselves. That environment didn't need policies. It had something else. Three years later, I understood what engineering culture really meant. It's when no one needs to tell you the rules, because doing it right feels natural. Because "the right way" is simply the way we do it. That worked. For twenty people. For a company that wasn't under audit. For a time when "just trust people" was a viable strategy. I'm not naive enough to think that scales. Later, I moved to another unit — no culture. Then another — no processes either. Back to chaos. Only now I knew what was missing. And that absence felt louder than any rulebook. I started recognizing this pattern everywhere I went. When Everything Seems Simple It always starts the same. When chaos grows and clients start asking questions, the instinct is: "Let's bring order." So policies appear. Mandatory code reviews. Required templates. Definitions of Done. Checklists for everything. On paper — perfect. In reality, hollow. Reviews become rubber stamps. Documentation becomes a checkbox. The form is there, the substance is gone. Not because people are lazy or malicious. When there's no why, people find the path of least resistance. "Just get it done so they stop asking." I remember one Tech Lead — a sharp guy, genuinely believed in what he was doing. He came to me frustrated one day. "I don't understand why everyone's ignoring me. I'm bringing policies that the company expects us to follow. This is work. This is how we're supposed to interact." He was right. On paper, completely right. And I wanted to tell him: "Remember that Head of Engineering who said we should 'graze in the pasture and shit code'? Yeah, that doesn't scale. Can't take that to an audit. Can't explain that to Legal." But I also wanted to ask him: "When was the last time someone actually read your policy? Not skimmed it to check a box. Actually read it. Actually cared." Both things were true. We needed more structure than in the old days. But we'd built a system where people could be perfectly compliant and completely checked out. The people who loved policies — the ones who genuinely wanted structure — they burned out around policy seven or ten. Everyone else just quietly disengaged. That's not a policy problem. That's a culture problem dressed in policy clothing. Formal processes create the illusion of control without building understanding. Policies replace ownership. Discipline Instead of Meaning When policies don't work, management steps in. "We need to be professionals," they say. "This is an expectation." Command-and-control makes its entrance. Reports, reviews, more oversight. Soon, people stop worrying about breaking production and start worrying about breaking the rules. It even works — for a while. Until the pressure fades. Because it's not culture — it's compliance. And compliance dies when no one's watching. The problem isn't discipline. It's trust. Without psychological safety, no one takes ownership. People follow orders, not purpose. They obey — but they don't care. Rational Understanding Without Connection Next comes the "let's explain why" phase. Workshops. Slides. Post-mortems. Examples of how a missing review led to a production outage. Everyone nods. Everyone agrees. And nothing changes. Because understanding isn't a habit. Knowledge doesn't rewrite behavior. Until someone feels the pain — the bug, the rollback, the lost weekend — nothing sticks. Awareness is the seed. But culture is what happens when awareness turns into instinct. Isolation Another hidden trap: distance. The people writing policies don't live inside them. They mean well, but they don't hear the friction. They don't sit in the same stand-ups, don't stay up during the same on-calls. So what comes "from above" feels alien. Something done to the team, not for it. Culture doesn't grow in hierarchy. It grows in proximity — through empathy, shared pain, and shared pride. Without connection, rules feel foreign. Without trust, behavior never takes root. Policies Without Example Even the best document dies without an example. You can declare "all code must be reviewed," but if the tech lead merges into main on Friday night, the policy is dead by morning. People don't learn from documentation. They learn from behavior. Leading by example works better than being enforced by rule. If leaders ignore the standard, the standard disappears. If they live it, it spreads. Culture cascades from behavior, not from documents. When It Finally Starts Working Real change arrives quietly. The tone shifts. "Because we have to" becomes "because it makes sense." People stop saying "the process" and start saying "our way." Peer pressure appears — but the healthy kind. "Hey, don't push without tests, please." Not as punishment. As care. That's when you know policies have turned into culture. The system starts regulating itself. Culture as an Environment In a mature team, nothing feels forced. Processes don't get rolled out; they just exist. New engineers join and adapt in a week, not because they read the policy, but because doing it right is easier than doing it wrong. It's not a system of control. It's an ecosystem of habits. Alignment over control. Ownership over compliance. Meaning over metrics. Culture isn't "how we should work." It's how we work when no one's watching. The Moment It Clicked It was during a retrospective. Tech leads and EMs in a conference room. I was sitting in one of those glass meeting booths, writing down "What went well / What to improve" like everyone else. And I realized I only had one thing to say. "I'm tired of your endless new policies." I started unpacking why. That Tech Lead is being ignored. The Jira tickets appear like clockwork. The Slack messages with zero reactions. The memory of my old Head of Engineering asking questions instead of writing rules. We weren't creating safety. We were creating theater. Maybe I'm romanticizing the past. Maybe that old Head of Engineering wouldn't work at scale. But I remember what it felt like when the default was trust instead of proof. Back to the Audit We finished the SOC2. The spreadsheets were green. The auditors were happy. The certificates looked beautiful. But I knew the real audit wasn't this one. Compliance can be passed. Culture can't. Policies can be implemented in a day. Culture can only be grown. The Question We Should Be Asking This isn't a manifesto against policies. Scale requires structure. Regulation requires documentation. Incidents require processes. You can't run a thousand-person organization on trust and vibes. But here's what I learned: you can write down "how we do things" without killing "why we care." You can have incident response procedures that assume competence instead of incompetence. You can document practices that already work instead of inventing practices because you think you should have them. The question isn't "policies or no policies." The question is: who are you writing them for? The people doing the work, or the people auditing the work? Because if it's the latter, you'll get compliance. If it's the former, you might get culture. And culture, when you're lucky, will start writing the policies for you.
