Every engineering leader I know wants a great culture. Most of them are trying to build it from the wrong end.
They write values. They run offsites. They invest in rituals. All of those things matter — eventually. But they are downstream effects, not upstream causes. Culture is not a thing you declare into existence. It's a thing that compounds, slowly and relentlessly, from the smallest observable unit in your organization: a single action, seen and responded to in time.
That unit is feedback.
Strip away everything else, and this is the thesis: an organization's culture is the aggregate output of its feedback loops. Every piece of feedback given or withheld is a small vote for the kind of organization you're becoming. The speed, the specificity, the courage — or the absence — of feedback is what determines whether a good action repeats or disappears, whether a bad pattern hardened or corrected, whether your values are lived or merely posted.
"Culture is not the posters on the wall or the values on the wiki. It's what happens when no one is watching."
If that's true — and I believe it is — then building culture isn't primarily a communications challenge. It's a feedback design challenge.
The Cycle Nobody Talks About
There's a model I keep coming back to when I think about how culture actually forms. It's deceptively simple:
The reason most culture-building efforts stall isn't values alignment or strategy. It's that organizations focus their energy at the wrong stage. They invest in culture-level interventions — naming values, running engagement surveys, redesigning the org chart — while neglecting the action level where culture is actually being written, one small moment at a time.
Why Speed Matters Most at the Action Level
An action is a discrete, observable moment. How someone handles a code review. Whether they document a trade-off. How they respond in the first ten minutes of an incident. These are the atomic particles of organizational culture — and they are extraordinarily time-sensitive.
The shorter the loop between an action and meaningful feedback, the more likely that action gets reinforced before it calcifies into a pattern. If feedback is slow or absent, people fill the gap with their own assumptions about what's valued. That gap is where culture drift lives.
This is the insight that changed how I think about the job: the absence of feedback is also a message. When someone does something well and hears nothing, they file it away as unremarkable. When someone does something poorly and hears nothing, they assume it was fine — or that nobody cares. Silence doesn't create a neutral cultural environment. It creates an ambiguous one, and ambiguity at scale is corrosive.
Fast feedback doesn't just correct — it declares. It tells someone: this moment was seen, this behavior matters, this is what we value here.
For engineering leaders managing distributed teams, this creates a real tension. You can't observe every action across every squad. Which means the question isn't whether you personally give feedback fast — it's whether your organization has systems that do. PR review culture. Sprint retros. Incident post-mortems. The Slack message sent after a sharp technical call. These are all feedback mechanisms, and they're either calibrated or they aren't.
Feedback Isn't One Thing — It Evolves
Here's where most frameworks about feedback miss the mark: they treat it as a single practice with a single purpose. Give feedback quickly. Be specific. Use a model. Repeat.
But feedback plays a fundamentally different role depending on where you are in the formation cycle — and applying the wrong kind at the wrong stage is a real failure mode.
At the Action Level
Feedback is about recognition of the specific moment. Not "you're doing great" — that's noise, not signal. The goal is to name the action precisely: "The way you flagged that risk in the RFC before it hit implementation — that's exactly the kind of thinking we need." That precision is what creates a pathway for the action to repeat. Without it, a great action is just a one-off with no reason to become a pattern.
At the Behavior Level
Feedback shifts from recognition to reflection. Once actions are starting to repeat, you're in pattern territory. The job now is to help the person see the pattern they can't yet fully see in themselves — and to name it in a way that reinforces the intentionality. "I've noticed that whenever your squad hits ambiguity, you're the one who calls for an explicit decision meeting. That's becoming something your team relies on." This moves feedback from reactive to developmental.
At the Habit Level
This is where the framing shifts entirely — and where it's easiest to get wrong. When something has become a habit, the question is no longer are you doing it? It's are you doing it well? Feedback at the habit level is calibration. The practice exists. Now raise the bar.
If someone has built a habit of writing tests, confirming that fact is useless. Feedback now sounds like: "Your tests consistently cover the happy path — the next level is building the muscle for edge cases and failure modes." The habit is intact. The feedback sharpens it. This distinction matters because treating habit-level behavior as action-level behavior — rewarding the existence of a practice rather than its quality — is how you get mediocrity that mistakes itself for excellence.
At the Culture Level
When culture is strong, it becomes self-reinforcing. The environment gives feedback without any individual having to deliver it. New engineers feel the expectations through onboarding, through the quality of code reviews, through what gets celebrated in retros. That feeling is compounded feedback from thousands of previous moments — the accumulated consequence of every action that was seen, named, and responded to appropriately.
Culture-level feedback is what you get when all the previous stages were handled well. You cannot shortcut to it.
The Management Implication
For managers specifically, I've come to believe something that probably sounds too strong: feedback is not a part of the job. Feedback is the job. Every other responsibility — performance reviews, 1:1s, delivery management, career development — is a feedback loop in disguise. The quality of a manager is directly proportional to the quality, consistency, and courage of their feedback.
This is why I'm skeptical of frameworks that treat feedback as a discrete practice — something you do during calibration cycles or after a project closes. That cadence trains the organization to treat feedback as an event rather than a climate. The result is a culture where people are surprised by performance reviews, because the information they contained should have been flowing in real time all along.
The model I use with my managers — borrowed and extended from Kim Scott's Radical Candor — is that feedback must be specific, timely, and genuinely caring. Not as separate criteria, but as a simultaneous discipline. Specificity without timeliness loses impact. Timeliness without caring becomes aggression. Caring without challenge becomes the most insidious failure mode of all: ruinous empathy, where you're protecting someone's feelings at the expense of their growth.
Giving feedback is caring. The manager who withholds a hard truth because it's uncomfortable isn't protecting their engineer — they're protecting themselves.
One more thing that often gets dropped from these frameworks: feedback is bidirectional. A manager who only gives feedback but never actively solicits it is modeling a one-way culture. Your engineers are watching. If you visibly receive feedback, adapt to it, and close the loop — you give them permission to do the same.
The Proof Is in What Compounds
Here's the argument that I find hardest to argue against: teams with the strongest feedback cultures are consistently the highest-performing teams. Not because they're staffed with better engineers — but because their errors correct faster, their good patterns propagate faster, and their people grow faster.
I've watched this play out firsthand. The engineers who adopted AI coding tools fastest in our organization weren't the ones who had the most time or the most technical confidence. They were the ones in squads with the strongest feedback cultures — teams that were already comfortable with iteration, with learning in public, with the idea that your work is always improvable and that saying so is an act of investment, not criticism.
That is not a coincidence. A strong feedback culture trains people to treat input as information rather than judgment. When you've built that muscle, every new challenge — a new tool, a new architecture, a new way of working — becomes something to iterate toward rather than something to defend against.
Culture compounds when feedback compounds. And feedback compounds when it's treated not as a periodic event but as the operating standard — the continuous, low-friction, high-frequency mechanism by which an organization learns about itself and chooses who it wants to become.
Culture is not what you declare. It's what you reinforce — action by action, feedback loop by feedback loop, until the organization gives itself feedback without needing you in the room.
That's the work. It's slow, and it's irreplaceable.
Be calm, and persist through challenge.
Enjoyed this article? Get new ones on engineering culture and security leadership delivered to your inbox.
Subscribe →