Leadership Under Load — Ego Lifts Get You Injured

Every gym has one.

The person who loads more weight than they can actually lift. A quick glance around, a slightly louder-than-necessary grunt, plates added to the bar with quiet theatre. The bar comes up halfway, the back bends, and someone rushes in to help.

In the gym I call this an ego lift — lifting to be seen, not to be strong.
In organisations, the same instinct shows up as well-intentioned leadership optimism.

In many ERP implementations — especially SAP Business One rollouts — a familiar moment appears early. A senior leader, often well-meaning and energetic, announces a timeline.

“We will go live in 90 days.”
“This will solve our reporting issues.”
“After this, decisions will be data-driven.”

The room becomes silent. Not because everyone agrees, but because nobody wants to be the person who says it cannot be done. The leader is not lifting a barbell. The leader is lifting expectations. And expectations are heavier than steel.

Ego lifts rarely come from arrogance. They come from pressure. Boards want speed. Customers want reliability. Teams want clarity. Investors want certainty. Leadership fills uncertainty with confidence.

But confidence is not capacity.

ERP implementation is not a motivational project. It is a structural one. Master data must be cleaned. Processes must be redesigned. Roles must become clear. Users must learn new behaviour. Old habits must fade slowly. Hero cultures skip this phase and go straight to the heavy weight.

What follows is predictable. Timelines shrink artificially. Training is rushed. Testing becomes symbolic. Exceptions multiply. Workarounds begin. The organisation technically goes live. Operationally, it does not.

Excel stays “just for safety.”
Approvals continue on WhatsApp.
Reports are distrusted.
Finance reconciles manually.

From the outside the lift looks successful. Inside the muscle, a tear has already begun.

This is the most dangerous ERP failure — not collapse, but partial adoption. The system exists, but behaviour does not change.

In the gym, ego lifting injures the back. In organisations, it injures trust.

After one strained implementation, employees stop believing timelines, managers stop committing to change, IT stops getting cooperation, and leadership stops receiving honest feedback. The next project becomes harder before it even begins. People do not resist technology. They resist pain they have experienced before.

I should admit this — I have done ego lifts too. Not dramatic ones. The polite corporate version. And occasionally, the literal gym version.

There are days when you feel unusually energetic. You slept well. The music is right. You want to progress faster than your body has negotiated for. So you say to the trainer, “Let’s increase the weight today.” Sometimes you don’t say it directly. You just repeat, “I think I can.”

My trainer does not argue. He just gives a look.

It is a calm, very firm no — the kind you immediately understand is not about authority. It is about consequence. A good trainer is not managing today’s lift. He is protecting tomorrow’s workout. Some days your muscles are strong but your stabilisers are tired. Some days your enthusiasm is ready but your joints are not. You do not always have the data to judge your own capacity.

Leadership works exactly like that.

Many times in ERP projects, leaders — including me — push timelines not out of ego, but optimism. We see benefits early and want momentum. We want progress to feel real. But organisations also have stabilisers: users learning new screens, finance closing cycles differently, managers trusting system reports, teams unlearning parallel processes.

When we push the organisation to lift more than its readiness, the system does not collapse immediately. It compensates. People work late. Excel returns quietly. Manual approvals restart. The project looks successful until months later adoption falls.

That is when you realise what the trainer already knew.

Capacity is not decided by motivation. It is decided by repeatability.

The strongest lifters in the gym are not the loudest. They warm up, start light, repeat movements correctly, and add weight slowly. They are not trying to impress the room. They are trying to survive repetition.

Good ERP leadership looks the same. Strong leaders say: we stabilise master data first, we pilot before scaling, finance closes one full cycle in the system before go-live, adoption matters more than date. It sounds cautious. It is actually courageous. The hardest leadership act is not making a promise. It is setting a boundary.

Hero culture says a strong leader solves problems personally. System culture says a strong leader builds a system where problems reduce over time.

ERP implementations succeed when leadership stops trying to be the strongest individual in the room and becomes the protector of process discipline. The goal is not a dramatic go-live. The goal is a boring month-end close.

If your ERP implementation feels exciting on launch day, be careful. In the gym, excitement during the lift usually means the weight is wrong. Organisations rarely fail on the day of the ego lift. They fail slowly — through workaround, fatigue, and quiet disengagement.

Strong leadership does not lift the heaviest weight.

It lifts the weight the organisation can repeat tomorrow. 

And sometimes the most responsible leadership decision is simply this: Not yet. We build strength first.

Leadership Under Load — Episode 3 The Warm-Up Is Not Optional

The warm-up is that part of the workout where your body negotiates with you to go back home.

It begins almost immediately. The intention is sincere, the schedule has been blocked, you have worn the right shoes, carried the water bottle, and declared to yourself that today you will be disciplined — and within five minutes your hamstrings file objections, your shoulders remember old grievances, and your knees suddenly develop a philosophical opposition to effort. Nothing heavy has started yet. No serious work has begun. And still, this is when resistance is at its peak.

Not during the lift. Before it.

My trainer has this habit of telling me stuff that I just don’t like, especially at that specific moment when he is — the warm-up isn’t conditioning your muscles, it’s testing your commitment. Your body is quietly asking whether you truly intend to do what you confidently declared at the entrance. And some days I strongly dislike my trainer. It’s a very particular irritation reserved for the person who is absolutely right, sees what you are avoiding, refuses to indulge your explanations — and is also the person you are literally paying to make you uncomfortable.

And this is exactly what the client begins to feel about us when we start Business Process Mapping.

