Bottom-Up Transformation

A system asks someone for a number they do not own, routes an approval to a person who does not decide, or produces a report that does not answer the question their manager asks on Monday. They comply once, get a worse outcome more slowly, and stop. That is not resistance. That is a competent person reading a specification and finding it wrong.

The adoption figure arrives a year later, after the budget has closed and the implementation partner has gone. By then the only variable left to blame is the user.

What actually happened

Polymath’s founder owned the group’s Workday platform from 2017, and the recruiting implementation and end-to-end redesign of talent acquisition were his to run, requisition through onboarding, across more than twenty offices in a formerly private CPG business of roughly $2–3 billion in revenue, by then listed on the TSX. Internal capacity was thin. The team could not buy its way past a design mistake, so each had to be found before it was built.

The requisition is where the team found the first. On paper the process began when a hiring manager raised one. In practice the hiring decision had been taken three weeks earlier, between the manager, their finance partner and a recruiter. By the time a requisition existed, its job was to record something that had already happened.

Look at what the form asked that manager for. A job level and a compensation range, owned by Total Rewards and invisible to him. A start date, turning on a notice period nobody had negotiated. An approval routed up the reporting line, when the constraint was a headcount budget in finance. So managers rang the recruiter, were given the numbers and typed them in. Every field was populated and none of it was information. The approval came back at once, because the approver had agreed weeks earlier.

The team rebuilt the form around who held each input. Total Rewards supplied the range into the requisition instead of asking for it. The approval moved to whoever controlled the budget line. The conversation that had always started the process became its first documented step, so the system recorded the decision when it was taken.

The same test produced the opposite result on a different problem. The team also built a global reward and recognition model with no incremental budget — roughly $5 million of identified organizational value, created by redesigning how recognition was proposed, approved and funded rather than by adding money to it — and a custom application to carry it. No campaign, no mandate. The design put the action where recognition already happened, which made using it the shorter path. Talent acquisition had to be argued into adoption. Recognition needed no argument at all. The difference was not the change effort behind them; it was whether the design asked people for things they actually held.

Polymath applies that test for a client before the build rather than a year after it, when the only variable still in play is the user.

Why it happens

An enterprise system is a written claim about who knows what and who decides what. Every mandatory field asserts that the person filling it holds that information. Every approval step asserts that the person it routes to decides. Every report asserts a question worth answering. Those claims come from the documented process and whoever sits in the design room.

The people who will use it hold a different map, and theirs is the accurate one. They know the range is set elsewhere, the decision was taken in a corridor, the real approver is whoever controls the budget, and the question their manager asks on Monday is not the one the report answers.

Put a person in front of a field they cannot honestly complete and you have not created a training need. You have created a choice between two costs. Comply, and produce a slower, worse outcome using a number read out over the phone. Or route around it, and get the right outcome where the system cannot see. Against the accountability they carry, they choose correctly.

A workaround is not a failure to follow the process. It is the process, found by the only people with an incentive to make the work happen.

Two properties of the workaround decide what follows. It is better, so it survives pressure. And it is invisible, so the design defect never returns as a defect. It returns as an adoption number, a year later, once the money is gone. By then the number can only be read as attitude, because the user is the only variable still in play. So the remedies address the user: communication, training, a mandate, a compliance report. Some of it works, in the narrow sense that fields get populated. None of it moves the decision back into the system, because the reason it left is untouched.

The record beneath the metric gets worse, and that is the loss that compounds. Time to hire, workforce cost by function, capacity against plan — each assumes the system captured the decision. Where it did not, those measures describe administration and get used for allocation anyway.

The strongest objection

The strongest case against this: we ran a serious change programme — sponsorship, super-users, training, communications — and adoption still lagged, so the design is not the problem.

That is evidence for the claim, not against it. A change programme is the most expensive available test of whether a design matches how the work is done. If adoption survives one and still falls short, you have bought a rigorous answer and misread it. What we concede is real: timing a go-live away from a peak, sequencing offices sensibly and training people properly all remove friction from a design that fits. None of it hands a manager a compensation range he cannot see.

The second objection is better: if every workaround becomes a requirement, you have rebuilt the old mess in a new system and standardized nothing.

Correct, if you take workarounds at face value. So do not. One question separates them: what would this person need in order to comply? If the answer is information they cannot access, authority they do not hold, or a decision taken before your process begins, the design is wrong and holding the line will not fix it. If the answer is nothing — they could comply and would rather not — that is a preference, and you hold the line.

The method

We run six steps. The first two happen before anyone opens a configuration workbook.

