PerspectivesPaper 10
From Headcount to Strategy
You can say how many people you have. Can you say which capability you cannot buy?
Any enterprise can produce a headcount to the individual and a labour cost to two decimals. Ask instead which commitments in the five-year plan have nobody in the building capable of delivering them, and there is no report, no owner and no vocabulary for the question.
That is not because the question is unimportant. It is the harder of the two constraints. It is because the answer has never been stored anywhere, and an enterprise can only discuss what it can retrieve.
What actually happened
Polymath’s founder spent his last two years in that business as senior vice president and Chief of Staff to the chief executive, with global growth analytics and insights on the same desk. It was a CPG group of roughly $2–3 billion in revenue that had gone public on the TSX. Three things sat on that desk and were never discussed in the same meeting: org design and hiring, investment prioritization, and technology strategy and roadmaps. Years earlier he had built the job architecture.
All three fed a five-year revenue, margin and brand roadmap he had influence over. It was written as commitments with dates: prioritize investment across three commercial segments on margin rather than revenue, move a set of platforms onto a common architecture, build capability closer to the consumer.
Beneath it sat an org design and a hiring plan, approved in the same cycle and expressed in roles, levels, functions and cost. Both were signed by the same people in the same fortnight, and neither answered the question that decided whether the first would happen. The org design showed a full establishment against every commitment. It could not show that two of them turned on one individual, or that a third needed a combination the group had never employed and could not put in a job posting.
Having built the job architecture, he knew exactly why. A job record answers what the work is worth, what it is called, where it reports and what it may approve, because payroll, compensation, approval routing and the hierarchy would each break without those answers. Every field serves a process downstream of it. None asks whether the person occupying the job can do something the company could not replace.
The change the team made was narrow, and it went into investment prioritization rather than the workforce plan. For commitments carrying real capital, the workforce answer had to be a name and a build time rather than a headcount and a cost. Where the answer was nobody, the date moved before the roadmap reached the board. The establishment was full against every line of that roadmap. It was a statement about what the workforce cost, and the company had been reading it as a statement about what it could do.
What Polymath hands a client is the roadmap read against the establishment: a name and a build time against each commitment carrying capital, and the word nobody where there is no name.
Why it happens
An enterprise can only debate what it can retrieve, and what it retrieves is decided by what its systems were built to administer. A role is a storable object: an identifier, a level, a cost, a reporting line, an occupant. It exists because payroll must pay someone, approvals must route somewhere and the hierarchy must resolve. It is stored because it has to be.
A capability is none of those things. It is a combination: domain knowledge, the relationships needed to get a decision made here, memory of what failed before, a technical skill, and judgment about which of your own rules can be bent. It sits inside a person and cuts across the boundary of their role. There is no field for it, and the fields claiming to be it — skill tags, competency frameworks, job families — describe the role again in other words.
The first consequence is arithmetic. What cannot be stored cannot be totalled, and what cannot be totalled does not survive the trip to an executive review. The workforce material that reaches a board is counts and costs.
The unit of record becomes the unit of debate. Headcount and cost are both answers about supply, and the strategic question was never about supply.
The second consequence is that the record implies substitution. Two people sharing a job code are identical to every system holding them, so the plan treats them as interchangeable. Across most of the establishment that is harmless. It stops being harmless on the commitments turning on a combination one of them has and the other does not.
The third consequence is the absence of a warning. Scarcity is normally signalled by price or by a queue. A scarce capability inside your own building has neither. The person is paid the rate their job carries, the work keeps being delivered, and no report shows a shortage. The first signal is a resignation, so discovery and loss arrive together.
The fourth consequence is strategic. Because scarcity is invisible, build time never enters strategy timing. A commitment resting on a capability you must grow takes as long as growing it takes, and that duration is knowable in advance, but only if somebody asks when the commitment is made. Nobody asks, because the workforce input to strategy is a cost envelope.
The strongest objection
The strongest case against this: our HR business partners already know who the critical people are, and formalizing it adds bureaucracy rather than knowledge.
The good ones do know, and they hold it honestly. Two things limit it. It is held function by function, and the capabilities that constrain a strategy cross functions: the combination behind the demand-planning work sat between commercial, supply chain and data, and no single partner’s map contained it. It is also held informally, so it surfaces when asked, and nobody asks during capital allocation.
There is a blunt test for whether that knowledge reaches decisions. Name the last capital allocation decision here where workforce input changed the answer — not the headcount funded, the shape of the commitment. A sequence reordered. A market entered a year later. An acquisition chosen over a build because the capability could not be assembled in time. If nothing of that class comes to mind, the workforce input is a cost check.
The second objection is better: judgment cannot be inventoried, and every attempt becomes a competency framework nobody maintains. Largely true, and what we propose is narrower in scope. Do not inventory the workforce. Inventory the strategy: a dozen commitments, two or three capabilities each, held by the people who set it.
The method
We run six steps, in this order, and we hold the order, because it is what keeps the exercise small enough to survive.
- We start from the commitments, not from the organization. We take the dozen commitments your roadmap actually rests on, and for each one we write the two or three capabilities it consumes, in verbs rather than job titles. The trade-off we accept: the list is subjective and people will argue about the wording, which is where the value is. Skip it and you begin an enterprise-wide skills inventory, which nobody maintains past its first year.
- We ask for a name, and we let the answer be nobody. We ask it of each capability: who here can do this now. Not which function owns it. A person. The role record cannot answer this, which is why we put the question to people rather than to a system. The trade-off we accept: naming individuals in a strategy document is uncomfortable, and some names recur. Skip it and the plan keeps assuming a full establishment covers the roadmap.
- We sort each capability into buy, build, or neither. Buy means the market has it and you can attract it inside the window. Build means adjacent people and a route, with a duration attached. Neither means it depends on context only your enterprise contains. The trade-off we accept: the neither column will hold a commitment you have already announced externally, and we leave it there rather than reclassifying it. Skip it and every capability is implicitly a buy, which is the assumption inside every headcount plan.
- We put build time into the roadmap, not the HR plan. A commitment resting on an eighteen-month capability cannot start when the roadmap says it starts, and we treat that as a roadmap fact rather than a resourcing detail. The trade-off we accept: it moves dates your executive team may already have said out loud. Skip it and sequence is set by ambition and corrected by failure.
- We decide with you where to stop hiring. Where we find the constraint is capability rather than volume, adding people routes more work through the same scarce judgment and spends the budget that could have bought the one hire that mattered. The trade-off we accept: refusing headcount justified on workload is harder than approving it. Skip it and the workforce grows fastest where growth is easiest to justify, rarely where the constraint sits.
- We revisit the list when the roadmap moves, not when the budget does. A new commitment, an acquisition or an exited market changes what is scarce immediately; the budget cycle learns of it ten months later. The trade-off we accept: we put the artifact on your strategy team’s agenda rather than the function’s. Skip it and it becomes an annual submission, and an annual submission is a document rather than a decision input.
What we hand over is a page per commitment. We do not build a workforce planning system, and this does not need one; we keep it short enough that your chief executive reads all of it before the roadmap is signed. What it really is, though, is an extension of the role record. That record was built to administer people, and inside Hire-to-Retire it answers cost, hierarchy and authority faultlessly. It cannot be asked about scarcity. We extend it to hold that one answer — who, how rare, how long to grow — and it becomes usable above the function maintaining it.
Evidence and measures
One page: what the roadmap promised, and whether anyone can do it.
| STRATEGIC COMMITMENT | CAPABILITY IT CONSUMES | BUY, BUILD OR NEITHER |
|---|---|---|
| Enter an adjacent category | Category economics judgment plus retailer relationships | Buy — available, slow, expensive |
| Automate demand planning | Retailer category logic joined to your own data model | Neither — half of it is only learned here |
| Integrate acquisitions to a timetable | Multi-country statutory judgment under deadline | Build — start before the next deal |
| Move pricing authority to the market | Commercial instinct paired with margin literacy | Build — the pair rarely sits in one role |
| Replatform a core system unaided | Knowing which of your exceptions are real | Neither — it is your own history |
| Stand up a direct consumer channel | Service economics and channel operations | Buy — the market sells this one |
Five measures worth tracking over ninety days. None requires a new system:
— Strategic commitments for which a named individual can be identified as the person who would do the work.
— Capabilities where that name is the same person twice. That is your concentration, and it usually surprises.
— Capabilities classified as neither that still sit under a commitment with a date announced outside the building.
— Honest time-to-replace for the five people whose departure would stop a commitment, asked of their leaders rather than recruiters. — Share of last cycle’s headcount requests justified by workload rather than by a capability you do not have.
If those five move, the workforce conversation has become a strategy conversation. If only headcount moved, it is still an expense discussion.
How Polymath solves this
We start against the roadmap rather than the organization chart. In the first weeks we match the commitments carrying capital, one at a time, to the role data you already hold, and we write down the exceptions: commitments with no name against them, names that appear three times, capabilities your enterprise has never employed. That list is usually the first capability view an executive team has seen of its own strategy. We run it as Foundational Architecture, and what we deliver is an extension to a record you already operate, not a deck.
We build that extension into the role record itself. Scarcity, build route and build time become attributes against the jobs carrying those commitments, and we write them with your strategy lead and the function leaders who would have to grow or hire the capability, because they are the ones who defend the duration afterwards. This is Job Architecture 2.0 pointed at strategy instead of administration, and your people write the definitions. Then we hand the record back to the function that maintains it.
What compounds is the record. Once scarcity, route and build time sit against the jobs, your record can be asked a question above its original pay grade: the same attributes tell the next roadmap what it can promise and when, show an org design proposal where it concentrates risk, give your recruiters a specification rather than a title, and let a build programme be justified against a dated commitment. The next roadmap arrives to a record that can already answer it, which is a different thing from commissioning the answer again.
What it costs to do nothing
The first cost is timing, and it arrives late enough to be expensive. A commitment nobody could deliver does not fail at announcement. It fails eight or ten months in, after the budget has been spent and the market has been told, and the options left are costly: pay a premium to hire, buy a company for its people, or withdraw publicly.
The second is concentration you never priced. Every enterprise depends on a few individuals whose departure would stop something that matters. What is avoidable is not knowing which ones, so the retention conversation, the succession decision and the documentation all happen after the resignation rather than before it.
The third is capital pointed at the wrong constraint. Twelve more people in a function that needed one different person is a permanent cost increase presented as investment, approved easily because volume is the language the workforce plan is written in.
Headcount tells you what your workforce costs. It does not tell you what it can do, and only the second answer decides whether the strategy is deliverable. It is the answer we go after first, against the roadmap rather than the chart.
Start here
Start with one workflow.
Choose one process that crosses three or more functions. We map it end to end with you, and mark every place the same problem gets solved twice.