The project has already had a confident beginning. Leadership has attended the kick-off. Timelines have been discussed. Everyone agrees the organisation needs structure. The vendor presentation was clear. There is relief that “a system” is finally coming. Then the first real working session happens.

Business Process Mapping.

And suddenly enthusiasm develops a calendar conflict.

“Do we need all departments present?”
“Can we shorten these workshops?”
“Can you just configure the system and show us?”
“Users will learn once they see the screens.”
“We will clean up processes after go-live.”

This is not resistance to software. This is the organisation negotiating to go back home.

Because BPM is the moment the project stops being about technology and starts being about behaviour.

During BPM sessions no one is learning SAP, or any ERP for that matter. Instead something far more uncomfortable happens. Sales realises delivery commitments are made without checking capacity. Production explains plans change depending on who escalates the loudest. Finance quietly admits reports are manually corrected before management sees them. Operations discovers three different departments maintain the same master data in three different spreadsheets and each one believes theirs is the correct version. Leadership notices decisions depend on individuals, not processes.

This is why BPM feels exhausting. It is not documentation. It is organisational self-awareness.

In the gym the warm-up exposes stiffness you didn’t know you had. In organisations BPM exposes dependencies you didn’t know you relied on. And in both places the instinct is identical — skip it and get to the “real work.”

Companies often want training quickly. “Let users see the screens, they will understand.” But training without process clarity creates a predictable outcome. Users learn transactions but not flow. Approvals continue on calls. Updates continue on WhatsApp. Spreadsheets quietly survive in the background. Data is entered at the end of the month just before review meetings. And then leadership concludes the software is good but adoption is poor.

Adoption is not poor. Preparation was skipped.

We assume change management begins after the system arrives. It does not. Change management begins when people participate in deciding how work will happen. A warehouse supervisor who helps design the goods receipt process rarely resists the system later, because the system is no longer management’s imposition — it is his workflow. People do not resist change as much as they resist loss of control.

A kick-off meeting therefore is not the beginning of implementation. It is the beginning of alignment. If the first question after kick-off is “when is go-live,” the project is already in danger. The more important question is quieter — “how do we actually work right now, truthfully?”

ERP systems rarely fail because the software cannot handle complexity. They fail because organisations try to automate assumptions. BPM is where those assumptions surface. And just like a warm-up, it feels unnecessary only until the consequences of skipping it arrive.

In the gym, the warm-up feels like delay. In reality, it is what allows you to train tomorrow.

In organisations, BPM feels like lost time. In reality, it is what allows the system to survive go-live.

The strongest lifters respect the warm-up the most. The most successful implementations respect the beginning the most.

Because speed without preparation is not efficiency.

It is damage… simply scheduled in advance.

 

Form Fails Before Strength Does: What the Gym Taught Me About ERP Implementations

My trainer has been trying to teach me this for years. Every time a lift felt difficult, I drew the same conclusion: I’m not strong enough yet.

Every time, he stopped me. “Strength shows up fast. Form shows up when you’re tired.”

It took me a long time to understand what he meant.

In strength training, Form and Technique are not the same thing.

Form is structure—posture, positioning, alignment. It is how the body holds itself under load. A stable spine in a deadlift. Balanced knees in a squat. Form protects joints and prevents injury. Its goal is longevity.

Technique is execution — the sequence of movement: breathing, tempo, bar path, muscle activation. The technique helps you move the weight efficiently and perform at your best.

Technique is about performance. Form is about safety and structure.

You can learn the technique relatively quickly. Form takes much longer because it must be built into the body.

And here is the subtle part my trainer kept repeating: Good form does NOT look identical for everyone.

Two lifters can both squat safely with excellent form, yet the movement can look different. Their height, limb length, hip structure — their physical build — changes how alignment appears. The structure is sound, even if the posture is not identical.

Good form creates stability. Uniformity is not the same as stability.

It took me years to understand why that matters.

Because ERP implementations often make the same mistake.

ERP programs are excellent at teaching technique:

• which transaction to use
• which fields to fill
• which steps to follow

Users learn the screens. Training is completed. UAT is signed off. But what determines whether the system survives scale is not technique. It is form!!

A user once told us, “The system tells me what to do. It doesn’t tell me who is allowed to decide.”

That is not a training gap. That is structural misalignment. In an organisation, ERP form is:

• clear process ownership
• stable decision rights
• governance that resolves exceptions
• shared rules that apply consistently

Here is where organisations struggle.

They interpret “standardisation” as identical processes everywhere — across roles, locations, and realities. But just as different bodies lift safely in different ways, different parts of a business may legitimately execute a process differently while still respecting the same structure.

Technique must be consistent.
Form must be stable.
Execution need not be identical.

A sponsor later observed: “The system works, but people keep going around it.”

Often, that happens not because users resist discipline, but because the organisation enforces uniformity rather than building structure. When processes ignore context, people create workarounds to get their jobs done.

Just like lifting, poor form does not fail immediately.
It fails under repetition.
Under pressure.
Under growth.

ERP systems rarely break at go-live.
They break at scale — when volume rises, exceptions increase, and decisions need clarity.

That is why strong implementations focus on form before force:
They stabilise decision rights before enforcing compliance.
They define ownership before automation.
They align governance before scale.

Technique can be trained in weeks. Form must be designed.

It took my trainer years to get me to understand this: strength is never the starting point. Structure is.

Strong ERP programs scale on form, not force.
Processes, governance, and culture carry the load.
When form fails, strength gets blamed — but unfairly.