The Payroll System That Depended on One Person
A few weeks ago, I sat down with an interim HR manager who was having a rough week. A newly developed integration connecting new billing software and the existing financial system with the payroll and HR environment was scheduled to go live within days. Then the finance manager resigned. With her, went most of the knowledge about how the payroll system actually worked. What had looked, until that point, like an ordinary software rollout suddenly became a business continuity issue: could the company still pay its people correctly and on time? The situation became more complicated the longer we talked. The HR and payroll platform needed to connect to four separate systems before the overall environment could operate as intended. Each integration had its own configuration, data flows, dependencies and potential points of failure. Keeping all of that working requires specialist knowledge that many companies no longer have in-house and increasingly have to buy from consultants. It raised a simple but important question:
How much complexity should an organisation tolerate just to run HR and Payroll?
There is nothing wrong with integrations in principle. Any organisation of scale needs payroll to connect with finance. HR systems need to exchange data with identity management, workforce planning and other business applications. The problem starts when integrations stop being connections and become the architecture itself. When employee data is scattered across several systems and vendors, a change in one application can ripple through the rest. On paper, the company may have modern software. In practice, it has created a web of dependencies that requires constant maintenance. And that fragility often remains invisible until something changes. Someone leaves. An integration fails. A supplier changes something. A process needs to be redesigned. Then the institutional knowledge walks out of the door, ownership becomes unclear, and consultants are called in to explain an environment the organisation thought it already understood.
Standardisation can create its own problems
There was a second issue in this case and it gets less attention. The new platform was highly standardised in the neat, vendor-brochure sense of the word, but offered relatively little room to adapt to how the organisation actually worked. That may sound like a technical detail. It is not. HR sits very close to company culture. Approval structures differ. Organisational models differ. Performance processes differ. Policies evolve differently. Decision-making structures vary between companies, countries and legal entities. Often, there are good reasons for those differences. Software that cannot accommodate them eventually forces a choice: change the organisation to fit the software, or build workarounds around the system. And those workarounds tend to reproduce exactly the complexity the software was supposed to remove. Spreadsheets return. Manual controls appear. Additional applications are introduced. Exceptions are managed outside the platform. The system may still be called standardised, but the operating model around it becomes increasingly fragmented.
Integration is not the same as unification
That distinction matters. An integration allows two separate systems to exchange information. A unified platform removes the need for many of those exchanges in the first place. HR and payroll are fundamentally connected. Changes to contracts, salaries, working hours, leave, benefits and organisational structures all have payroll implications. Yet many organisations still operate environments where this information travels through multiple applications before it reaches payroll. Every additional hand over creates another dependency. That is not necessarily a technology problem. It is an architectural choice. And CHROs and CFOs should question that choice more often.
HR technology should reduce dependency
What stayed with me from this conversation was less about one implementation or one resignation than a design question that does not get asked often enough: “Is HR technology making the organisation less dependent on individual people, interfaces and specialist knowledge or is it creating new dependencies?”
That is one of the principles we build from at PeopleCoral. We believe HR and payroll should operate from one platform and one employee data foundation, rather than being stitched together from multiple applications, vendors and interfaces. Integrations will always remain necessary. They connect HR with Finance, IT and the wider business. But integrations should connect HR to the organisation. They should not be doing the work of holding HR itself together. The platform also needs to remain adaptable. Companies change. Regulations change. Organisational structures change. Operating models change. Software that cannot change with them eventually becomes another constraint.
Complexity is easy to ignore when everything works
None of this is particularly visible while systems are running smoothly. A fragmented environment can appear perfectly manageable for years. Until someone resigns. Until integration fails. Until a company acquires another business. Until payroll expands into another country. Until management asks for consolidated information across entities.
That is when the real cost of complexity becomes visible. The purpose of HR technology was never to create another layer that organisations need to manage. It should make HR simpler to operate, easier to change and harder to break. And if running payroll depends on one person understanding how five different systems fit together, that is probably a sign that the architecture deserves another look.