Why Culture Change Is Harder Than You Think

I used to think culture change was about inspiration and alignment. You know — get everyone in a room, talk about values, create shared understanding, and watch behavior magically improve.

I was completely wrong.

After years of working with teams that struggled with ownership and accountability, I've learned that culture change is about forcing new behaviors until they become automatic. It's about building systems that make the right choices inevitable and the wrong choices painful.

But what I didn't expect was how much I'd have to learn about human psychology — and how wrong my initial assumptions would be.

Here's the story of what I've discovered about why some culture changes succeed while others fail.

The Defensive Trap That Kills Culture

The biggest culture killer I've observed isn't incompetence or lack of skill. It's defensiveness.

When I look back at failed culture changes, there's always a pattern: people think that admitting mistakes will damage their standing. What actually happens is that it's the refusal to admit mistakes that destroys culture.

I can spot this pattern immediately: someone can't own up to their failures, so they create elaborate explanations, point to process failures, blame unclear requirements, or find ways to make it someone else's fault. This behavior is toxic to team culture because it spreads.

"Extreme ownership means looking at yourself first. There's always something 'you' can do. As soon as you start pointing fingers, culture breaks down."

The moment one person starts deflecting blame, others feel they need to protect themselves too. Soon you have a team where everyone is covering their tracks instead of solving problems.

When I see someone who can't admit their own mistakes, I know they're poisoning the culture because they can't:

