Why won't my team follow the new system?

Edit of TIH - 2.4 The System looked great on paper

===

[00:00:00]

[00:00:00] HOOK

---

[00:00:00] Linda van Egmond: Let me describe something that probably sounds familiar. so you've identified a problem, a process that is messy, slow, or just not happening consistently, and you do the right thing. You document it. You write out the steps, and you train the team.

You maybe even build it into whatever project management tool you're using, and then about six weeks later, nobody's using it. Not because your team is trying to annoy you, and not because the process was wrong, but because something about it just didn't stick, and you're standing there looking at a perfectly designed system that has absolutely no relationship with how things actually work in your business.

This episode is about why that happens and what to check before you roll anything out.

[00:00:52] REALITY CHECK

---

[00:00:52] Linda van Egmond: I worked with a company in growth mode. They were super serious about getting more professional in how they operated. We built a process together, [00:01:00] and it was good. It had clear steps and clear ownership, and it was documented properly, and we trained people on it, like the works.

And it fell apart anyway. Not dramatically and not overnight. It just quietly stopped being used. People defaulted back to how they'd always done things, and the new process got treated like a suggestion rather than a way of working.

When I looked at what went wrong, it wasn't the process. The process was fine. What was missing was the culture around it. The team understood what the new process was, They just did not understand why it existed, what the problem it was solving was, and why the old way wasn't good enough anymore.

So when the new way felt slower, as all new things do, they went back to the old way Because the old way worked fine as far as they could tell.

[00:01:57] THE SHIFT

---

[00:01:57] Linda van Egmond: Here's what I've come to believe after seeing this happen [00:02:00] more than once. A process is only as strong as the culture that holds it.

You can have the most logical, the most well-documented system in the world. If the team doesn't trust it and doesn't see why it exists, or if it conflicts with how power and decisions actually flow in your business, it will not survive a week Think about it like moving a plant.

You can have the right pot, the right soil, the right amount of light, but if you move a plant that's adapted to one environment to a completely different one and don't give it time to adjust, it dies. It doesn't matter how healthy it was before. A new process needs the same thing, not just the right design, but the right conditions as well.

And the conditions most founders skip are the human ones. Does the team actually understand why this matters? And does the process fit the real decision-making [00:03:00] structure, not the official one? And this is one nobody asks: who in the team is most likely to break it first, and why?

The last question sounds a bit brutal, but it's one of the most useful things you can think about before you launch anything new. because there's almost always someone whose workloads, habits, or role becomes harder with the new process.

And if you haven't thought about that person in advance, they will become the hole in your system without either of you meaning for this to happen.

[00:03:33] THE MOVE

---

[00:03:33] Linda van Egmond: So before you roll out any new process, ask three questions. Question one: Does the team understand why and not just what? Can someone on your team explain in their own words what the problem is that this process solves and what goes wrong if it's not followed? If the answer is no, more training is not the solution .

A real conversation, not a presentation, [00:04:00] about why this matters is something you need to do Question two is, does this fit how decisions actually get made here? Look at every approval step and every handoff and every moment where someone has to wait for someone else, and then ask yourself, does that map to how things actually work in this team, or does it map to how things are supposed to work on paper?

Those are often Two very different things. And if there's a mismatch, fix it before you launch, Not after people have already found the workaround, because they will. Question number three is, who is going to break this first and why?

Go through your team and think about whose day this new process makes harder. Not who will be difficult about it, that's a different question, but whose actual workflow creates a genuine reason to skip a step or to default to the old way, and then [00:05:00] talk to that person before you launch. involve them in the design if you can, and at minimum, make sure they feel seen and not just trained.

With the company I mentioned earlier, we went back and did this work after the fact. We had a conversation about why. We adjusted the approval steps to fit the actual decision-making rhythm, and We identified the two people whose jobs made this new process genuinely inconvenient and worked with them specifically.

The second time, thankfully, it stuck.

[00:05:31] WRAP + CTA

---

[00:05:31] Linda van Egmond: A system that looks great on paper is not a system, it's a plan. A system is what people actually do on a Thursday afternoon when things are busy and an easier path is right there. So before your next rollout, take 20 minutes and go through those three questions: why, not just what; real decisions versus official decisions; and who breaks it first.

It will save you the experience of [00:06:00] discovering the answer to all three of them the hard way. That was it for this week. See you next week.