Design the Struggle Back In

The Leadership Move Nobody Is Making on AI

The Leadership Move Nobody Is Making on AI

Every AI rollout gets scored the same way: how much friction did it remove. Fewer approval steps. Faster first drafts. Less waiting on someone senior to review the work. The instinct is universal because it is usually right. Most organizational friction is waste, and removing it is the whole point of transformation. Some of that friction was never waste, though. It was training. The lawyer who used to draft the routine contract herself, the analyst who built the first version of the model by hand, the associate who wrote the memo nobody important would read: none of that work existed because it was the best way to produce the artifact. It existed because doing it badly, slowly, under supervision, was how a junior person became a senior one. Remove that work with AI and you have not eliminated inefficiency. You have eliminated the on-ramp. This is not a call to slow down AI adoption. Slowing down protects the wrong thing, the existing shape of the work, not the developmental value inside it. The leadership move that actually holds is different and harder. It is deliberately designing struggle back into the system AI just made frictionless. Picture a junior analyst three years into a role that, five years ago, would have had her building forecasting models from scratch for the first eighteen months. Today AI builds the first version in minutes, correctly, most of the time. She reviews it, approves it, moves on. She is faster than her predecessor ever was at the same tenure. She is also, by every account from the people who manage her, worse at knowing when the model is wrong. Nobody made a decision to let that happen. It happened because nobody made a decision at all.

The instinct to protect is the wrong instinct

When leaders notice that AI is eroding how junior people learn, the reflex is protective. Ring-fence some tasks. Tell the senior team to do things “the old way” some of the time. Add a training program to compensate for what the workflow no longer teaches. None of it works, because it treats a design problem as a scheduling problem. A training program bolted onto a workflow that AI has already hollowed out is not struggle. It is theater. The junior person knows the real version of the task is being done by AI three doors down. Practicing on a sandboxed exercise that nobody actually depends on does not build the same judgment as doing the work when it counts, because judgment is built under real stakes, not simulated politeness. There is a second failure mode that looks like caution but is really nostalgia: refusing to automate anything a junior person currently does, on the theory that all friction is developmental. That is just as costly as removing everything. Most of the friction in most workflows is genuinely waste. Formatting, reformatting, chasing down a source, restating something already said in a different template. AI should eat all of that immediately and completely. The leadership move is not protecting the old workflow and it is not automating everything in sight. It is building a new workflow that has real stakes and is still safe enough to fail inside.

Lever one: build the practice environment, not the training deck

