Why Do Good Policies and Business Systems Still Fail?

Business tools do not create execution

I developed my Leadership Execution System because I kept seeing the same gap. Businesses had plenty of tools. They had read the books. Attended the workshops. Downloaded the templates. Introduced the systems. And still they would ask:

"Why aren't people actually doing what they're supposed to do?" Because tools don't execute. People do. A worksheet doesn't create accountability. A KPI doesn't make somebody care about the result. A meeting agenda doesn't make people prepare.

A procedure doesn't make five managers apply the same standard. A deadline in an Action Register doesn't force somebody to honour it. The tool can support the behaviour. It cannot replace it.

The GAF'er principle

I use a particular word with my clients. A GAF'er. In Christine-speak, that's somebody who gives a fuck. You know those people when you meet them. They notice what matters. They take responsibility. They care about the result. They understand that their behaviour affects everybody around them.

They do not continually wait to be told. They do not see a hole in the ground and repeatedly walk around it because filling it is technically somebody else's responsibility. They think: This needs dealing with. Then they start thinking about what they can do.

That attitude is incredibly important because no business system on Earth can compensate indefinitely for people who simply don't care whether it works.

The tool matters — but the connector matters more

I am a great believer in useful tools. I built an entire Leadership Execution System around them. But the value is not having another worksheet sitting in a folder. The value is in the connection between: what the business says matters and what people actually do about it.

If the dashboard shows a problem, what does the manager do? If a commitment is made, does anybody follow up? If a deadline slips repeatedly, does anything happen? If the same process fails three times, does somebody improve the system?

If a one-on-one identifies a development area, is progress tracked? If a meeting reaches a decision, is there a clear owner? That's the connector. Without it, you have paperwork. With it, you have execution.

Most policy problems are actually consistency problems

One of the things I have noticed repeatedly is that businesses often assume a policy is broken when the real problem is much simpler. It isn't being applied consistently. One manager does it one way. Another manager does it differently. One employee gets away with something.

Another employee gets challenged for exactly the same behaviour. Now the team is no longer testing the policy. They are testing the consistency of the leadership team. And once people realise that the rules depend upon:

who is asking; who is managing them; who happens to be watching; or how much noise they make; you have created a very different problem. Nobody knows whether the standard really matters.

Ask the consistency question

Suppose two managers in your business face exactly the same situation today. Would they handle it broadly the same way? If the answer is no, expect confusion. Expect frustration. Eventually, expect resentment. Employees don't need every policy to be beautifully written.

They need reasonable confidence that agreed standards apply consistently. That is what creates trust. Not another twenty-page procedure. Leadership consistency.

Stop rewriting policies nobody applies properly

This is another trap. Something goes wrong. People complain. The management team decides: "We need a new policy." Perhaps you do. But first ask: What happened to the existing one? Was it unclear? Or did one manager simply ignore it? Did people know it existed? Was it trained?

Was it reinforced? Did leaders apply it consistently? Did anybody address breaches? Was there any follow-up? Because rewriting the policy will not solve a leadership inconsistency. You may simply end up with a newer document nobody consistently applies.

Standards become suggestions surprisingly quickly

Leaders sometimes say: "This is non-negotiable." Then somebody ignores it. Nothing happens. It happens again. Still nothing. Perhaps another manager applies the standard to somebody else. Now what does the organisation believe? Not what the policy says.

What leadership behaviour has taught them. They have learned: This is negotiable. That's why you have to be careful with management language. If something genuinely matters, it needs to matter when applying it becomes inconvenient. Otherwise, stop pretending it is a standard.

Systems fail when leaders rescue people from them

Imagine you introduce a new process. Everyone is supposed to submit information by Thursday. One person doesn't. So the manager says: "Never mind, just tell me now." Next week, same thing. Another manager says: "I know you're busy. I'll do that part for you."

What has the organisation learned? Not: "We have a Thursday process." It has learned: "Thursday is optional if somebody rescues me." Leaders often destroy their own systems by rescuing people from the discipline required to make those systems work.

If the process matters, support people in using it. Train them. Fix genuine flaws. But don't repeatedly bypass it and then complain that nobody follows it.

Don't confuse poor execution with a poor tool

Suppose your Action Register isn't working. Before replacing it, ask: Are actions clear? Do they have one owner? Do they have a real due date? Does anybody review them? What happens when they are missed? Do managers endlessly roll them forward? If nobody follows up, the problem probably isn't Excel.

Likewise, your dashboard may be perfectly adequate. The issue may be that nobody discusses what the numbers mean. Your one-on-one template may be fine. The issue may be that managers turn the meeting into a lecture. Your meeting agenda may be good. The issue may be that nobody prepares.

Do not automatically blame the tool for behaviour occurring around it. But don't keep a bad system merely because it exists The opposite is also true. Sometimes the process genuinely is rubbish. Perhaps it is too complicated. Perhaps nobody understands why it exists.

