Everyone is talking about job redesign. Nobody is talking about what happens next.

Several competitors have been touting their “job redesign” capabilities. We are building ours too, and I suspect most of the early solutions will follow a similar pattern and offer similar capabilities, if not immediately, certainly within a few quarters of each launch. There are only so many ways to reconstruct jobs from their constituent parts. Of course, that’s not really the hard part – the hard part is what comes after the redesign.

I’ve mentioned in previous posts how this moment feels very much like Talent Management v2. And this is another example of why.

I spent a good part of my early career inside the formation of the talent management category. In those years, every gap in the stack got answered the same way: with a new product or capability. Recruiting had a problem, so the market built an ATS, then assessments, then sourcing. Learning had a problem, so it built an LMS and then learning content management systems, and eventual LXP solutions. Performance had a problem, so it built a performance system and then succession and leadership assessment. Each one solved the problem it could see from where it stood. None of them could see each other. We then spent the next decade and a half building integrations to undo or reconnect the fragmentation we had just paid for.

That reflex is now pointed at workforce intelligence writ large and specifically at the redesign of work.

Redesign is becoming a feature because basic role decomposition is easy.

There is a reason this is happening now – a key driver of course is the rise of automation and the resulting “job splintering and fragmentation” that is starting to occur as companies begin deploying agents or use AI to complete specific tasks. The other is that a key piece of the analysis has gotten a lot easier a lot faster than most people thought it might.

Taking a job apart used to be hard. It required a taxonomy, a task model, and a small army of analysts. It is now close to free. Any competent model will shred a job description into tasks in seconds and hand you back a tidy list. And everyone and their brother now seems to have an automation exposure score that operates at a task level – which means the ability to discern which tasks will likely remain human, which will move to automation, and which will hybridize is now relatively ubiquitous.

Together, the distillation of roles into tasks and tasks into an automation score provides much of the raw data necessary for job redesign. It is worth noting though that while AI makes decomposition of the “documented” work cheap, it does not necessarily make discovery of “actual” work cheap. Six Sigma processes, organizational network analysis, journey mapping all still matter – as does an outside-in view of how skills and tasks are evolving in the market and at your competitors.

That said, there is enough meat on the bone that some vendors are moving forward with just the task and automation substrate – which is cheap and fast.

And in HR, when a capability gets cheap, it becomes a feature. And when it becomes a feature, everyone eventually ships it.

But let’s not kid ourselves: it’s the cheap and easy half of redesign that is getting productized. No one is touching the “not cheap and not easy” second half of job redesign – the “what next?” Well, except maybe us of course… ; )

Diagnostics read. Redesign writes. Or at least it should.

A lot of what’s been built so far in the universe of workforce intelligence is read-only at least in a practical sense. Skills taxonomies and gap analysis, automation exposure scoring, benchmarking, org analytics – these all observe work. They report on it. A read-only tool can sit anywhere in your stack and cost you very little if it’s disconnected from other tooling, because nothing downstream depends on its output.

Redesign is different in kind, and I think we might all be underestimating how different.

A redesign changes the definition of a job. And the definition of a job is one of the most heavily depended-upon objects in the enterprise. Your architecture references it. Your plan counts it. Your comp structure prices it. Your requisitions describe and hire it. Your succession plan prepares for it. Your curriculum trains it. Your org model positions it.

Change that object and you have not produced a recommendation. You have produced a set of downstream obligations. All of which need to be addressed with direct and specific actions.

What most of the current tooling produces

I have started calling it read-only job redesign. A redesign that can be described but not executed – at least not at scale and not in a comprehensive way.

It produces a proposed job. A cleaner set of tasks. A confident view of what should be automated or augmented and what should remain human. It may help you reassemble the human bits into new suggested jobs based on task adjacency models. But then what?