The clearest version of this shift already exists in the market: the GenAI simulator, a realistic, high-stakes practice environment where the cost of a bad decision is contained but the decision itself is not simplified. We wrote about this shift in depth here, and the data is not subtle. Bank of America uses simulators to train financial advisors on the hardest conversations they will have with clients, the ones carrying real emotional and financial weight, before those advisors are in a room with real money on the line. \SOURCE: Bank of America, The Academy – [https://careers.bankofamerica.com/en-us/career-development/the-academy\] What makes a simulator different from a training module is that it preserves the actual difficulty of the judgment call while removing the actual cost of getting it wrong. A compliance officer practicing on a simulated ambiguous disclosure is still wrestling with ambiguity. A new manager rehearsing a layoff conversation with a simulated employee is still managing real discomfort, real hesitation, real second-guessing. AI can generate the finished artifact instantly. It cannot generate the discomfort of deciding under uncertainty, and that discomfort is the entire training mechanism. Skip it and you have skipped the part that actually builds the skill. Most simulators in production today are company-built, not vendor-bought, and that is not a gap to wait out. It is a signal that this capability has to be designed on purpose rather than procured off a shelf. If your organization has not identified at least one high-stakes judgment call worth building a practice environment for in the next twelve months, that is the first gap to close, and it is worth closing before the senior people who currently hold that judgment start leaving. Picking which judgment call to simulate first is not a hard problem once you frame it correctly. Ask where a bad call currently costs the most, in dollars, trust, or time, and ask who currently only learns that judgment by making the mistake live, in front of a real client or a real dataset. That intersection, high stakes and currently learned the hard way, is the shortlist. Most organizations have two or three candidates on it, not twenty, which is exactly why this is buildable in a year rather than a decade

Lever two: redesign the role before you deploy the automation

Most automation decisions get made at the task level. Can AI write this memo. Can AI draft this contract clause. Can AI build this model. The right question sits one level up: if AI does this task, what does the person who used to do it now do instead, and does that new thing still build judgment, or did the promotion happen in title only. This is a redesign question, not a tooling question, and most organizations skip it entirely. They automate the task and assume the person “moves up the stack” without ever specifying what moving up the stack actually requires them to practice. The associate who no longer drafts the memo needs a genuinely new developmental task, something like reviewing three AI-generated drafts critically and defending, in front of someone senior, which one is right and why. Without that explicit reassignment, the associate does not move up the stack. They just stop practicing. Do this redesign work before the automation ships, not after someone notices the bench thinning out. Naming the replacement developmental task, in writing, as part of the rollout plan, is the actual substance of the redesign. Everything else, the tool selection, the pilot, the rollout timeline, is just removing a step. The step you removed has to be replaced with something that still teaches, or the organization has quietly traded a training pipeline for a productivity metric. This is also where facilitation earns its place in the AI conversation, and not as a soft add-on. Deciding which developmental tasks survive automation is a genuine disagreement waiting to happen: the people who benefit from moving fast and the people who are responsible for who exists in the role five years from now rarely agree on the trade instinctively. Someone has to structure that conversation on purpose, in the room, before the rollout, or it never happens and the default answer becomes whatever is fastest to ship. “Review and defend” is a useful default for what the replacement task looks like, but it only works if the defense is real. That means the junior person does not just initial the AI draft. They have to be able to explain, out loud, to someone who will push back, why this version and not one of the other two the model could have produced. If nobody ever pushes back, the review step degrades into the same rubber stamp the memo used to be, just with less writing involved.

Lever three: apply a real test, not a feeling

The test that separates friction worth keeping from friction worth removing is simple to state and hard to apply: does this friction develop the person doing it, or does it just drain them. Formatting a document by hand develops nobody. Deciding what argument the document should make, under real constraints, with real consequences for getting it wrong, develops everyone who has to do it. AI should eat the first kind of friction completely and immediately. The second kind is the one leaders need to protect, redesign around, and in some cases deliberately reintroduce. Applying that test requires actually walking the workflow, task by task, and asking who is currently doing the developmental version of each step and whether AI just quietly took it from them without anyone deciding that on purpose. Most leaders have not done this walk. It takes an afternoon with the team that actually does the work, not a quarter with a consulting deck, and it is the single highest-leverage hour available to anyone worried about the bench five years out. The output of that afternoon should be a short, specific list: which tasks stay fully automated because the friction there was never developmental, which tasks get a redesigned developmental replacement, and which one or two tasks get deliberately protected from automation for now because nothing has been designed yet to replace what they teach. That third category should be small and it should have an expiration date. Protecting a task indefinitely is the nostalgia failure mode again, just moving slower.

What this looks like in the room

None of this happens by memo. It happens in a room with the people who actually do the work, walking the real workflow step by step, naming out loud where the struggle currently lives and what it currently builds. That conversation surfaces disagreement fast: the senior person who says “that’s just busywork” and the junior person who says “that’s the only place I ever get real feedback” are describing the same task from two different vantage points, and both of them are right about their own experience. Leaders who skip that conversation and redesign the workflow from a whiteboard alone consistently guess wrong about which friction is developmental. The people doing the task know. The redesign only works if someone facilitates that disagreement into a shared answer instead of letting the loudest voice or the fastest deadline decide by default. The senior person in that room also needs to hear something uncomfortable: the busywork they are relieved to hand off might be the exact thing that made them good at their job. That is not an argument for keeping it exactly as it was. It is an argument for taking seriously what it built before deciding it is safe to remove.

The stakes are five years out, which is why almost nobody is doing this

Nothing about eroded apprenticeship shows up in this quarter’s numbers. Output goes up, cost goes down, and the dashboard looks great. The cost shows up later, when the senior people who have been quietly absorbing junior work retire or move on, and the organization discovers it has no one who actually built the judgment to replace them. By then the fix takes years, not an afternoon. That lag is exactly why this requires deliberate leadership action instead of waiting for the market to fix it on its own. Nobody gets punished this year for skipping the redesign. Somebody gets punished badly in year five, and the people making today’s automation decisions are rarely the ones who will answer for that later. Design the struggle back in now, while it is still cheap. The friction AI removed was never the point. The friction leaders choose to keep on purpose is.