New-country onboarding dropped from months of engineering work to weeks of plugin configuration, and a single unified audit trail replaced six disconnected compliance stories. The starting state: a workforce management company running payroll across six countries as six entirely separate codebases — each with its own team, its own deployment path, and its own interpretation of what "the payroll system" did. Six countries was the ceiling. A seventh would not have been survivable under the existing architecture.
The challenge: redesign the payroll platform so country-specific compliance could change independently of the core, without turning every regulatory update into a six-way engineering exercise.
Starting Conditions
The workforce management company had grown from serving a single country to serving six over several years. Each expansion had been treated as a new build. The team that launched the second country had copied the first country's codebase and adapted it. The third country had copied whichever of the first two was closest to its regulatory environment. By the sixth, the codebase lineage looked like a genealogy chart and the differences between siblings had become impossible to track.
Scale and divergence. Six country codebases. Six deployment pipelines. Six on-call rotations. The engineering organization was structured by country rather than by capability, which meant that seventy percent of the work — the part that was actually the same across countries — was being done six times in parallel by teams that did not talk to each other.
Regulatory cadence. Payroll compliance is not static. Tax thresholds change annually in every jurisdiction. Statutory deduction rates change on legislative timelines that do not align across countries. New reporting obligations arrive without warning. Under the silo architecture, every regulatory change triggered a six-country engineering exercise — not because six countries had changed, but because any fix to the shared-by-convention payroll logic had to be re-applied in six places by six teams, and any drift between the six implementations was a compliance exposure.
Bug propagation failure. When a defect was found in one country's payroll calculation, there was no structural mechanism to check whether the same defect existed in the other five. It almost always did. The fix would be applied in the country where it was reported and would silently persist everywhere else until somebody happened to notice. The company had been accumulating a class of long-lived bugs that were not bugs in a single codebase — they were bugs in the copy-and-adapt pattern that had spawned the codebases in the first place.
What had been tried. A previous initiative had attempted to extract shared utilities into a common library. The library had been adopted by three of the six country teams and ignored by the other three, producing the worst of both worlds: a "shared" library that was not shared enough to be a single source of truth, and a set of country forks that were not independent enough to move freely. The team's own diagnosis was that they needed a rewrite. My diagnosis was different — rewriting six codebases into one would reproduce the silo problem as a monolith problem. This was a boundary problem, not a codebase problem.
Structural Diagnosis
Three architectural problems explained why the silo model had become structurally unworkable at six countries.
Universal logic was being implemented as local logic. A code-level audit of the six codebases revealed that roughly seventy percent of the payroll logic was functionally identical across countries. Employee records, time capture, gross-pay calculation, payment execution, audit logging, and the core of the payroll run lifecycle were doing the same thing in six different files with six different bug histories. Only about thirty percent of each codebase was genuinely country-specific: the tax calculations, the statutory deductions, and the regulatory reporting formats. The silo pattern had failed to distinguish between work that belonged to every country and work that belonged to one country, and had treated all of it as local. Conventional fixes — asking teams to share code voluntarily — fail because the boundary was never drawn. Voluntary sharing across undrawn boundaries is a coordination cost, not a structural solution.
Compliance and core were entangled at the file level. Inside each country codebase, the regulatory logic was interwoven with the core payroll flow rather than isolated behind an interface. A change to the core — adding a new pay component, adjusting the timing of a deduction — could not be made without touching every file that contained regulatory logic, because there was no structural wall between the two concerns. This is the entanglement that makes "just extract the common parts" look easy on a whiteboard and impossible in a pull request. The files had to be untangled before they could be split. Extraction without untangling produces a shared core that still requires every country team to approve every change, which reproduces the original coordination cost with additional ceremony.
Audit trails were per-country, not per-company. Each country produced its own compliance artifacts in its own format for its own regulator. There was no cross-country view of what had been run, for whom, under which rules, with which approvals. When leadership asked a portfolio question — "are we compliant everywhere?" — the answer required assembling six separate reports in six separate formats and taking it on trust that the underlying runs had used comparable logic. The entanglement meant they almost certainly had not. Conventional fixes — centralized dashboards that pull from six data sources — only reconcile the presentation layer. They do not fix the underlying divergence, and they give leadership a false sense of coherence that makes the risk worse.
The Intervention
The redesign took the shape of a shared core plus country-specific compliance plugins, rolled out country by country rather than in a single cutover. The sequencing mattered as much as the architecture.
Phase 1: Drawing the Boundary
What was built: A written specification for what belonged in the shared core and what belonged in a compliance plugin. The spec was terse by design: core owned the data model, the lifecycle, the payment execution, and the audit log. Plugins owned tax calculation, statutory deductions, regulatory reporting, and any country-specific validation rules. Anything in the middle got adjudicated explicitly, in writing, with a decision recorded for future reference.
Why this came first: Nothing else works when the boundary is fuzzy. Every prior sharing attempt had foundered on the question of where core ended and country began. Without a written specification — reviewed and accepted by the country teams before any code moved — the extraction would have produced a shared core that each country team continued to interpret locally, which is the silo problem in a different shape.
The mechanism: The boundary specification made the seventy-thirty split explicit and defensible. Every code movement in later phases could be resolved against the spec rather than negotiated team by team. This converted an ongoing political cost into a one-time design cost, which is the only way cross-team architecture work ever actually finishes.
First-phase outcome: The country teams agreed on where the line was before any file was moved. The agreement was not enthusiastic, but it was explicit, and explicit agreement is the substrate that lets structural work proceed.
Phase 2: The Shared Core
What was built: A single codebase containing the universal seventy percent — employee management, time tracking, payment processing, audit logging, and the payroll run lifecycle. One codebase, one deployment pipeline, one on-call rotation, one bug-fix queue. The existing country codebases remained in production while the shared core was built alongside them; nothing was cut over yet.
Why this depended on Phase 1: Without the written boundary, the shared core would have either absorbed country-specific logic that belonged in plugins (rebuilding the entanglement) or excluded universal logic that belonged in the core (forcing country teams to reimplement it). The spec was the only thing keeping the extraction honest.
The mechanism: The core exposed a plugin interface with a deliberately narrow contract. A plugin received gross pay and a fully populated employee context; it returned net pay and a set of compliance artifacts in a canonical format. Everything else — the shape of the payroll run, the sequencing, the audit logging, the payment execution — stayed inside the core and was invisible to the plugin. This interface was the structural wall between the two concerns that had been missing from the silo architecture.
First-phase outcome: A working shared core with a single reference plugin simulating one country's rules. The reference plugin was not a real country yet. Its job was to prove that the interface could carry the full weight of country-specific regulation before any real country depended on it.
Phase 3: Country-by-Country Migration
What was built: Six compliance plugins, one per country, migrated sequentially. Each plugin encapsulated its country's tax calculations, statutory deductions, and regulatory reporting formats. Each migration followed the same sequence: build the plugin against the shared core, run both old and new systems in parallel against a period of historical payroll data, reconcile every line-item difference, then cut over when reconciliation was clean.
Why this sequencing mattered: Cutting over all six countries at once would have been reckless. Payroll errors are not abstract — they are people's paychecks and a company's regulatory standing. Parallel running the old silo codebase alongside the new plugin during the transition made the cost of discovery visible and contained. A reconciliation difference in country three would surface before country four's migration started, which is how you catch a systemic bug in the interface rather than discovering it when six countries are already dependent on it.
The mechanism: Validation gates in front of every payroll run. Before a run could execute, it passed through a country-specific gate that checked the plugin's compliance outputs against a set of regulatory invariants. Anomalies — values outside expected bands, missing statutory fields, deductions inconsistent with the employee context — were flagged for human approval before the run proceeded. The gate was not a report. It was a hard block. Procedures can be bypassed. Gates that refuse to let the next step proceed cannot.
Phase 4: Unified Audit
What was built: A single audit log, owned by the core, capturing every payroll run across every country in a canonical format. The plugins wrote their compliance artifacts into this shared log rather than maintaining their own. Leadership could now ask a portfolio question — "what did we run this month, under which rules, with which approvals?" — and get a single answer.
Why this came last: The audit layer only becomes coherent when the runs being audited are coherent. Building a unified audit log over six silo codebases would have produced a unified presentation of incoherent data. Once the plugin architecture guaranteed that every country was running against the same core with the same lifecycle, the audit log could finally be a single source of truth rather than a reconciliation exercise.
Constraint and tradeoff: The plugin architecture requires somebody to own the boundary. When a new regulatory obligation arrives — say, a new statutory deduction in one country — the team has to decide whether it is genuinely country-specific (plugin) or whether it hints at a capability the core should grow to support (core). This decision happens at most a few times a year, but when it happens it is consequential. A wrong call in the direction of "put it in the core" pollutes the core with country logic. A wrong call in the direction of "put it in the plugin" leaves other countries unable to reuse the capability when they face the same obligation later. The framework traded six engineering exercises per regulatory change for one architecture decision per regulatory change, but the one architecture decision is not free and cannot be automated.
Results
New-country onboarding. Dropped from months of development to weeks of plugin configuration. The mechanism is structural: the core is already built, the interface is already defined, the validation gate pattern is already in place. Adding a seventh country means writing a new plugin that implements the interface and defines its country-specific rules. It does not mean forking a codebase, spinning up a team, or building a new deployment pipeline. The ceiling that had capped the business at six countries was removed by the shape of the architecture, not by adding engineering capacity.
Code reuse across regions. Seventy percent of the payroll logic is now implemented exactly once, in the shared core, and every country benefits from every fix. The thirty percent that remains country-specific lives in its plugin where it cannot entangle with anything else. This is the number the silo architecture had been quietly producing for years without being able to capture — the company had been doing the same work six times because it had no structural place to do it once.
Unified compliance audit trail. Leadership can now answer portfolio compliance questions from a single source. The shift is not just operational — it is epistemic. Previous audits relied on taking it on trust that six codebases were doing comparable things. The plugin architecture makes them actually comparable, and the unified log makes the comparability visible.
Regulatory cadence. Regulatory updates can now be deployed to a single plugin without touching the core or the other five countries. A tax threshold change in country two is a single plugin release. In the old architecture it would have been a six-country re-verification exercise, because every team would have had to confirm that nothing in their local version of the shared-by-convention code had drifted in a way that the change now broke.
Counterfactual. Without the redesign, the company could not have survived a seventh country. The engineering cost of each additional silo was growing faster than the business value of each additional market, and the accumulated entanglement was making regulatory updates slower rather than faster. The most likely outcome of continuing on the silo trajectory was not a visible failure — it was a silent slowdown in which the company stopped expanding, attributed the stagnation to market conditions, and never diagnosed that the architecture had put a ceiling on its own growth.
The Diagnostic Pattern
The workforce management company did not have a payroll problem. It did not have a compliance problem. It had a boundary problem — the boundary between what was universal and what was local had never been drawn, and the architecture had defaulted to treating all of it as local.
The transferable principle is structural. Any multi-jurisdiction system — payroll, tax, regulatory reporting, education, healthcare, anything that serves multiple governed contexts — eventually faces the same decision: standardize what is universal and isolate what is local, or pay the copy-and-adapt cost on every change forever. The shape of the plugin architecture matters less than the discipline of drawing the boundary before writing the code on either side of it. The mistake that produces silos is not a coding mistake. It is the decision to start building before the boundary is named.
The same pattern has since recurred in adjacent engagements — multi-campus education governance, multi-region HR platforms, multi-entity financial operations. Different domains, same structural principle. The question to ask is never "should we share more code?" It is "where is the line between what must be the same everywhere and what must be free to differ locally, and have we drawn it in writing before we started building?" Systems that draw the line early scale across jurisdictions. Systems that do not, do not.
Related Service
This engagement falls under my PMO & Governance practice.
View advisory engagement models