Perhaps it asks for information nobody uses. Perhaps the software creates double handling. Perhaps the approval process was designed when the company had five people and now has fifty. Good execution does not mean blindly complying with bad systems forever. GAF'ers should notice that too.

The useful question is: Is this system helping us achieve the result we want? If not, improve it. But improve it deliberately. Do not simply ignore it individually while everybody else continues pretending it exists.

Consistency doesn't mean mindless rigidity

Applying standards consistently does not mean applying them stupidly. Context matters. Judgement matters. There will be exceptions. But an exception should be understood as an exception. Not a completely different rule depending upon which manager happens to be working.

You want enough consistency for people to understand: This is generally how we do things around here. Then managers can apply reasonable judgement inside that framework. That is very different from everyone inventing their own management system every day.

People watch what leaders tolerate

Culture is not built only by the values on the website. It is built through thousands of small leadership decisions. What gets challenged? What gets ignored? What gets rewarded? What gets allowed to happen again?

If one manager continually fails to follow a basic process and nobody addresses it, that becomes information. If somebody repeatedly misses commitments and dates simply keep moving, that becomes information.

If the supposedly non-negotiable rule is regularly waived for a particular high performer, that becomes information too. People watch. They work out very quickly what actually matters around here.

Great tools expose behaviour

One reason useful business tools can feel uncomfortable is that they make things visible. An Action Register shows whether somebody follows through. A dashboard shows whether the number moved. A weekly accountability meeting shows which commitments keep rolling over.

A one-on-one reveals whether somebody is developing. A What Success Looks Like document makes expectations harder to pretend were never discussed. That visibility is a feature, not a flaw. But it only becomes useful when managers are willing to have the conversation that follows. The tool reveals.

Leadership responds.

Don't make the system somebody else's job

Another reason systems fail is that ownership gets handed to administration. Finance owns the dashboard. HR owns performance management. Operations owns procedures. The executive assistant owns the Action Register. Fine — those people may administer the mechanism.

But management still owns the behaviour. Finance can produce the KPI. They cannot force the sales manager to improve conversion. HR can provide the performance-management process. They cannot replace the manager having the conversation. Administration can record the action.

They cannot make the owner honour the commitment. Tools may have administrators. Execution needs owners.

Build systems around real management behaviour

A good system should make useful behaviour easier. For example: A weekly meeting should make it easy to see commitments and follow up. A dashboard should make important patterns visible. A one-on-one structure should help the employee think.

A What Success Looks Like document should make development expectations clear. A Decision Knowledge Capture tool should stop useful learning disappearing back into somebody's head. An Action Register should stop commitments evaporating once the meeting ends.

The system should support the management discipline you actually want. That is why simply buying software is rarely the answer. Start with the behaviour. Then choose or design the mechanism that supports it.

Test the system under pressure

Policies and systems often look wonderful when nothing difficult is happening. The real test comes when following them is inconvenient. The customer is angry. The employee is your best performer. The manager is busy. The deadline clashes with something else. Someone says:

"Can we just make an exception this once?" Sometimes yes. But notice what you do. If every difficult situation causes the system to collapse, you do not really have a system. You have a preference.

Ask what happened after the tool was introduced

When businesses introduce something new, they often focus heavily on launch. Training session. Email. New template. New software. Announcement. Then everybody moves on. Three months later nobody knows whether it changed anything. Instead ask: Are people using it?

Is it producing better conversations? Are decisions clearer? Are commitments more visible? Is follow-through improving? Are managers behaving differently? Are results changing? If not, why not? That is how you turn implementation into learning.

Don't let compliance become the goal

The objective is not: 100% of forms completed. The objective might be: better thinking; clearer ownership; faster decisions; fewer recurring mistakes; stronger accountability; more capable managers; more consistent customer experience. The form is only useful if it helps create the outcome.

That is an important distinction because organisations can become very good at complying with a process while completely missing its purpose. You can fill out every box and still manage badly.

The Leadership Execution System isn't magic either

I should say this about my own tools. The Leadership Execution System will not magically improve your business because you downloaded it. Of course not. Its value comes when leaders use the tools to connect the dots. What are we trying to achieve? What does success look like?

What are the numbers telling us? What are people doing about it? What commitments were made? Are they happening? What did we learn? What needs to change next? That is the execution system. The documents simply help make those questions visible and repeatable.

Look for the GAF'er behaviour

When implementation works well, you will usually see people behaving differently. They notice. They prepare. They bring evidence. They flag problems early. They don't wait until somebody chases them. They follow through. They improve things.

They ask what the business needs rather than endlessly retreating behind: "That's not my job." That is the give-a-fuck factor.

And I would rather have a fairly simple tool being used properly by a team of GAF'ers than the world's most sophisticated management platform being ignored by people who do not care.