Once bitten: why "not another
system" is the wrong lesson.

I hear it in almost every first meeting with a new HR leader. I'll be halfway through explaining what Beny does, and I'll watch their shoulders drop half an inch. Not because the idea is wrong. Because the word "implementation" just landed, and somewhere in their memory a project from three or four years ago is replaying in full, painful detail.

I get it. I've sat on the other side of enough of these conversations now, as a co-founder building HR technology, to know that the scar tissue is real. Somebody sold their business a platform once. It took twice as long as promised. The data migration was a mess. Employees hated the login flow. IT was never properly looped in. When it finally launched, usage cratered within a month and the whole thing quietly became "that system we're stuck paying for."

So when the next vendor walks in, even one with a genuinely different offer the answer is already forming before the pitch is finished: not another system.

I understand the instinct. I don't think it's an unreasonable one. I do think it's the wrong lesson from the right experience, though, and it's quietly costing businesses far more than the implementation they're avoiding.

The stigma isn't about technology. It's about trauma.

Nobody in HR is afraid of software. What they're afraid of is being the person who championed the last rollout that went sideways, and having to explain to the CFO why the business is now managing yet another underused line item which, funnily enough, is exactly the conversation my co-founder wrote about in his last post on this. Unused benefits and stalled systems are the same failure wearing different clothes. Something gets bought, poorly landed, poorly adopted, and quietly written off as a lesson in "we tried that."

The problem is that lesson gets generalised. One bad rollout becomes "systems implementations are always painful," which becomes "we're better off with what we've got," which becomes a business running five-year-old processes because the alternative feels riskier than the status quo. I've watched genuinely good HR leaders talk themselves out of improvements that would have taken their team a fraction of the time they feared, purely because the last experience left a mark.

Here's what that costs, in plain terms. It costs the hours your HR team spends every week on manual workarounds for a problem a modern system would have solved in a click. It costs the candidates and employees who quietly notice that your processes feel a generation behind your competitors'. It also costs you the compounding advantage of getting the fix in twelve months ago instead of waiting for "the right time," which to be honest rarely arrives on its own.

Most bad implementations fail for the same three reasons.

Having now been on the vendor side of dozens of these rollouts, I can tell you the failures are rarely about the software itself. They almost always come down to three things, and all three are avoidable if you know to look for them before you sign.

The first is scope creep dressed up as thoroughness. Somebody decides that since the business is finally implementing a system, it should solve every adjacent problem at once. Every extra requirement adds weeks. A project that should have taken six weeks stretches to six months, momentum dies, and the business ends up going live with a bloated version of what it actually needed.

The second is treating implementation as an IT project rather than a change management one. The technical setup is usually the easy part. What actually determines whether a system succeeds is whether people understand why it exists, what's in it for them, and how to use it without having to ask someone. Businesses that skip this, that assume a login email and a PDF guide constitute a launch are the ones who end up with 20% adoption six months in.

The third is choosing a vendor who treats "go live" as the finish line. If a provider disappears the moment the contract is signed and the system is switched on, you're on your own for the part of the process that actually determines whether it sticks. The businesses that get burned are almost always the ones who didn't ask, before signing anything, what support looks like in month three.

What I'd tell any HR Director weighing this up.

None of this means implementation risk isn't real. It is. The fix isn't avoidance, it's due diligence on the right things. Before you rule out a system because the last one hurt, ask the vendor in front of you three questions.

1. How long does a typical rollout actually take, with a real business your size, not the best-case number in the sales deck.
2. Who owns adoption after launch, and what does week four look like, not just week one.
3. What happens if usage stalls three months in? Is there a plan, or is that your problem now.

If a vendor can answer those clearly, the implementation risk you're carrying drops dramatically, because most of what goes wrong in a rollout is predictable and manageable well in advance. If they can't answer clearly, it tells you which failure mode you're signing up for before you've signed anything.

The businesses I respect most in this space are the ones who've stopped asking "should we implement something new" and started asking "what would a good implementation actually look like, and who's willing to be accountable for it." That's a very different question, and it tends to get a very different answer.

Scar tissue is a reasonable teacher. Just make sure it's teaching you to ask better questions, not to stop asking them at all.