Your DNA Document Is Dead Without a Voice: How Recognition Shapes Engineering Culture
Or: The CTO’s Loudest Tool Isn’t a Strategy Doc — It’s a Slack Message
It was 2:47 on a Thursday afternoon, and the aircon on level 22 was losing its war against thirty-six bodies packed into a room designed for twenty. Somchai had just finished presenting — a clean, quiet teardown of a checkout flow that Product had greenlit two sprints ago. He’d found the dark pattern — the flow where the “confirm cancellation” button was greyed out and buried below three upsell offers, making it almost impossible for users to actually leave. The vinyl floor squeaked as someone shifted in their chair. The room had that heavy, over-breathed stillness where nobody wants to be the first to speak, where the hum of the projector fan becomes the loudest thing in the building. Then the CTO, sitting in the back row with a laptop half-closed on his knees, leaned forward and said — not loudly, but into the silence, which made it louder: “This is exactly the kind of product judgment we need.” Eleven words. Every head in the room turned. And every engineer on that floor just learned more about what this company actually values than any DNA document has ever taught them.
That’s the thing about culture. It doesn’t live in Confluence. It doesn’t survive in slide decks presented during onboarding week, sandwiched between the Wi-Fi password and the fire escape map. Culture is a living broadcast, transmitted in real time through the things leaders choose to notice — and the things they don’t.
As Maya Angelou once said, “People will forget what you said, people will forget what you did, but people will never forget how you made them feel.” She was talking about human connection, but she might as well have been describing the blast radius of eleven words spoken into a quiet room at 2:47 on a Thursday.
The Document Nobody Reads vs. The Message Everyone Screenshots
Every engineering organisation has some version of the DNA document. You’ve seen yours. Values like “we ship with quality,” “we own our systems end-to-end,” “we challenge respectfully.” They get unveiled at a quarterly all-hands with the gravity of a papal decree, maybe pinned to a Confluence page with a banner that says “Our Engineering Principles,” then quietly left to gather digital dust somewhere between the onboarding checklist and that wiki page about the office printers nobody’s updated since 2019.
Meanwhile, the actual culture is being written in real time — in Slack channels, in all-hands shout-outs, in the stories that get retold over Thai iced tea in the kitchen on level 8.
Here’s the uncomfortable truth: your DNA document describes the culture you want. Your recognition patterns describe the culture you have. And when those two things diverge — which they almost always do — engineers trust the evidence of their own experience over the aspirations of a Google Doc every single time.
As the sociologist William Bruce Cameron observed, “Not everything that counts can be counted, and not everything that can be counted counts.” We’ve gotten remarkably good at counting feature velocity, sprint burndowns, and deployment frequency. We’ve gotten remarkably bad at counting the moments that actually shape whether people feel safe to do their best work.
The Blast Radius — Recognition Is Never Just About One Person
This is the concept that changes everything once you see it. When a senior technical leader recognises someone publicly — in a Slack channel, an all-hands, a team review — the primary audience isn’t the individual being recognised. It’s everyone watching. And they’re all running the same calculation in their heads, whether they realise it or not: “If that behaviour gets noticed at the top, that’s the behaviour I should optimise for.”
This works in both directions, and it’s unforgiving in its honesty.
Recognise the engineer who noticed the session management library had ballooned into an over-engineered mess, took a week off product work to simplify it, and ended up saving six figures a year in compute costs? You just told every engineer in the organisation that initiative, simplification, and thinking about cost matter here — even when nobody asked for it. Even when it wasn’t on the board. Even when the Product Owner would have preferred those five days spent on the checkout redesign.
Recognise the team that shipped fastest without mentioning what they cut to get there? You just told everyone that speed is what the top cares about, regardless of what the DNA document says about quality and sustainability.
Every act of recognition is a culture decision. The only question is whether it’s an intentional one.
Why the Messenger Matters as Much as the Message
Not all recognition carries equal weight. This isn’t a value judgment — it’s organisational physics.
A thoughtful, detailed review from a direct manager is valuable. Managers provide frequency and context, which matter enormously for day-to-day morale and growth. But a single line from the CTO — “this is exactly the kind of engineering judgment we need” — gets screenshotted, shared in team channels, and remembered for months. The rarer the source, the stronger the signal.
There’s also a career-signaling dimension that we’d be naive to ignore. When the CTO notices your work, it doesn’t just feel good — it implies that your work is visible at the highest level, which shapes how the entire organisation perceives you. Suddenly you’re not just a senior engineer who refactored a library. You’re the senior engineer the CTO called out by name.
As the basketball coach John Wooden put it, “A coach is someone who can give correction without causing resentment.” The inverse is equally true: a leader is someone who can give recognition that resonates far beyond the recipient. Managers say “you did well.” The CTO says “this is what we value.” Both are necessary. They serve fundamentally different functions.
Recognition as Culture Architecture
DNA documents aren’t useless — let me be clear about that. They articulate intent. They set the vocabulary. They give you something to point at when explaining to a new hire why we do things the way we do. But intent without reinforcement is just aspiration.
Recognition is the reinforcement mechanism.
If your DNA document says “engineers are empowered to challenge decisions,” then the CTO publicly celebrating the engineer who questioned a feature because they believed it was misleading to users is worth more than ten slides about empowerment. If it says “we own our systems end-to-end,” then calling out the engineer who dug into a production anomaly in a service they don’t own — because they spotted it in Grafana and it didn’t feel right — that’s ownership culture made visible.
The DNA document sets the vocabulary. Recognition provides the evidence. Without senior voices actively backing up those values through what they choose to celebrate, the document is just words on a page that engineers scroll past on their way to the actual wiki page they were looking for.
Engineers are smart. They watch what gets rewarded, not what gets written.
What You Recognise Is Who You Become
This is where it gets concrete. The behaviours you choose to recognise publicly aren’t just nice moments — they’re architectural decisions about your culture. Every one is a signal, broadcast to the entire org, about what “good” looks like here.
The engineer who asked “should we build this?” — not whether they could, but whether they should. Product brought a feature request, the requirements looked straightforward, the sprint had capacity. But something about it didn’t sit right. Instead of quietly building it and moving on, the engineer raised the concern. That’s not insubordination — that’s the product thinking your DNA document claims to want. If nobody ever sees that behaviour recognised, it quietly stops happening.
The engineer who simplified instead of added. They saw a library that had accumulated years of complexity — what started as a clean abstraction had become a Swiss Army knife that also somehow made coffee. They took initiative, carved out a week, stripped it back to its essential purpose. The result was measurable: lower CPU utilisation, fewer incidents, faster onboarding for new engineers who no longer needed a Rosetta Stone to understand the codebase. Nobody asked them to do it. That’s the point.
The engineer who flagged a security concern that wasn’t their responsibility. Something looked wrong in a service they happened to be reading through while debugging a downstream issue. They could have kept scrolling — it wasn’t their system, wasn’t their team, wasn’t their problem. They raised it anyway. That’s the ownership culture you cannot mandate into existence. You can only recognise it into existence.
The team that killed their own feature. The data came back and it wasn’t working. Instead of tweaking metrics or extending the experiment to justify the sunk cost, they pulled the plug and wrote up what they learned. That takes courage, and it only happens in cultures where being honest about failure is visibly, demonstrably safe — not just in the DNA document, but in what gets celebrated when it happens.
The engineer who made the boring investment. Migrated a critical path off a deprecated dependency. Improved the CI pipeline. Reduced flaky tests from forty-seven to three. Nobody claps for this work unless someone makes it visible. And if nobody makes it visible, everyone learns that this work is career-neutral at best — something you do because you’re a good person, not because the organisation values it.
As the writer Samuel Johnson noted, “People need to be reminded more often than they need to be instructed.” Your engineers already know what good engineering looks like. What they need to see is that the organisation knows it too.
The Danger Zone — The Casual Comment Problem
Here’s the flip side of the blast radius, and it’s where this gets uncomfortable for those of us in leadership positions.
Senior leaders don’t just amplify positive recognition. They amplify everything. The blast radius doesn’t have an off switch. It doesn’t distinguish between your carefully considered Slack message and the offhand remark you made while half-reading a pull request.
A CTO’s casual “why did we build it this way?” dropped into a design review can undo months of psychological safety work. It might have been genuine curiosity. To the engineer presenting, surrounded by peers in an over-warm meeting room on level 7, it landed as judgment. A passing comment about one team’s velocity — “Team Alpha shipped three features this sprint, that’s great” — can make three other teams feel invisible, especially the ones doing the unglamorous platform work that enabled those features in the first place.
And here’s the one that really stings: if you’ve just publicly celebrated an engineer for pushing back on a product decision, but then you visibly lose patience when someone challenges your idea in a leadership meeting — congratulations, you’ve just taught the entire organisation that the DNA document only applies in one direction.
As the psychologist Carl Rogers observed, “What is most personal is most universal.” The fear of being judged by someone in power isn’t unique to software engineers. It’s a fundamental human experience. And it means that every unguarded moment from a senior leader carries weight that the leader themselves often can’t see.
The Consistency Tax — When Recognition Creates a Caste System
There’s a pattern I’ve watched play out across multiple organisations, and it’s one of the more insidious ways recognition can go wrong.
If the CTO consistently recognises customer-facing feature teams but never acknowledges platform, infrastructure, or enablement work, you’ve accidentally created a two-tier culture. The blast radius cuts both ways: what you don’t recognise publicly is also a signal. Engineers in the invisible tier learn quickly that the DNA document’s claim that “we value all contributions” is performative.
The engineer who made the boring investment — the dependency migration, the pipeline improvement, the test stability work — they need to see that this matters at the top too. Otherwise you’ll keep writing about ownership and operational excellence in your DNA document while the org optimises for feature launches, because that’s what actually gets noticed.
I’ve seen this play out with my own teams. The engineers building internal tooling, improving developer experience, maintaining the systems that make everyone else productive — they need to know their work is visible. Not because they’re insecure, but because recognition is a resource allocation signal. If the only path to visibility is shipping customer-facing features, that’s where your best engineers will gravitate. And your platform will slowly rot.
The Practical Framework — Making This Intentional
If you’ve read this far and you’re feeling a bit called out, good. I wrote this because I’ve been on both sides of this equation — the engineer whose work was invisible, and the leader who didn’t realise what his silence was communicating.
Here’s what I’ve found actually works:
Audit your recognition patterns. Go back through the last month. What have you publicly recognised? That’s your real culture, regardless of what the DNA document says. If you’ve only celebrated shipped features, you’ve told your org that delivery is the only thing that matters — and your values around quality, ownership, and courage are decorative.
Align recognition to your values. Pick one DNA value per quarter and deliberately seek out examples to recognise publicly. Make the connection explicit: “This is exactly what we mean when we say engineers are empowered to challenge.” Don’t assume the connection is obvious. Spell it out.
Be specific, not generic. “Great job” is noise. It’s the participation trophy of leadership communication. “I saw that you pushed back on the dark pattern in the checkout flow because you didn’t think it was right for the customer — that’s the judgment we need across the org” — that’s a culture-defining moment. The specificity is what makes it land. It shows you actually understood what happened, not just that something happened.
Amplify your managers. “I heard from Namfon that your team made the tough call to kill a feature based on the data” — now you’ve reinforced both the behaviour and the manager’s credibility. This is compounding interest on your recognition investment.
Watch your shadow. Assume every comment you make in public — every Slack message, every all-hands aside, every corridor conversation — will be interpreted as a signal about what matters. Because it will be. You’re always broadcasting, whether you’ve pressed record or not.
The Bottom Line
As Peter Drucker once noted, “Culture eats strategy for breakfast.” We’ve all heard this so many times it’s become wallpaper. But here’s the part nobody quotes: the meal culture eats for breakfast is cooked by recognition. Recognition is the mechanism by which abstract values become lived behaviours.
Your DNA document is the menu. Recognition is the actual food that gets served. And if the food doesn’t match the menu, people stop reading the menu.
Every engineering organisation has values. Most of them are aspirational fiction. The difference between a DNA document that shapes behaviour and one that gathers dust isn’t the quality of the writing or the elegance of the principles. It’s whether the people at the top are actively, visibly, consistently reinforcing those values through what they choose to notice, celebrate, and amplify.
Recognition from senior technical leaders isn’t a nice-to-have. It isn’t a feel-good exercise in employee engagement. It’s the single most powerful culture-shaping mechanism available to you. It costs nothing, takes seconds, and its blast radius extends to every engineer who sees it.
The only question is whether you’re using it intentionally, or whether you’ve left the most powerful tool in your leadership toolkit sitting in a drawer while you spend another afternoon polishing the DNA document.
Now, if you’ll excuse me, I need to go recognise someone. There’s an engineer on my team who spent last week making our CI pipeline boring and reliable, and I haven’t said a word about it yet. That changes today.