How to Run Global Benefits Without Firefighting

Benefits technology was supposed to reduce administrative burden. That was the promise: centralisation, automation, scale.

It hasn’t played out that way.

As Carl Chapman put it at the start of our recent webinar discussion with Workday’s John Whitaker, and benefits expert Mark Kelly,

‍“if you look across most global organisations today… work hasn’t gone down. It’s increased.”

That increase isn’t marginal. It shows up in persistent ticket volumes, in payroll corrections becoming routine, and in the disproportionate strain triggered by relatively small expansions. None of that points to a workforce problem. It points to a systems problem.

The uncomfortable conclusion is that technology hasn’t removed complexity. It has changed how complexity is handled — and more often than not, pushed it back onto people.

Scale isn’t the cause of complexity. It’s where it becomes visible

There’s a tendency to treat global scale as the moment things become difficult. More countries, more vendors, more rules — therefore more complexity.

But that explanation doesn’t hold up under scrutiny.

What scale actually does is expose the quality of earlier decisions. John Whitaker, who has led international benefits at Workday and previously scaled Amazon into new markets, put it plainly: “every decision that you make at that point will be amplified further down the road.”

Those early decisions rarely feel consequential. A cash allowance instead of a structured benefit. A local vendor chosen for speed. A workaround on data requirements because the system isn’t ready. Each one is defensible in isolation.

Collectively, they create a system that might not scale cleanly.

Whitaker’s point reflects a pattern most global teams recognise. What begins as a pragmatic compromise becomes embedded, and by the time the organisation reaches real scale, those compromises are experienced as operational friction.

At that stage, the system isn’t struggling because it’s complex. It’s struggling because it was never designed to contain complexity in the first place.

Tech often redistributes complexity rather than resolving it

Much of the market still operates on the assumption that better platforms solve this problem. Integration, automation, unified systems — the language is familiar.

The lived experience is different.

Chapman described the pattern succinctly: “we see ticket volumes that never really stabilise… payroll corrections becoming part of the operating rhythm.”

That’s not what successful automation looks like.

What’s happening instead is a redistribution of work. Tasks that should be handled by systems are pushed into:

• manual reconciliation
• exception handling
• post-go-live data fixes
• cross-functional coordination

The system appears to function, but only because people are compensating for its limitations.

This is why organisations can believe they have an “integrated” setup while still dealing with constant downstream issues. The integration exists at the surface level, not in the underlying logic.

Whitaker’s observation that “for the last 20 years we’ve not been able to get an accurate report sent to payroll” is telling in this context.  It’s not a complaint about tooling in isolation. It’s an indictment of how little progress has been made on the fundamentals.

“For the last 20 years we’ve not been able to get an accurate report sent to payroll”

Firefighting is the consequence, not the failure

Once complexity is being managed by people rather than systems, firefighting is inevitable.

Mark Kelly, formerly Global Head of Benefits at BCG, described the effect directly:

‍“the strategy doesn’t even appear. It just never gets built.”

This isn’t a question of capability, it’s a question of capacity. When teams are absorbed by renewals, corrections, and vendor management, the time required for strategic thinking simply doesn’t exist.

Whitaker quantified it more bluntly. In his experience, “probably up to about 90% of your time” is consumed by what he calls “busy work” — activity that keeps the system running but doesn’t move it forward.

At that point, decision-making shifts. Teams stop optimising for the business and start optimising for manageability. Renewals are deferred because there is no bandwidth to run them properly. Vendor changes are avoided because the process is too onerous. Complexity is tolerated because removing it would require more effort than living with it.

This is how firefighting becomes the everyday reality rather than a temporary state.

The industry’s fixation on interface misses the point

A significant part of the problem is where organisations focus their attention when evaluating technology.

Interface quality, employee experience, analytics, AI — these dominate buying decisions today. They are also, in most cases, of secondary importance.

The failure points sit elsewhere: in eligibility logic, in data architecture, in payroll alignment, in local compliance handling. These are less visible, harder to demonstrate, and far more consequential.

Whitaker’s warning on this is direct:

‍“if benefits technology can’t do the fundamentals… it doesn’t matter what the dashboards and AI look like.”

The sequencing matters. Until the system can reliably handle enrolment, data flow, and payroll output across countries, additional layers of sophistication add very little. In some cases, they make the problem worse by obscuring it.

Complexity is often designed in, not imposed

There is also a more uncomfortable point beneath this.

Some of the complexity isn’t imposed by global variation. It’s introduced by design choices.

Whitaker noted that “we build a lot of complexity into this… almost as a badge of honour.”  More benefits, more rules, more edge cases — all intended to improve the employee experience.

The result is frequently the opposite. Employees engage with benefits infrequently and often superficially. “They look at their benefits once a year, if we’re lucky,” he said.

What they experience isn’t engagement, but confusion. What teams experience isn’t flexibility, but administrative load.

This is where the distinction between design and infrastructure becomes important. Complexity that’s intentional and supported by systems can be valuable. Complexity that’s layered onto fragile infrastructure becomes chaotic.

What changes when the system actually works

The discussion points to a more pragmatic definition of success.

Not transformation. Not innovation. Control.

When the underlying system works as intended, three things change.

First, administrative work stabilises. It doesn’t disappear, but it becomes predictable rather than reactive.

Second, change becomes manageable. Adjustments to vendors or benefits do not trigger cascading failures across payroll and data flows.

Third, teams recover the capacity to operate strategically. Whitaker described the effect of removing renewal-driven admin through a global underwriting approach: it “elevated my team” and created the space to launch materially new programmes.

That sequence tells us something. Strategy doesn’t emerge from better ideas. It emerges from removing the conditions that prevent it.

A more useful way to evaluate systems

Most organisations still assess their setup based on what they can see: interface quality, reporting capability, the promise of analytics.

A more useful question is simpler, and less comfortable:

Are the hard parts working?

Chapman framed it directly: “not the interface… the configuration, the governance, the payroll output.”

Can the system enrol employees accurately across countries?

Does data move cleanly between systems without manual intervention?

Can you make changes without creating downstream issues?

If the answer to those questions is no, then the issue isn’t a lack of features, it’s an infrastructure failure.

Where this leaves the employee benefits category

There’s nothing particularly novel in any of this. That’s part of the problem.

As Kelly noted, “we’re talking about the same stuff that we were talking about 15, 20 years ago.”

The industry has spent that time improving surfaces — better interfaces, better reporting, more sophisticated narratives about AI. The underlying mechanics have changed far less.

Until that’s addressed, nothing will change. More technology will be introduced. Work will continue to increase. Teams will continue to compensate.

The alternative is less about innovation and more about discipline: designing systems that can actually contain complexity, and proving that they work under real conditions.

The most practical way to assess that’s not through a sales pitch. It’s to see the system operate — in its hardest moments, not its cleanest ones.

That’s where the difference becomes visible.

Watch the webinar

‍