The Culture Tax
Managing internal and organizational culture
No phrase has ever filled me with more dread or anxiety than hearing my CEO say "engineering is slow"---and I'm probably not alone in that feeling. So I did what most of us do: I optimized. Cycle times, sprint commitments, a shiny new engineering-intelligence dashboard, a board chart that finally pointed up and to the right.
As CTOs, we go for the "easy" fix: patch the delivery pipeline, push velocity, prove we're not slow. Unfortunately, you can't stop there.
In most cases, it isn't a question of engineering velocity but of the perception of speed---and what that perception is costing you. Who decided engineering was slow, and why?
A big part of the CTO's job---or any exec's, for that matter---is perception management. We represent our teams, and it's our job to protect and nurture how they're perceived by the rest of the organization. You can build the healthiest, most psychologically safe engineering team in the industry; if the rest of the company thinks you're a cost center that can't ship, your culture is still broken. Just not in the way you're measuring.
That's the culture tax. Ignore it and it doesn't go away---it just gets more expensive to fix later. And most CTOs are only watching half of it.
The Two Ledgers
The mechanism is simple: small decisions compound over time. None of them looks like much on its own. Together, and left unattended, they add up to something you can't ignore.
Start with the numbers---they're hard to wave away. McKinsey's Organizational Health Index---covering 1,500 companies across 100 countries---found that top-quartile organizations deliver 3x the total shareholder returns of unhealthy ones, regardless of industry. Gallup puts the global cost of disengaged employees at $8.9 trillion annually---9% of global GDP. And McKinsey's 2026 State of Organizations report found that 75% of organizations struggle to build high-performance cultures; less than a quarter achieve lasting impact.
That's compounding interest on decisions CTOs made---or avoided---years ago. And the person paying for it is rarely the one who made the call.
I'll keep abusing the tax-and-finance analogy for the rest of this article, so bear with me. You can think about your culture as two ledgers. The internal ledger tracks what happens inside engineering: trust erosion, mentorship gaps, psychological safety failures, what you tolerate and what you don't. The external ledger tracks how engineering is perceived by the rest of the company---and how that perception shapes what engineering becomes.
Most culture advice addresses the internal ledger. Most CTOs focus there because it's within their direct control. But the external ledger is where we often fail to spend enough time, and the consequences will not only impact how your team is perceived but also affect the team's internal culture.
The Internal Ledger
If you're a CTO who reads leadership content, you've encountered most of this before. Psychological safety, toxic culture, anti-patterns that corrode teams from the inside. It matters. It's also not the ledger you're neglecting.
A brief inventory.
The research is overwhelming, and you've seen most of it. Google's Project Aristotle tied psychological safety to 43% of the variance in team performance; MIT Sloan, analyzing 34 million profiles, found toxic culture is 10x more important than compensation at predicting turnover. Not twice as important. Ten times. The anti-patterns are just as familiar---hero culture, stack ranking, the velocity trap, survivor syndrome---and the damage is measurable: 81% of employees who rate their culture as poor say their manager lets bad behavior slide.
None of this is new. The research is extensive, the case studies are public, and the prescriptions are well-documented. Trust, psychological safety, fair incentives, accountability for behavior---the internal culture playbook is mature. If you're doing the work on the internal ledger, good. Keep going.
You can get all of that right and still have a culture problem---because none of it touches the second ledger.
The External Ledger
Software engineering, by its own nature, can be hard for external teams to understand, and it can often result in skewed views and grievances from said departments. Sales doesn't understand why we can't just ship faster. Finance sees a big line item that has no clear output. And the CEO absorbs those views and internalizes them as a risk.
Those perceptions aren't just annoying. They're organizational behavior waiting to happen.
These views slowly harden and take root in the company culture, and before you know it, they change the way that the rest of the org interacts with software engineering---relegating and siloing them. The roadmap becomes dictation, not collaboration.
Marty Cagan describes this as the defining gap between mediocre and high-performing companies: in most organizations, executives define the roadmap and engineers execute; in the best companies, engineers are co-problem-solvers who understand the "what" and "why," not just the "how."
The identity trap is what comes next. "They don't understand what we do" starts as a frustration and becomes a cultural identity. Engineers retreat into technical jargon as armor. The us-versus-them dynamic hardens; engineering starts optimizing for engineering, not for the business.
You can see it in the decisions themselves. Architecture picked for elegance over impact. Tooling chosen for developer comfort over what the company needs. A shorthand that locks out anyone who doesn't write code. I've seen this pattern in multiple organizations. It's never the engineers' fault for being frustrated. But the CTO created the conditions by not managing the interface.
Edgar Schein named the underlying dynamic decades ago: operator, engineering, and executive cultures are structurally misaligned, and when nobody manages the gap, the organization stops learning. The failure mode is always the same---leadership says "engineering is a partner" while treating it as a vendor, and people disengage from the dissonance. Basecamp is the cautionary tale that still gets cited: the founders used a "no politics at work" policy to shut down accountability over a racist internal list, 30% of employees quit within weeks, and a carefully built progressive image collapsed because the internal reality never matched it.
The external ledger isn't about PR or marketing engineering to the rest of the company. It's about whether the organization's perception of engineering matches engineering's reality---and whether you, as CTO, are actively managing that gap or letting it compound.
The Feedback Loop
Your internal culture and the way your team is perceived aren't separate problems. They are two sides of the same coin.
The loop is mechanical. Perceived slowness invites process---specs, approval gates, status meetings layered on to manage a risk the process itself creates. The overhead slows engineering down, which confirms the perception that started it. Each turn tightens the next, and it runs without an owner.
Every pass makes it harder to undo. The longer the loop runs, the more it costs to reverse---and there's no quick reset for years of accumulated organizational scar tissue.
Return-to-office mandates are the clearest recent example of perception dictating policy. Software engineers are knowledge workers---the work can be done from anywhere and the output is the same. But in plenty of organizations, the perception that people at home aren't really working hardened into policy anyway. Companies sent RTO as a trust signal: "We don't believe you're productive at home." The best engineers read it correctly and left. Eighty percent of companies reported losing talent to RTO mandates, and high-performing workers showed twice the intent to leave as average ones. The org shed the people it most needed, which only confirmed the story that engineering couldn't deliver.
Outside perception bends how the org behaves, and that behavior, whether we like it or not, turns into culture.
Where This Framework Breaks Down
Four situations where the two-ledger model doesn't apply cleanly.
Early-stage startups. Under about 20 people, everyone knows everyone. The internal and external ledgers are the same conversation. The two-ledger distinction becomes relevant around 50 people, when engineering and the rest of the org stop sharing ambient context.
Crisis mode. When the system is on fire, nobody cares about perception management. Both ledgers get suspended until the crisis passes. The tax accrues while you're firefighting, but trying to address it mid-crisis is a mistake.
Earned perception. Some perception gaps are accurate. If engineering is slow, managing perception without fixing velocity is dishonest---and engineers will see through it immediately. The external ledger is about alignment, not spin.
Structural authority gaps. Forty-three percent of CTOs report to another IT leader, not the CEO, and only 38% have a separate budget. Managing the external ledger requires organizational authority that some CTOs don't have. The framework assumes enough positional power to influence cross-functional perception; if you don't have that, the framework is aspirational, not actionable.
The CTO's Interface Responsibility
The CTO is the translator between engineering and the rest of the organization. As a CTO you need to be able to speak both languages---the technical and the business---and to make engineering's decisions legible to non-engineers.
Four things this means in practice.
Translate technical decisions into business language. Ninety-one percent of CTOs identify technical debt as their biggest challenge, but they frame it in technical terms---"we need to refactor the authentication layer"---instead of business terms: "we're losing 20% velocity because of brittle systems, and our last outage cost $2M." If the CFO can't quantify why engineering needs a platform investment, the CTO hasn't done their job.
Make engineering's decision-making legible. Non-engineers can't evaluate engineering decisions they can't see. Architecture Decision Records, cross-functional design reviews, transparent prioritization frameworks---these aren't bureaucracy. They're context sharing. "This is what we decided, this is why, and this is what we traded away." When decisions are visible, the perception of engineering as a black box starts to dissolve.
Close the perception loop. Regular cross-functional touchpoints that aren't about asking for things or reporting status. Product, Sales, and Finance should understand engineering constraints before they encounter them on a deadline. Not after. Gallup's data shows that 70% of team engagement is attributable to the manager. For engineering at the organizational level, that manager is the CTO.
Invest in engineering's organizational reputation. Internal engineering blogs, demo days, architecture talks open to non-engineers, lunch-and-learns where engineers explain the "why" behind recent decisions. Make engineering's work visible to people who don't read code. This isn't vanity---it's how you prevent the "service bureau" perception from taking root in the first place. And once that perception takes root, removing it costs ten times more than preventing it would have.
Kellan Elliott-McCrea put it simply: "People have to know you care about them---that's fundamentally your job as an engineering leader." That applies to your team. It also applies to every other function that depends on what your team builds.
What I'm Doing
Early in my career, I learned how important is it to manage the internal culture of the team, developer experience, psychological safety, and mentorship. As I moved up in the management chain, I realized (sometimes painfully) that the team's perception was just as important. I had to learn how to translate technical decisions into business language, make engineering's decision-making legible, and invest in engineering's organizational reputation.
As CTO or any kind of engineering leader you can't afford to ignore teams reputation and perception.
Worth Reflecting On
Internal Culture:
What behaviors are you tolerating in your engineering org that you wouldn't tolerate in a new hire's first week?
When was the last time someone on your team told you something you didn't want to hear---and you thanked them for it?
If your best engineer quit tomorrow and gave an honest exit interview, what would they say?
Organizational Perception:
How does your CEO describe engineering to the board?
When was the last time a non-engineering leader said "I understand why engineering made that decision"?
Does Product come to engineering with problems or with solutions they want built?
Both together:
If you left tomorrow, which would your successor inherit first---the internal culture or the organizational perception?
The answer will tell you what aspect of your organization you've been neglecting. Both are important. And the CTO who manages only the one they're comfortable with is the CTO whose successor inherits the other.