1. We inventory the workarounds before we design anything. We sit with the people who do the work and ask what they actually do, in what order, in which tool, including the spreadsheet, the group chat and the phone call. Asked with no consequence attached, it takes us a week per process. The trade-off we accept: we hear things that embarrass a process owner, so we do not have them in the room. Skip it and you design from the documented path, written for auditors and followed by nobody.
2. For every field, we name who holds the information, not who types it. Where those are different people, we have the system supply the field or we take the field off the form. The trade-off we accept: design takes longer, and some inputs have no owner anywhere, which is slower to fix than a form. Skip it and you ship fields that can only be completed by guessing, and guesses reconcile perfectly.
3. We route approvals to the constraint, not to the hierarchy. We find where the real refusal lives — the budget line, the pay structure, the capacity plan — and we route there. If the reporting line needs visibility, we give it a notification, not a gate. The trade-off we accept: we are taking approval steps away from people who hold them today, which is a status conversation before it is a design one. Skip it and a step that is always granted will not survive testing.
4. We build the report against the question the user’s manager actually asks. Not the process owner’s question. We sit in one of those Monday conversations and write the question down in the words used. If the system cannot answer it, the private spreadsheet is permanent. The trade-off we accept: we build outputs that look parochial beside an enterprise dashboard. Skip it and you fund a reporting layer its users bypass.
5. We release to one country first and log every workaround as a defect. A pilot proves nothing unless we track workarounds the way build defects are tracked, each with an owner and a date. The trade-off we accept: the rollout slows and our list makes uncomfortable reading for the sponsor. Skip it and the first country’s workarounds are exported to twenty more, where they harden and get defended.
6. We keep the channel open after go-live and we answer on a fixed clock. We give any user a route to say this asks them for something they do not have, owned by the process owner rather than the service desk. The trade-off we accept: it generates volume, most of it preference rather than defect. Skip it and adoption is again your only feedback, once a year and too late.

None of this is change management, and none of it replaces change management. What we do is move the same information forward by a year, to where acting on it costs a design decision rather than a re-implementation. Don’t automate a broken process is usually heard as a remark about quality. We read it as a question about who holds what. A single hire draws on four functions — the pay structure in Total Rewards, the budget in finance, the notice period held by a candidate, the decision held by a manager — and a Hire-to-Retire process breaks exactly where it asks one of them for another’s information. Configure over that and the only thing we would have automated is the asking.

Evidence and measures

From one talent acquisition redesign: what the form asked, and what the user held.

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

— Count the spreadsheets and chat threads running alongside the process. Ask under an amnesty; any other number is wrong.

— The gap between the date a decision was taken — the calendar invitation is the evidence — and the date the system recorded it.

— Fields where a single value carries most of the entries. That field asks for something the user cannot supply.

— Approvals granted so quickly nothing could have been read. Count them by approver; the pattern is the finding.

— Design decisions in your last release tracing to a named user’s constraint rather than a process document.

If those five move, the design changed. If the only movement is field completion rates, you have taught people to fill in a form.

How Polymath solves this

We start with your process as performed rather than as documented. In the first weeks we sit with your recruiters, hiring managers, and payroll and HR administrators, and we record what is actually done: in what order, in which tool, including the spreadsheet and the phone call. We then put every workaround to one question — could this person have complied? Where the information, the authority or the decision sits elsewhere, we log it as a Process Redesign item and settle it before anything is configured.

We build the redesign rather than recommend it. We configure the forms, the routing, the integrations and the reports your people currently keep privately, in the platform you already run, alongside the administrators who will maintain them, and we test it against a live hire rather than a script. Where an input has no owner anywhere, we resolve that before go-live instead of routing it to somebody willing to guess. Then we hand it back to the recruiters, managers and administrators who run it every day.

What compounds is a true record. Once we have sourced each field from whoever holds it and routed each approval to whoever can refuse, your decisions are captured when they are taken, and time to hire, offer acceptance and workforce cost by function describe your business rather than your paperwork. The same input map is what we build onboarding, absence and performance against next. The map does not get rebuilt: every process after this one starts from a list of who holds what, rather than from a document describing who ought to.

What it costs to do nothing

The visible cost is a licence carrying a fraction of the work it was scoped to carry. That is the smallest part of it, and the easiest to defend in a budget review. The second cost is in the record. Every downstream number assumes the system captured the decision; where it did not, capital allocation runs on a description of administration.

The third becomes external. An approval that is always granted, immediately, after the fact, is not an approval. It is a step. In a public company that step gets tested, by people with no interest in why it made operational sense.

The re-implementation is the real bill. Five years on, the platform is declared the problem, a replacement is scoped from the same documented process by the same people, and you buy the same defect again with interest. None of that turns on a platform decision; it turns on what the work looks like when somebody actually does it, and that is where we start.