Shipping the Org Design With the System

A release changes what the work consists of: which steps exist and who performs them. The documents telling a person what their job is do not move with it. Job descriptions belong to job architecture, objectives to the performance cycle, span and boundary to whoever owns the establishment, the catalogue to a service owner. Each has its own custodian, calendar and change process, and none sits in the programme plan.

So on the first working day after go-live a competent person holds two specifications: one in the system, one in the document they will be reviewed against at year end. Where they disagree the reviewed one wins, and it should. That is not a change management failure but an accurate reading of what the organization asked for.

What actually happened

Polymath’s founder owned the Workday platform and global HR shared services at a consumer packaged goods company — public on the TSX, revenue of roughly $2–3 billion, payroll to run in approximately 21 countries, integrations reaching more than 20 offices. He also held the HR-related financial controls for about eight years, building, testing and remediating them with auditors.

The platform went live globally and absorbed work the country teams had been doing office by office: joiner and leaver administration, the local record of who held which position, the chasing of a manager for a signature. The configuration was correct and did what it was specified to do.

Nothing else about a country HR role moved with it; nothing else was in the release. Job descriptions still made local record maintenance the substance of the work; boundaries drawn when each office administered its own people still stopped a case at a border the platform no longer recognized; and what a manager asked for each month was still the local file: current, complete, reconciled.

The objectives were the binding constraint, and nobody counted them as part of the process. Take one country HR administrator. Agreed in the cycle that closed before the release, their objectives committed them by name to the accuracy of the local employee records, the turnaround on local requests, and the reconciliation between what the country held and what the centre held. The platform now maintained those records, answered those requests, and was itself the reconciliation. Every line that person would be reviewed against described something the release had taken over, so they went on doing it: the file kept beside the platform, the two reconciled by hand, managers chased for entries they had been asked to make. Nobody was working around anything; that administrator was performing what a manager had agreed in writing.

Across the country teams the programme saw duplicate maintenance and light use of the configuration, and gave it the name it had a budget line for: adoption. More training was bought, and none of it altered a document anybody would be measured against. The controls made the gap legible first. Several control descriptions still named a local reconciliation the global configuration had absorbed, and eight years alongside auditors teaches that the written account of who does what is what gets tested.

What he proposed was not more training but a rewrite of the country HR role: the boundary moved to the handoff that survived, local intake channels republished as the work that remained, and new objectives dated to the go-live, so that exception work and the judgment the configuration could not hold became the measured work.

Polymath scopes that rewrite into the release itself, so the jobs and the configuration carry the same effective date.

Why it happens

A programme’s scope is drawn around the system. The plan carries columns for configuration, data, integration, testing and training, and none for the establishment, which nobody on the programme can produce. So a release, which changes what the steps are rather than what they cost, is authored by people with no authority over the documents telling a person what their job is.

Each artifact defining a job is owned elsewhere, and every owner has a legitimate reason not to move on a release date. Job descriptions carry grading consequences, so they change deliberately and rarely. Objectives sit in a cycle that closed months before go-live, and reopening them mid-year reads as moving the goalposts. The catalogue belongs to an owner whose customers would read a shorter list as less service. Every custodian is being careful, and the sum of that care outlasts the process it was built for.

It also needs separating from a different diagnosis of low adoption, which on a dashboard looks identical. Sometimes the design genuinely is wrong — the system asks for something the user does not hold — and the route built around it is the better specification. That is answered by changing the design. What is described here survives a design that is right: the fields can be completed, the routing is sound, the new path is shorter, and people walk the old one anyway, because the old one has a target against it. One person cannot comply; the other would be worse off complying, and no remedy serves both.

Which is why the standard responses underperform. More training teaches a sequence to people who already understand it. Sponsorship and communications assert that the change matters, beside a document asserting what will actually be reviewed when the cycle closes. An adoption dashboard measures the symptom accurately enough to fund another round of the first two. Hypercare clears defects, and no defect log has ever contained an objective. And the manager who would rewrite the objectives is measured on the outputs they produce, so they read the same incentive, one level up.

The strongest objection

The strongest case against this: objectives exist to hold people accountable for business outcomes, and rewriting them every time technology ships is how an organization ends up measuring project compliance instead of results.

Concede it properly, because it is right about the failure mode. An objective reading “adopt the new system” is worse than the one it replaced: it commits a person to an activity rather than a result, and it expires when the next release lands. But this is not every release. It is the small number that change what the work consists of rather than how a step is performed, and the test applies in an afternoon: does any line here commit this person to an activity the system now performs? Most of the time the rewrite is a deletion, and what remains is closer to an outcome, because the line removed was transactional.

The second objection is harder, and it comes from the better-run functions. Our objectives are already written at outcome level — service quality, cost per transaction, satisfaction, first-contact resolution. They name no steps, so they cannot be describing the old process.

They can, and usually are, because an outcome objective takes its meaning from the measure underneath it, and that measure was built on the process just retired. Cost per transaction assumes the transaction is the unit of work; automate the transactions away and the denominator falls faster than the cost, so the ratio deteriorates in a year when the service improved. Resolution time assumes the queue is where work arrives; first-contact resolution assumes there is a contact. An outcome objective with a pre-automation measure behind it is a step objective in better language, and it is harder to spot because the words are unobjectionable. Read the measure, not the sentence.

