You Wont Understand AI Until You're Fired
Most AI adoption programs ask people how AI could help them work faster. The question protects the job, so the answer is always marginal. A real redesign almost never comes from the person doing the work, which means leaders have to manufacture the discontinuity a firing would otherwise create.
Everyone Has to Get Fired
Almost nobody rebuilds their own job while they still have it.
Most people won’t seriously redesign their job around AI until someone takes the job away from them. Then they’ll do the exercise properly, with real urgency and no sacred cows, from the wrong side of the decision.
That isn’t a discipline problem. It’s what happens when you ask the person with the most to lose to propose eliminating their own work.
The question contains its own answer
Most AI adoption programs ask employees some version of: where could AI help you do your work faster?
That question protects the job. The person answering has spent years becoming excellent at a particular workflow, has status and headcount attached to it, and has just been reassured by management that AI is an assistant rather than a threat. They’ll find something real. They’ll find about a chatbot’s worth.
The question that produces a redesign is different: which 70 percent of this work shouldn’t be done by you at all? Very few people ask that about themselves voluntarily, and fewer answer it honestly.
Intel ran this exercise in 1985. Japanese competitors were destroying the memory business the company had been built on, and Andy Grove asked Gordon Moore what a new CEO would do if the board replaced them both. Moore said a new CEO would get Intel out of memory. Grove’s suggestion was that the two of them walk out the door and come back in as the new guys.
Moore was the CEO. Grove was the president. They could have made that call on any ordinary Tuesday, and they still needed the fiction of getting fired to see it.
People optimize inside a constraint instead of attacking it
I watched a version of this with a client recently. A design project had been sitting in a queue for weeks, waiting for someone to have bandwidth. I said, “Just watch me for a minute,” opened Claude, gave it the assignment, attached a screenshot of the page that needed to change, and the project started moving.
The interesting part isn’t that it worked. It’s that the constraint had been sitting there for weeks and nobody inside the workflow had gone after it. They had adapted to it. They scheduled around it, apologized for it, and treated the queue as weather.
The economics underneath told the same story. These were six-figure employees, roughly $50 an hour before benefits and overhead. Some were paying $20 a month out of pocket for limited AI accounts because the more capable plan was hard to get approved. At $50 an hour, that plan pays for itself if it returns two hours a month.
Nobody decided this. Software approvals are built for a category of purchase that behaves nothing like a $100 seat one employee needs this week. But the people closest to the problem worked around it instead of escalating it, because working around it is what the last ten constraints had required. We approved the better plan in an afternoon. It should have been approved months earlier, and the reason it wasn’t is the whole point.
The redesign has to come from someone who doesn’t own the job
If you’re leading this, the practical conclusion is uncomfortable. You probably can’t get a real redesign out of the people currently doing the work, and asking them more insistently won’t change that. You have to manufacture the discontinuity.
- Have someone who doesn’t own the function rebuild the workflow from the outcome backward, then bring the owner in to break it.
- Set a constraint rather than a goal. “Same outcome, one fifth of the cycle time” produces a different exercise than “find AI use cases.”
- Stand the redesigned version up next to the existing one instead of debating which is better.
None of this means cutting first. The executive who watches an impressive demo, assumes a function is solved, and cuts the team is making the same mistake from the other direction, and will find out what real data, real exceptions, and real customers do to a demo. Redesign and test the work, then decide what the roles are.
Start with one outcome where work is visibly piling up behind one person, and give the redesign to somebody else. The person stuck in the queue has already made peace with it. That’s the problem.
Questions
Why won't employees redesign their own jobs around AI?
Because the redesign threatens the expertise, status, and headcount they spent years building. Asking how AI could speed up existing work is a question that protects the job, so the answer is usually a chatbot bolted onto the current process.
What did Intel's leaders do in 1985?
Facing Japanese competitors in memory, Andy Grove asked Gordon Moore what a new CEO would do if the board replaced them both. Moore said a new CEO would get Intel out of memory. Grove suggested the two of them walk out the door and come back in as the new guys.
How can a leader get a real redesign?
Manufacture the discontinuity. Have someone who doesn't own the function rebuild the workflow from the outcome backward, set a constraint rather than a goal, and stand the redesigned version up next to the existing one.
Does this mean cutting the team first?
No. The executive who watches an impressive demo, assumes a function is solved, and cuts the team is making the same mistake from the other direction. Redesign and test the work, then decide what the roles are.
CITE THIS PIECE
Ryan Matzner “You Wont Understand AI Until You're Fired.” Staghorn, 9 August 2026. https://staghorn.ai/notes/everyone-has-to-get-fired