There is nothing to receive it or help you organize and align the many next logical steps. No system is wired to take the new definition and change anything. The redesign lives in a document, gets socialized in a steering committee, and then relies on a massive amount of manual human effort to stitch the obligation chain back together.

It would be one thing if we were talking about one job, but the problem isn't redesigning one job. The problem is redesigning 500 jobs continuously as technology keeps changing the work.

Read-only job redesign is not useless. It provides a clear picture of what a new job could look like, and it’s certainly a better-informed opinion than we had before. But it should not be confused with the ability to change how work gets done, and right now it is being sold as if it were.

Here is the part that makes this concrete. I mentioned the notion of an obligation chain – all the downstream activities that follow the redesign. By my count, a redesigned role sets off five separate consequences, across seven or more owners and dozens of systems. Miss any one of them and the redesign likely goes off the rails in one or more meaningful ways.

Consequence one: Your redesign did not change how many people you need. It changed which people.

The obvious first read on redesign is a headcount read. Take work out of a role, take bodies out of the plan. That was the ethos and overall zeitgeist of automation thinking in 2025. And we all know how that went: “Hey everyone – look we fired a bunch of humans because we have AI – yeah automation!” Six months later: “Oh noes, we need all the humans back because they did a ton of stuff we didn’t know about and the AI isn’t ready yet!” Three months later: “Oh my good gawd, now our headcount costs are HIGHER?”

Suffice to say the instinctual CFO response of “more automation, less heads” isn’t playing out the way anyone initially anticipated. In fact, it’s often wrong, and it is wrong in an expensive direction. What we’re all learning in real-time is that task elimination is not the same thing as FTE elimination.

Removing routine work from a role does not shrink demand proportionally. It reshapes it. The seniority mix changes, because what remains is the judgment-heavy portion of the job. Or maybe the reverse happens and previously specialized roles get augmented enough that they need less specialized or less experienced talent. The span of control changes, because the supervisory load of the role changes with it. The ratio between roles changes, because sometimes work doesn’t vanish – it just migrates to an adjacent role that was already handling the exceptions. And a whole new category of work capacity enters your planning and financial models: the automated and agentic capacity now doing the work you removed, but with its own cost, its own failure modes, and no clear line of ownership of its work outputs.

Where you need connective tissue: The job architecture and demand side of your workforce plan, and from there into the finance headcount model and the budget cycle. If the redesigned role does not exist in the plan as demand, cost, and capacity, it cannot be funded. If it cannot be funded, it cannot be hired against. A redesign that never reaches the demand model is a redesign that never happens, no matter how well it was reasoned.

This is where a lot of redesign projects will get quietly killed. Not by disagreement. By never being represented in the numbers that get approved – because neither Total Rewards nor finance teams were brought to the table to evaluate and codify the details necessary to support the operating model.

Consequence two: Your job redesign project is a mobility event or an attrition event in disguise.

The moment you publish a new profile for a role, you have made a statement about everyone currently in it.

Three populations emerge from the disruption:

• Some incumbents get a richer job and need development to hold it.

• Some watch their tasks get absorbed into AI or other teams and need a redeployment path.

• Some now sit closer to a different job family entirely, which is either a mobility opportunity or a resignation, depending on whether anyone noticed in time.

The question that separates a real redesign effort from a document is a supply question: what share of the current talent population is within reach of the new profile, and what is the plan for the share that isn't? Did the redesign create more internal opportunities or fewer? More dependence on the external market or less? And in each case, what do you do about it?

Where you need connective tissue: Your skills inventory and inference layer, internal mobility and talent marketplace, performance criteria, succession, and the job catalog in your HRIS. Redesign is both a supply-side event and a demand-side one, and the supply data most organizations hold is an antique photograph of the workforce as it was, not as it is, or will become. And that assumes it exists at all. Often, skills data is incomplete, precluding any scalable or systemic way to match people to newly created roles. The demand side isn’t much better. Internal skill expectations are often derived from the old role, harvested from the old job description, which the redesign just invalidated.

