You Can't Rebuild It by Accident

Before you build a single program, the principles that separate real development from the appearance of it.

In my last couple of posts, I made a case and then offered a diagnosis.

The case: Our junior Procurement talent is at risk, because AI is removing the foundational work that used to build the practitioner.

The diagnosis: That foundational work was never one thing - not a course of study nor a series of tasks. Rather, it was a developmental chain - three uneven inputs that allowed the development of discernment, which matured into judgement, and culminated in a trusted, accountable practitioner (see image below).

Our old apprenticeship models produced all of this (almost) for free. It was almost incidental - a by-product of juniors simply doing the work, day after day, next to people who were better and more experienced than them. They watched, modeled, learned, absorbed and became. But with AI changing that developmental model, we need to rethink how we get our juniors up and running.

We need, therefore, a new brief: to rebuild each element of the chain deliberately, defending hardest the ones AI severs most directly. Today’s and next week’s post will focus on how we can execute to this brief - with today’s post detailing the ground rules for this rebuilding i.e. what needs to come before we can implement any successful junior development program.

But before we do, it’s important to note a potential complication here.

When you try to produce something on purpose that used to happen by accident, you will either do it well, or you will do it badly. In most situations, “doing it badly” becomes self-evident, so you can see it and course-correct.

Not when it comes to AI. In this particular case, done badly doesn’t just mean “less effective”, it means building something that looks like development - busy, well-funded, full of activity - and yet not producing the discernment and judgement we need in our practitioners i.e. reproducing the very discernment trap we’re trying to escape. And we only figure it out years later.

So before we set about building a program, we need to understand the ground rules, as well as the constraints. Internalize them and you get a program that delivers. Get them wrong and no amount of programming will save you. (I’ll get to the actual building blocks - the simulations, the rotations, the mentoring and the rest - next week.)

Let’s start with the rules - and there are, specifically, four of them.

Rule 1: Make the Invisible Visible

When we think about traditional apprenticeship models, say, a blacksmith and his apprentice, the work is visible. The apprentice watches the master’s hands, sees the angle of the hammer, observes the results, copies it, makes mistakes, gets corrected, then learns to do it right. The entire curriculum is on display.

But in knowledge work, the important part - the thinking - is invisible. When a senior practitioner looks at a sourcing recommendation and says “no, this doesn’t work,” the analysis that produced that judgement happens inside their head. The apprentice only sees the conclusion and maybe an explanation. They don’t see the reasoning behind it and, no matter how good the explanation, they won’t intrinsically understand it.

This is the central problem when it comes to developing judgement, and the first rule of any rebuild follows directly from it: you have to deliberately make expert thinking visible.

This isn’t a new or fringe idea. There’s a whole body of work on “cognitive apprenticeship” built precisely around making the invisible thinking of experts visible to novices - and it’s serious enough that McKinsey built its own developmental model on it. It names six methods worth knowing: modeling (expert performs the work as the student observes), coaching (expert observes and facilitates as the student performs the work), scaffolding (expert provides support that’s gradually removed), articulation (student explains their knowledge and reasoning), reflection (student compares their performance with others), and exploration (student explores in diverse situations, solving their own problems).

In practice, this translates to the difference between a senior who hands a junior a finished category strategy, and one who narrates why as they build it: “I’m weighting this supplier’s capability over their price because our product roadmap is going to need those capabilities in two years, and switching later is going to be expensive.” That narration - the part most seniors skip because it’s obvious to them - is the actual curriculum.

The reason this is a principle and not just a nice technique is that every single building block I’ll detail in my next post is, underneath, just a delivery mechanism for those six methods. A high quality program has to make expert thinking visible, otherwise it’s just activity posing as development.

Rule 2: It’s Human and Machine - Not Either/Or

There are two lazy positions on AI that plague much of mainstream thinking, and both are wrong.

The first is nostalgic: keep AI away from junior work so they can learn the “real” way. But that’s neither possible nor desirable - the tools are genuinely valuable, and a junior who can’t use them is going to be unprepared for the actual job.

The second is the one my last post warned about: let AI do the work and have juniors supervise it. That’s the discernment trap - handing someone the job of judging output they have no calibrated basis to judge.

Rule 2, then, sits between them: the question is never whether juniors use AI, but in what sequence and in what role. AI is a phenomenal development tool when used one way and a discernment-destroyer when used another way. The difference is entirely in the design of how we use the tools, not in the tools themselves, which leads directly to the most important rule of the set.

Rule 3: AI Must Be a Questioner, Not an Answerer

If you take one thing from this post, take this:

AI that hands you the answer builds nothing that lasts. AI that makes you reason builds something that does.

Everything about how juniors use AI should be configured around that single distinction - which, specifically, means three things:

Struggle first, AI second. This sequence is non-negotiable. The junior attempts the work and commits to a position before the AI engages. Think about a junior building a should-cost model. The destructive version of this is “AI, build me a should-cost model for this part”. They might get a polished output in seconds, but they’ll learn nothing and have no way of knowing whether it’s right. The developmental version is the reverse: they build their own first, then bring AI in to pressure-test it - or, better yet, the AI asks them, “what did you assume about material costs, and why?” In the first version, the machine did the thinking. In the second, the junior’s own struggle did the thinking and the machine sharpened it. Always embed the ‘struggle’ first.

Use AI as a Socratic tutor. Configured well, AI can withhold the answer, ask guiding questions, and scaffold a junior toward their own conclusions - which is exactly what a good mentor does, but at infinite scale and availability. And there’s early evidence that this matters in precisely the way you’d hope: when AI is set up to reframe its explanations as questions, people get measurably better at spotting flawed reasoning. When it simply hands over the answer in conversation, the apparent gain evaporates when the conversation ends. Better for us to own the reasoning than to ‘borrow’ the answers.

Productive struggle is a feature, not a bug. The natural instinct of a well-meaning manager is to remove friction from a junior’s path. But when it comes to the learning process, this instinct is wrong. The struggle is not an obstacle to learning, it is the learning. It’s the thing that builds mental maps and intrinsic understanding. It’s important, therefore, for us to design for friction, and not against it.

I won’t pretend this is easy, because it does run against so many of the incentives that have become endemic in our daily work lives: the need for speed, efficiency, the “why are you doing it the slow way when the AI can do it instantly?”. All of those incentives push us in the other direction, which is exactly why this can’t be left to juniors to figure out on their own, or even to individual line managers. It has to be a deliberate, protected protocol, set and defended from the top. Which brings us to our next rule.

Rule 4: Leadership Shows Up in Hours - Not Just Dollars

The most common way training programs die is through “support” that’s no more than lip service. Leadership sponsors an initiative - approves a budget, sends a launch email, gives a nice speech and commissions a dashboard - and then goes back to their actual jobs. That isn’t sponsorship, not in the sense needed here.

If you go back to Rule 1, you’ll see that those six methods that make expert thinking visible all run on one thing: senior time. Modeling is a senior thinking aloud. Coaching is a senior watching a junior work and correcting them in the moment. There is no version of “make the invisible visible” that doesn’t cost the expert some real portion of their time. So when leadership funds a program but won’t spend the calendar time to back it up, they’ve built something superficial.

The rule, then, is: sponsorship is measured in senior hours on calendars, not just dollars in budgets. And it has to be visible, because juniors are watching - they calibrate what matters in an organization by what they see their leaders actually do, not by what leaders say they value. A CPO who blocks two hours a week to sit with juniors and think out loud teaches more about the function’s standards than any policy document ever will.

Two Constraints

The four rules above are choices. The two constraints below are not - they’re conditions that bound what’s even possible, and any blueprint that ignores them is simply not going to work.

Co-location. Part of what we’re trying to rebuild - network capital, and the tacit transfer that comes from sitting near someone better than you - was produced by proximity. Overhearing the difficult supplier call, pulling aside the senior as they walked out of the meeting, absorbing how the room handled a tense moment. And therein lies the problem: some of what we’ve been blaming on AI is, in part, a co-location problem. If the juniors are not in the office - at least on some regular basis - they will not benefit from the serendipity of in-person learning. (In fact, the recent decline in entry-level hiring (we can argue about the exact numbers though that doesn’t really matter) tracks at least as closely with how remote-able a role is as with how AI-exposed it is.)

I don’t want to relitigate remote work here - there are real and good reasons for it, and this isn’t the post for that debate. But any blueprint that pretends the relational layer can be fully rebuilt over Slack and video calls is just not going to hold over the long term. If your juniors are fully remote, you can rebuild the cognitive threads but you will genuinely struggle to rebuild the relational ones.

Motivation. None of this works on a junior who doesn’t want it. I’ve noted before that the spiral runs on the junior’s own drive, and I meant it as more than a flourish. A development program built for the unmotivated is just an expensive babysitting service - until the baby gets a bit older and leaves home.

Two things follow. You select for it - curiosity and a genuine willingness to work through ambiguity matter more than a polished CV. And you protect it - because the fastest way to extinguish a good junior’s drive is to make the work frictionless and therefore meaningless, which, ironically, is exactly what an over-helpful AI does when you let it. Keeping the fire lit is part of the program’s job.

What Comes Next

So those are the rules. Make the invisible visible. Human and machine, never either/or. AI as questioner, not answerer. Leadership measured in hours, not just dollars. All of it bounded by two honest constraints - co-location and motivation.

These are the physics that every program has to obey. They’re how you tell, before you’ve spent a dollar, whether what you’re about to build is real development or not.

In the next post, I’ll lay out the building blocks themselves, sequenced across a junior’s first year and a half, with steadily rising stakes holding it together.