WEEK 52

If AI Is Changing the Job, Why Are You Treating It Like a Software Rollout?

Identity, authority, incentives, job design, fear, ownership, and approval systems often determine whether AI transformation succeeds more than the technology itself.

Week 52 · The System · 8 min read
Editorial illustration for Week 52: If AI Is Changing the Job, Why Are You Treating It Like a Software Rollout?

Some AI work is about the product a company sells to customers. The concern here is different: AI that changes how people inside the company do their jobs. The organization might build the capability or buy it, and it might sit inside operations, support, engineering, finance, or another internal workflow. What matters is that the technology starts changing who does the work, who decides, and how people show that they are good at their jobs.

I learned a version of this problem before the current generative-AI wave.

Store Tasking changed more than the task list

As Store Tasking became more intelligent and more directed, the efficiency story was easy to see. Better signals could help associates spend less time figuring out what needed attention and more time resolving work that mattered. From a software and operations perspective, that can look like straightforward progress.

Some associates described a different concern: they worried about turning into robots.

That reaction was not simply a complaint about whether the task list was accurate. It was about autonomy and visible contribution. If the system tells me every move, how do I show that I understand my department? How do I demonstrate initiative? How does a supervisor recognize the person who notices the problem before the software does?

The software could improve task execution while changing the employee's sense of how judgment, expertise, and leadership showed up in the job. That did not mean the technology was wrong. It meant the job was changing with it.

AI raises the same issue with much more reach because it can now draft, analyze, recommend, route, summarize, and sometimes take actions that used to be part of somebody's role.

A task is not the same thing as a job

When an internal AI capability gets good at a task, organizations can move too quickly from the AI can do this work to the role around this work matters less. Those are not the same statement.

A job is usually a bundle of execution, judgment, context, relationships, accountability, and exception handling. The visible artifact is often the easiest part to automate: the report, the first analysis, the summary, the draft response, the routing decision. The value of the role may also include knowing when the normal answer is wrong, understanding which tradeoff the business is actually making, or carrying responsibility when something goes badly.

The Product question for internal AI is therefore two-sided: what part of the work can the capability now do better or faster, and what does that change about the human role around it? Avoiding the second question does not preserve the job. It just lets the job change without being designed.

Adoption is not neutral when the adopter sees personal risk

Leadership can say, use AI to save time, while an employee hears, show us how much of your job we no longer need you to do. That tension does not make every concern rational or every objection valuable. It does mean adoption is not happening in a neutral incentive system.

If the organization cannot explain what happens to the capacity AI creates, which work should grow, how performance will be measured, or what expertise becomes more valuable, successful adoption can feel like evidence against the adopter's own future. More training will not fix that ambiguity.

People do not need a promise that nothing will change. They need a credible picture of what the changed role asks them to become.

Managers are part of the job redesign too

Internal AI can also change management work. If routine approvals disappear, what is the manager responsible for now? If frontline employees have better information and wider decision boundaries, where does authority move? If status reporting and routine coordination become easier, what kind of leverage should a strong manager create instead?

Those are not communications questions. They are job-design and operating-model questions.

A manager defending an approval may be protecting status, but they may also remember the failure that caused the approval to exist. An expert resisting an AI recommendation may be protecting turf, or they may understand an exception the system has not seen. The useful move is to investigate the objection before labeling it resistance.

Ask what the resistance is protecting

When somebody pushes back on an internal AI capability, get specific. What failure do they expect? Which accountability becomes unclear? What evidence would change their mind? Are they protecting customer quality, a safety control, professional identity, job security, decision authority, or an old habit that no longer earns its place?

Some objections will reveal real system knowledge. Others will reveal incentives or status structures that the organization may intentionally want to change. The point is not to romanticize resistance. It is to stop using change resistance as a label that ends the Product investigation.

For Product, that pushback is evidence about the system around the capability. The workflow, controls, incentives, authority, and human judgment are all telling you what the new operating model has to account for.

Make the future role visible

A credible internal AI rollout should be able to answer more than how many people are using the capability and how much time it saves. It should be able to describe what happens to the work itself.

What should people spend more time doing? What should disappear? Which decisions move? What judgment remains human because accountability requires it? What new responsibilities appear because AI is handling more routine execution? How will somebody demonstrate expertise, initiative, or leadership in the new system?

Those questions are not a promise that every current role remains intact. Some tasks will disappear. Some roles will shrink, others will expand, and some expertise will become less scarce. The responsibility is to make those changes explicit enough that people are not left privately inventing what adoption means for their careers.

There is also a longer-term workforce question about how people develop expertise if AI absorbs more junior work. That matters, but the immediate issue here is whether the organization has designed a believable role for the people being asked to adopt the capability now.

AI changes the social system around the work

An internal AI capability can perform well. The workflow can become faster. Usage can rise. The organization can still stall because the technology changed authority, status, incentives, and identity faster than leadership redesigned the work around it.

So the final question is not only whether the AI works. It is who knows, who decides, who reviews, who gets credit, who owns the exception, and how people understand their value in the new system.

Those are not side effects to clean up after deployment. When AI materially changes the job, they are part of what is being designed.