Absent a clear picture of the skills you have or the skills you will need, internal mobility, reskilling, and talent marketplace solutions can’t deliver at scale, resulting in sub-par talent reskilling and redistribution.

Consequence three: Your job redesign effort defines a bunch of roles the external market cannot supply.

I have yet to hear anyone talking about this risk, but it’s very real. Think “purple squirrel” challenges on steroids.

Redesign will inevitably produce composite roles. You strip the routine work out of two adjacent jobs, keep the judgment, add the oversight of whatever now performs the routine part, and you get a role that is theoretically elegant and yet empirically unhireable. It exists in your architecture. It seems reasonable. And it doesn’t exist in the labor market.

Before a redesigned profile is approved, it needs to be tested against the outside world. Does this combination of skills occur in the market at all? At what volume, in which geographies, at what wage? Is that supply expanding or contracting? Who else is competing for exactly this person, and what are they paying? What does the combination do to time-to-fill, and can talent acquisition actually hire against it?

The same test runs in the other direction. Redesign is one of the few genuine supply-expansion levers available. Recut a role differently and it may become fillable from adjacent pools, from different educational backgrounds, from geographies you had written off, from populations your old profile screened out for no defensible reason. You only find that out if you have robust labor market intelligence underpinning the analysis.

Where you need connective tissue: External labor market intelligence, talent acquisition capacity planning, location and footprint strategy, and sourcing. Redesign built only from internal data is just an opinion with a taxonomy attached. The external market is the only thing that tells you whether the job you designed is a job you can staff.

This is the same challenge talent acquisition teams have faced for years around location planning – real estate teams often make new office, data center, or manufacturing plant decisions in a vacuum, based purely on real estate costs and tax incentives, only to find there is no local talent pool to support that new facility, leaving talent acquisition teams holding the bag. Same issue here – all of the best intentions and logical decisions won’t mean anything if the labor market can’t support it.

Consequence four: A redesigned job is a re-leveled or differently priced job, whether you intended it or not.

Job evaluation runs on scope, judgment, autonomy, accountability, and required capability. Redesign could change every one of those inputs. With even just a few changes, redesign becomes a leveling and re-pricing event. Absent very well thought out strategies, redesign will carry pay consequences more often than not.

Several things break at once. The role may no longer match the benchmark job you had been pricing it against, which means you have lost your market anchor for a job you now intend to hire. Two roles that used to sit at the same level may no longer belong there, which creates internal equity exposure. And another, more insidious problem may emerge: the routine work leaves, the job gets harder, the band stays where it was, and eight months later the retention problem arrives looking like a culture problem. Or maybe the reverse – the job gets materially easier, reducing the need for a cost premium which forces the price point downward, resulting in workforce displacement or redeployment.

Where you need connective tissue: The job architecture and leveling framework, comp bands and market pricing, survey benchmark matching, and pay equity analysis. In Europe this also runs straight into pay transparency obligations, where equal-value comparisons rest on skills, effort, responsibility, and working conditions. Redesign moves all four. A redesign wave without a continuously maintained, gender-neutral category foundation underneath generates substantial legal exposure.

The test is simple: after redesign, can you still level the role, price the role, and explain the band to the person in it?

The alternative? Divorce your work architecture from your job architecture (or at least create some kind of firewall), define the former granularly, and the latter broadly – enabling planning accuracy while absorbing some of the shock and legal / regulatory risk associated with re-leveling and job redefinition. Probably goes without saying but this needs to be very carefully designed with the help of labor law experts.

Consequence five: The tasks your job redesign automates away could be the foundations of apprenticeship.

This last consequence is the slowest to appear and potentially the hardest to reverse.

A new task mix means new competency requirements, which means the curriculum attached to that role is now training people for a job that no longer exists. Onboarding is no less challenging. Without proper planning, you run the risk of people being hired into the redesigned role next quarter yet being inducted into the previous version of it.