The method

Six steps. One and two establish what the job has become, three and four move the structure around it, five and six put dates and evidence against both. Programmes defer the last two, and that is what restores the old process.

1. We read the objectives before we read the configuration. For every role the release touches, we mark each line people are measured on as still true, now performed by the system, or no longer possible. The trade-off we accept: we need the real documents rather than a template, and some managers find that intrusive, so we ask openly and say why. Skip it and we design for jobs we have only heard described in a workshop.
2. We write the post-release job on one page before touching a formal document: what this person does now, what they decide, what they hand on, what they are no longer responsible for. The trade-off we accept: our page carries no grading status, so people whose level depends on the answer will argue with it, and we would rather hold that argument now than in an evaluation panel. Skip it and the rewrite happens document by document, and the versions disagree.
3. We re-cut the team boundary and the span against the sequence the system now runs. Where a boundary divides work that no longer accumulates, we move it to the handoff that remains; where a span supervised volume, we say what supervision is now for. The trade-off we accept: this is a conversation about people rather than process, and it will not always finish on the release date. Skip it and the handoffs the system removed get rebuilt as boundaries between teams.
4. We reissue the service catalogue as the list of what the team does now. It is how the rest of the business decides who to ask, so while it advertises pre-automation services those requests keep arriving. The trade-off we accept: a shorter catalogue reads as a withdrawal of service, so we take the explanation to the finance and operations leads who use it. Skip it and demand keeps arriving in the shape the release was meant to stop.
5. We put the new objectives in effect on the release date rather than at the next cycle. We draft them with the manager and the individual together, we date them to go-live, and we settle how the part-year under the old targets is treated, so nobody is penalized for a measure that stopped applying. The trade-off we accept: reopening objectives out of cycle is unpopular, and somebody senior in HR must authorize it. Skip it and your people spend the rest of the year paid to perform the process you just retired.
6. We rewrite the control descriptions and the escalation path inside the same release. A control names a step, a role and an evidence artifact; once the step has gone, the description must say what is performed now and by whom, and we give the escalation path the same treatment. The trade-off we accept: this pulls internal audit into a delivery timeline they had not planned to join. Skip it and the first accurate account of your new process is written by a tester, a year on, as a finding.

The outcome sits in step five. The others make the change intelligible; the objectives make performing it rational for an individual. A programme that redraws the boundary, reissues the catalogue and rewrites the descriptions while leaving the targets alone has told people what the new job is while paying them for the old one — a harder place to stand than changing nothing.

Evidence and measures

What a person works from on the Monday after go-live:

Five measures worth tracking over ninety days. None of them requires a new system:

— Lines in a person’s objectives committing them to an activity the system now performs. Sample a few roles and read them; the count is the size of the problem.

— Requests still arriving through the intake channels the release was meant to close, counted channel by channel, not as a total. — Effective date on the most recently reissued job description in the affected teams, against the go-live date.

— Share of the team’s week spent on exceptions, design and query resolution rather than processing. It should rise; it is the only one here describing the new work.

— Escalations reaching the process owner rather than the local team lead, as a share of all escalations.

Read the third first. A date after go-live means the organization caught up; a date before it means the retired process still has a signed document behind it.

How Polymath solves this

We open on the objectives and the job descriptions rather than the configuration, because those decide what people do with what you have built. Early on we take a single process the release has already changed, mark every line in the affected roles’ objectives against what the platform now performs, and produce the post-release job on a page for each — days of work, and usually enough to settle whether adoption is a design question or a structural one. From there we redraw the boundary, the span and the catalogue against the process as it runs. We run this as Change Management, because the configuration was already finished.

We do the work inside the performance and planning cycles you already operate, with the people whose jobs are changing. The country HR leads and the team managers draft the new objectives, because a measure only holds when the people answerable for it wrote it, and a target somebody else wrote does not survive its first review conversation. The process owner settles the escalation path, the HR business partner who owns the performance cycle authorizes the out-of-cycle change, and your control owners rewrite the descriptions with us while the release is open. We run one cycle alongside the team and the next is theirs.

What accumulates is the habit of shipping the two together. Once a function has seen a release land with dated objectives, a redrawn boundary and a reissued catalogue on the same day as the configuration, the next one gets scoped that way without anybody arguing for it. Your organization stops treating its own structure as the constant every system must be configured around, which is the condition under which the release after this one can be worth what it costs.

What it costs to do nothing

Start with the benefit already booked. Capacity released by the platform and never redirected does not sit idle; it goes back into the work the platform was bought to take over, so the case reconciles while the teams stay as busy as before.

The second cost is written by your auditors. A control description naming a step that no longer happens either passes on evidence reconstructed for the test or fails on the absence of a record nobody keys. In a listed company both are found by people with no interest in the operational reason, on a calendar belonging to them.

The third decides what your next release can be worth. Exception handling, query resolution and the design of the one after it are where an HR function earns its keep, and nobody is measured on any of them, so they get done in the margins by people whose week is still shaped around local administration. Leave that in place and the estate accumulates new systems against an unchanged organization, each release returning less than the last.

None of this turns on a platform decision or a new programme. It needs one release’s worth of objectives read beside the process the system now runs, and a date against the rewrite. That reading can be done on the go-live you have already shipped, and it is the shortest route back to the benefit you approved.