You’ve heard the phrase. “Culture eats strategy for breakfast.” It gets repeated so often it’s almost lost its punch. But in technology organizations, there’s a more specific version of that dynamic worth paying attention to. It’s not culture in some big abstract sense. It’s the quiet, everyday norms that engineers follow when no one’s watching. The unwritten rules that shape whether your team ships carefully or ships fast and crosses their fingers. Those norms are either protecting your strategy or quietly taking it apart.
The Culture You Have vs. The Culture You Think You Have
Most tech leaders will tell you their org values quality. They’ll point to code reviews, retrospectives, architectural review boards, or an engineering handbook that someone put real effort into. Those things are real and they matter. But they don’t tell you what engineers actually do when the pressure is on and a shortcut is sitting right there.
What happens when a deadline is close and a quick fix is available? What happens when a junior engineer speaks up about a dependency that’s long overdue for replacement? What happens when a team is asked to estimate a feature and the honest answer is “we need to refactor this first”? Those moments reveal the real culture. Not the stated one.
If honest answers get softened before they reach leadership, that’s a culture problem. If refactoring never makes it into sprint priorities because it’s hard to justify on a roadmap, that’s a culture problem. And that culture problem is quietly, efficiently generating technical debt faster than any remediation program can keep up with.
Psychological Safety Isn’t a “Soft” Topic
There’s a tendency to treat psychological safety like it belongs in an HR workshop. It’s worth pushing back on that. Psychological safety is foundational to engineering quality. Without it, engineers don’t raise concerns early and don’t surface design flaws in reviews. They don’t speak up when a system is trending toward fragility. They wait, they work around it, and the problem gets bigger.
Google’s Project Aristotle found that psychological safety was the single most important factor in high-performing teams. Not technical skill, process, or tooling. Just the confidence that speaking up wouldn’t come at a personal cost. That finding holds in engineering environments as much as anywhere else. Maybe more, because the cost of silence tends to show up months later, at exactly the wrong moment.
Building it isn’t complicated, but it does require consistency. It means responding to bad news with curiosity rather than frustration and recognizing the engineer who says “this approach has a real problem” rather than the one who ships quietly and deals with the fallout later.
Incentives Shape Everything, Whether You Realize It or Not
Here’s a question worth sitting with honestly. What does your organization actually reward? Not what the mission statement says. In practice, what gets noticed?
Do engineers get recognized for the systems they stabilize, or only for the features they ship? Is reducing operational burden treated as a real contribution, or is it invisible next to new capabilities? Most organizations, even with good intentions, have incentive structures that reward velocity and quietly penalize investment. Refactoring doesn’t show up on a product roadmap. Paying down technical debt doesn’t land in a quarterly business review. The people doing that work often do it out of professional pride, and rarely get the visibility that comes with launching something shiny and new.
That asymmetry shapes behavior over time. Engineers learn what gets noticed. They optimize for it. And gradually, the culture drifts toward shipping at the expense of sustaining.
You don’t need a culture overhaul to fix this. You need deliberate choices about what leadership pays attention to. A CIO who publicly calls out a team for proactively retiring a fragile integration sends a signal that travels further than any internal memo about engineering quality ever will.
Ownership Without Accountability Is Just a Label
Agile and DevOps brought “you build it, you run it” into the mainstream, and the intent is genuinely right. Teams that own their systems tend to build them more carefully. But ownership without real accountability is just a slogan. If a team owns their system in name while support burdens quietly flow elsewhere, they haven’t internalized ownership. They’ve inherited a title.
Real ownership means the team actually feels the downstream consequences of their decisions. Not punitively but honestly. When the people who made the architectural choices are also on the on-call rotation, those choices start looking different. When the engineer who built the brittle integration is also the one being paged at 2 a.m., the next integration gets built with a bit more care.
That connection between decision and consequence is one of the most powerful levers available to technology leaders. It doesn’t require new tools or new frameworks. It just requires organizational design that keeps the feedback loop short and honest.
What Leaders Actually Control
Culture gets described as something that emerges on its own, being too diffuse for any one person to really shape. There’s some truth in that. But leaders have more direct influence over engineering culture than they often let themselves believe. They control what gets prioritized in planning and how bad news lands in review meetings. They control what gets celebrated and what gets quietly ignored. They control whether quality is treated as a constraint or an actual value.
The organizations that manage technical debt well, that scale without accumulating crippling complexity, that attract and keep strong engineers, tend to share something in common. Leadership there treats engineering culture as a strategic asset, not just a background condition. They invest in it on purpose and talk about it directly. These leaders hold themselves to the norms they’re trying to build, especially when it’s hard, and especially when an exception would be easy to justify.
That consistency is what eventually becomes culture. It’s slower than a reorg. It won’t fit neatly in a slide. But it compounds, just like technical debt does, just in a much better direction.
Every conversation about technical debt, governance, and modernization eventually leads back here. The systems your organization builds reflect the culture that built them. Fix the systems without addressing the culture, and you’re doing a renovation that won’t hold.
~ Dr. Carl Ryan Tucker