But the deeper issue is developmental. The “low-level” routine tasks most exposed to early automation are frequently how new graduates and early-career professionals develop expertise and confidence in their skills. In some cases, those early “at bats” help junior talent develop the judgment and discernment that the senior version of the role requires. Reviewing and adjudicating simple cases is how someone earns the pattern recognition to handle the hard ones. Over-automate the entry rungs and you optimize this year’s cost structure at the expense of the lived experiences that will produce the next decade’s mid-level and senior population.

That is not an argument against automating them. It is an argument that the redesign is incomplete until you have answered where judgment and experience get built instead.

Where you need connective tissue: Learning paths and the LMS, capability academies, career frameworks and progression criteria, certification, succession pipelines, and manager enablement. Key questions to ask: How are you going to continue to create mid-level and senior expertise if routine tasks usually performed by new grads and early-career team members get automated? What is the plan to update the onboarding plans and the role-specific learning pathways at scale to support a continuous stream of redesigned roles, and who owns the update?

Redesign is a mini-version of the same disconnectedness in Work Intelligence efforts.

Five domains, seven or more owners, dozens of systems. No redesign “module” owns any of them.

Sound familiar? This is almost the exact argument I made a couple of months back about Work Intelligence. I argued then that we’re treating Skills Intelligence, Work Intelligence, Talent Intelligence, SWP, and Org Design like they are separate solutions when they are, in fact, different facets of what should be one unified platform relying on a shared data architecture and normalized data layer.

The difference here is that the “sprawl” of technologies and owners is even wider given how ubiquitously “jobs” are used across all HCM systems. That said, it certainly helps to start the redesign from a core Workforce Intelligence Platform like ours to at least align the major storylines – market-driven recommendations married to internal definitions of the role, skill and task evolution frameworks to lean on, demand driver capabilities supported by agents, scenario driven SWP against the redefined role, financial modeling, skill gap analysis, skill adjacency models, upskilling and reskilling support, org design support, and labor market intelligence around “hiring difficulty,” competitors, and cost.

Historically, redesign efforts have lived somewhere between a workshop and a spreadsheet. New tooling is going to improve this tremendously. But I think we need to be very clear about this work. The hard part was never the decomposition or the reimagining of the role. It was everything that needs to happen once you finalize the design.

Eight questions that separate a true redesign from a “read only” recommendation.

1. Does the redesigned role land in your demand model as cost and capacity, or only in a document?

2. When a role changes shape, what happens to the org structure around it – spans, layers, reporting lines, and the adjacent roles that just inherited the work?

3. What share of your current incumbents is within reach of the new profile, and how do you know?

4. Can you actually move and develop that “within reach” population – mobility paths, reskilling, open roles – via personalized learning plans linked to skill gaps?

5. Does this profile exist in the external market? Where, how many, at what price, expanding or contracting? And what competitors are hiring for the same roles?

6. Can you still level it, price it, and defend the band to the person sitting in it?

7. Do you have a clear picture of where you might be “hollowing out” early experiences at the expense of future capability and expertise creation?

8. How will you know if the job redesign is a success, and the extent to which reality matched initial expectations?

Everest Group named this shift from diagnosis to redesign when they recognized us as a Luminary in their “Innovation Watch: Work Intelligence and Workforce Redesign 2026.” I agree with how they framed this shift, and I would rather be held to the harder half of it – all the downstream impacts after you redesign the role. We believe the only way to tackle this at scale is via an integrated Workforce Intelligence Platform. Absent a tech like ours, you are basically on your own, using fragmented, disconnected tech to solve what is an integrated, connected problem.

The industry’s habit is to answer a system-shaped problem with a feature-shaped product. Redesign will not survive that habit, because it is the most interconnected capability in the entire HR tech stack. Redesign must “write back” into all these related downstream processes and systems – if not directly, as an integration, then as a shared context and data layer informing the other key decisions.