• Mentor anyone else (how do you teach ownership if you don't model it?)
• Create effective processes (how do you fix what you won't acknowledge?)
• Learn from failures (how do you improve what you won't accept responsibility for?)
• Build trust with their team (who wants to work with someone who throws others under the bus?)

What happens instead is they start creating processes that work around the actual problem rather than addressing it. Band-aids on top of band-aids, all because they can't face the reality of what went wrong.

This is where intervention becomes crucial. In healthy cultures, this behavior gets addressed quickly because it's so obviously destructive. The key is creating that healthy environment where defensive behavior simply can't take root.

But here's what I learned the hard way: you can't just address the symptoms. You have to understand why people become defensive in the first place. And that led me to a much bigger realization about ownership.

The Ownership Problem

The biggest mistake in culture change is thinking ownership is a personality trait. That some people "naturally" take responsibility and others don't.

What I've learned through experience is that ownership isn't a trait — it's a system that gets built and enforced through consequence.

I've worked with brilliant engineers who would wait weeks for budget approval instead of escalating a critical issue. Not because they were lazy or incompetent, but because the system they thought they were in was reactive. They waited for clarity instead of creating it.

---

"Just because you understand something doesn't mean everyone else does. Even when you think you're being clear, you're probably not."

Here's an example of how this plays out: A few weeks prior, we'd talked about implementing an on-call schedule but hadn't formalized it yet. Then our main data feed broke during live games at night.

But this was actually two separate failures in the same incident.

First failure: The problem had actually started earlier in the day — multiple developers had stopped by my office to ask if I was in meetings. I'd say yes, they'd go back to their desks. It wasn't until later I discovered they had something urgent but didn't want to interrupt. My first reaction was: "Are they so stupid they can't realize they should interrupt me if it's urgent?" But that was me pointing fingers. As I thought about it more, I realized the real problem was that they needed me to help fix their problems. When I was VP of Engineering, anytime they'd ask for help, I'd offer it immediately. They became dependent on me. Now as CEO, they still looked to me to fix their technical problems. That dependency was on me — I hadn't mentored them to own problems independently.

Second failure: When the API completely failed that night, one of our engineers noticed the problem and mentioned it in Slack. But no one escalated for over two hours. When we investigated, the response was "no one was on call because budget approval was pending." They were waiting for me to approve the on-call schedule implementation we'd discussed weeks earlier, rather than just implementing it themselves or escalating the immediate crisis.

Two different ownership failures, same root cause: they were waiting for me instead of taking initiative.

I've seen this pattern repeatedly: problems fester, deadlines slip, and when we do postmortems, the same people who let things slide have perfectly reasonable explanations for why they didn't act.

1. "We didn't have budget approval."
2. "I was waiting for direction."
3. "I thought someone else was handling it."

Every excuse was technically true. But every excuse missed the point: they saw a problem and chose not to own it.

What we did to fix it: We required both engineers involved to add written self-evaluations to the postmortem admitting their personal failures. One had to write down why he didn't escalate immediately when he saw the problem. The other had to explain why "waiting for budget approval" wasn't actually an excuse for leaving systems unmonitored. We also established a rule that critical system failures bypass all approval processes — if you see it, you own it until someone with more authority takes over.

The breakthrough came when we stopped accepting "waiting for approval" as an excuse for leaving critical systems unmonitored. Building accountability structures that make ownership unavoidable changes everything.

But as I started paying closer attention to these patterns, I realized the problem wasn't just about individual incidents. There were deeper behavioral patterns at play — and they were more subtle than I initially thought.

Recognizing Bad Culture Patterns

When assessing team health, certain patterns indicate broken culture. It's not dramatic dysfunction — it's quiet problems that look almost reasonable on the surface.

Here's what to watch for and how each pattern can be addressed:

The Analysis Paralysis Leader: Hides behind process talk and architectural discussions instead of naming failures plainly. When something breaks, they want to discuss root causes and systemic improvements rather than acknowledge that they personally didn't act when they should have. This is defensiveness disguised as thoroughness.

Here's what this looked like: We had a critical system component that handled user authentication. During a routine deployment, something went wrong and users started getting login errors. Our lead engineer noticed the issue and commented in Slack that "the architecture is resilient, so this should self-recover."

But it didn't self-recover. For the next three hours, users couldn't log in. When I asked him what he'd done to follow up, he said he "thought it was covered" because he'd made that initial assessment. In his mind, observing the problem and commenting on it was the same as taking responsibility for it.

When we did the postmortem, instead of owning his failure to follow up, he wanted to discuss architectural improvements and monitoring enhancements. Classic deflection — turning a personal accountability failure into a systems discussion.

What we did: This became a training moment about what ownership actually means. I sat down with him and explained that when you comment on a system's status, you're taking responsibility for tracking its resolution until it's actually fixed. No observations without ownership. For his postmortem, he had to include exactly what steps he took to verify recovery, when he checked back, and why he didn't escalate when his assumption proved wrong. Most importantly, he had to write down that assuming something would fix itself isn't the same as ensuring it gets fixed. The goal wasn't punishment — it was helping him understand that ownership means follow-through, not just observation.

The Willing But Directionless: Mirrors whatever leadership style is in front of them. Copies solutions without understanding principles. When things go wrong, they'll point to the person they were copying rather than examine their own judgment in blindly following.

This showed up when a senior leader was telling another manager how to run his team "just do what [another manager] did" without providing any strategic context. When I asked both of them about the biggest problems they were facing on the dev team, they couldn't answer. They jumped straight to talking about "goals" — "deliver on time" and "reduce bugs" — without understanding what they were actually trying to solve.

What we did: I had to coach both of them through this backwards thinking. Before you can set goals, you need to identify problems. I made them each write down the three biggest issues preventing their team from being effective. Then we worked backwards from those problems to create strategic solutions, not just copied tactics from other teams. The senior leader had to justify every directive he gave with a strategic explanation tied to solving those specific problems. He had to articulate not just what to do, but why it mattered to the business and what success looked like. We also started weekly one-on-ones where both managers had to explain their understanding of what problems they were solving, not just what goals they were hitting.

The Passive Observer: Sees problems but doesn't act because "it's not my job" or "someone else is handling it." When systems fail, they have a perfect alibi: they weren't responsible.

This happened when a paid feature failed in production. An engineer noticed the issue but waited 2.5 hours before escalating because "no one was officially on call." The excuse? Budget approval was still pending for the on-call rotation.

What we did: We implemented "If you see it, you own it" escalation. Anyone who observes a system failure becomes responsible for ensuring someone with authority knows about it within 15 minutes. No exceptions, no bureaucratic shields. We also created a bypass protocol for critical issues that doesn't require any approvals.

Bad Culture Pattern	What It Looks Like	What Works
Defensive Blame-Shifting	"The process failed" instead of "I didn't follow up"	Written self-examination before external blame
Reactive Ownership	People wait for problems to escalate before acting	Accountability systems that make escalation unavoidable
Process Hiding	Using procedures as excuses for not taking initiative	Eliminating excuse structures and bureaucratic shields

What I've learned is that defensive behavior is contagious, but so is ownership. With the right intervention at the right time, the tide can turn. When one person starts taking real ownership, others follow. Each instance of honest accountability makes it safer for others to do the same.

The goal is creating an environment where ownership thrives and defensiveness simply can't survive.

---

Once I understood these patterns, I realized there was another layer to the problem. Even when I thought I was being clear about expectations, people were still interpreting things completely differently than I intended.

Why Clarity Is Harder Than You Think

Even when you think you're being crystal clear, you're probably not.

I learned this the hard way when I realized that team members were interpreting my direction completely differently than I intended. I'd say "own this outcome" and they'd hear "do this task." I'd say "escalate when there's a problem" and they'd hear "escalate when you're sure it's a big problem."

The issue isn't intelligence. It's that everyone has a different mental model of what ownership means, what escalation looks like, what "good enough" is.

See the problem? Every word gets filtered through their existing assumptions about how things work.

Going back to the previous example. WHen the two engineers stopped by my office to tell me something was broken. Later, when I asked why the issue wasn't fixed, they said, "We didn't want to interrupt — you were busy."

To them, that sounded respectful. To me, it was a red flag. They assumed that because I was in a meeting, responsibility shifted upward — that ownership paused until I was available. In their minds, I was the bottleneck. In reality, they were.

If I had trained and mentored them properly, they would have known: You don't need permission to solve the problem you own.

The real failure wasn't that they didn't fix it — it's that the culture allowed them to believe my unavailability was a valid reason not to act. They confused deference with ownership.

That's when it clicked for me: Defensive people don't just avoid blame — they look for structural excuses to justify inaction.

It's not about bad people; it's about a system that teaches them that "waiting" is safer than "owning." When a team uses ambiguity — whether it's "move faster" or "you were in a meeting" — as a shield, you don't have a communication problem. You have a cultural one.

But here's what I learned: you don't fix permission-seeking behavior by giving more explicit permissions. That just creates new dependencies.

The Real Problem: They Were Trained to Seek Permission, Not to Think

When they didn't interrupt me, it wasn't about respect — it was a failure of ownership conditioning. They were operating inside a mental model that said: "If the boss is busy, my job is to wait."

That's a learned behavior. They were never trained to ask the deeper question: "Who owns the outcome if I do nothing?"

You don't fix that by saying "next time, interrupt me." That only creates a new dependency — another explicit rule they'll cling to. You fix it by changing what they believe ownership means.

Ownership isn't a set of instructions; it's an identity. People who own outcomes don't wait for permission — they assume responsibility until someone takes it from them.

So the goal isn't to teach them to interrupt — the goal is to create a system that exposes the cost of hesitation:

• When a problem goes unaddressed, the postmortem makes ownership visible by name
• When someone acts without waiting, they're recognized publicly for decisiveness
• When ambiguity exists, silence becomes guilt

That environment trains instinct. Eventually, they stop asking, "Should I interrupt?" and start asking, "What happens if I don't?"

Instead of "move faster on the API integration," it became "the user registration endpoint must be working by Friday, and I need daily progress updates starting tomorrow." No room for interpretation, no wiggle room for defensive deflection.

That's when I realized: defensive people don't just avoid taking blame — they actively use ambiguity to protect themselves. If the instruction isn't crystal clear, they can always claim they misunderstood rather than admit they didn't deliver.

This discovery led me to understand something deeper: culture problems start with people, but they persist because of systems. Most organizations don’t fix behavior — they build processes to work around it. Instead of confronting the person who hesitated, they add a checklist. Instead of addressing ownership gaps, they create escalation policies. Over time, the system becomes a safety net for avoidance — protecting comfort instead of accountability.

The Process Band-Aid Problem

Here's something I see constantly: teams that create processes to work around people instead of addressing the people problem directly.

Someone misses deadlines repeatedly, so instead of dealing with their accountability issue, the team creates a new approval process with more checkpoints. Someone doesn't communicate well, so instead of fixing their communication, they create more meetings and status updates.

These "solutions" don't fix anything. They just institutionalize the dysfunction.

The real problem isn't that processes are bad — it's that you can't process your way around people who won't take ownership. You end up with bureaucracy that protects poor performers while making everyone else's job harder.

Before you can fix processes, you need to see things for what they really are. And if people can't admit their own mistakes, they'll never see clearly enough to create processes that actually work.

What usually happens instead is they create processes that sound good but miss the point entirely:

• More documentation (when the problem is people don't read what already exists)
• More approvals (when the problem is people don't take initiative)
• More meetings (when the problem is people don't follow through)
• More oversight (when the problem is people don't self-manage)

All of these "solutions" treat symptoms while the real disease — lack of ownership — spreads.

Understanding this pattern was crucial, but it raised a bigger question: how do you actually implement change that sticks? Everything I'd learned about defensive behavior, ownership systems, clarity problems, and process band-aids pointed to the same conclusion: traditional approaches to culture change simply don't work.

---

Implementing Real Culture Change

Here's what I've learned about making culture change stick: it requires repetition, follow-up, and everyone actually wanting to change. You can't slow-roll it. You can't give people 3-6-9 months to "improve."

Successful culture change happens when you make it immediately uncomfortable for people to operate the old way.

The people who adapt fastest are usually the ones who can look at themselves first when something goes wrong. They ask "What could I have done differently?" before they ask "What went wrong with the system?"

The people who struggle are the ones who immediately start looking for external factors to blame. They're so focused on protecting themselves that they can't see the real problems, let alone fix them.

"Culture change isn't taught — it's tested."

Here's what actually works in practice:

Written Accountability: Verbal acknowledgment disappears. Written reflection anchors ownership. Every incident must end with written accountability from each person involved. No exceptions. No "we'll do better next time" fluff. People must write down what they personally could have done differently.

Self-Examination Before External Blame: Before anyone can point to process failures or external factors, they must identify their own contribution to the problem. "What could I have done differently?" comes before "What should we change about the system?"

Single-Point Ownership: Every failure must have one person who owns it. Not "the team failed." Not "we need better processes." One person who says "I saw this and didn't act appropriately" or "I made the wrong call here."

Address Defensive Behavior Immediately: When someone deflects or blames others, it gets called out in real-time. No delays, no dancing around it.

These aren't just theoretical principles — they're battle-tested through years of trial and error. But implementing them effectively required me to completely rethink how leadership itself works in a culture change context.

Leadership and Culture Change

The hardest lesson was shifting from solving problems to solving behavior patterns.

Early in my career, leadership meant correction. When something broke, I'd jump in and fix it. When someone struggled, I'd help them figure it out. I thought that was good leadership.

What became clear is that fixing problems for people doesn't change how they approach problems. It just makes them dependent on you to fix things.

The approach that works is precision and cultural enforcement. Here's how it looks in practice:

When someone gives a passive excuse like "we didn't have budget approval," the response needs to break it down into the real failure: "you waited for approval instead of owning escalation."

After that paid feature incident, when the team lead defended the engineer's 2.5-hour delay by saying it was "understandable given the circumstances," the conversation had to stop entirely. The response: "This is not ownership — this is waiting for permission."

The Root Cause of Most Failures

After analyzing dozens of postmortems across different teams and projects, I've found that almost every failure comes down to the same thing: people won't look at themselves first.

It's never just the technical system that fails — it's the accountability system. And the accountability system fails because people are more focused on protecting themselves than solving problems.

Almost every culture problem I'd encountered could be traced back to a leadership failure. Not technical leadership — cultural leadership. And that led me to develop a more systematic approach to making culture change actually stick.

Making Culture Change Stick

Successful culture change requires a proven system that consistently reinforces ownership behaviors:

1. Model extreme ownership from day one - When things go wrong, examine your own role before anyone else's. Even when it seems like you had nothing to do with it, find your contribution. This sets the tone for everyone else.

2. Require self-examination before external blame - "What could you have done differently?" must be answered before discussing process improvements. No exceptions.

3. Make defensiveness more painful than honesty - Reward people who admit mistakes and own problems. Make excuse-making immediately uncomfortable.

4. Require written reflection - No verbal hand-waving allowed in postmortems. People must write down their personal contribution to problems.

5. Address defensive behavior in real-time - When someone deflects or blames others, call it out immediately.

What becomes clear through experience: culture change starts at the top and trickles down. When leaders consistently examine their own role in failures — even when their connection isn't obvious — it creates permission for everyone else to do the same.

The result: People who can examine their own role in failures become better leaders, better teammates, and stronger culture contributors. The defensive people either adapt or become isolated.

The alternative to this approach is accepting that problems will keep repeating, that ownership will remain diffused, and that teams will always be one crisis away from dysfunction.