Making the Invisible Visible — A clear path. A clear standard. A clear outcome.

The foundational job of a leader is developing people. Here is a practical method for doing the hardest part of that work.

Article 04 in the Leadership Journey Series

I want to start with a question that Dylan DuFresne poses in his book The Phantom Pallet.

When you stay late and solve problems nobody else can solve, what does that make you?

The answer his character Dave eventually arrives at is not what most leaders expect to hear. It is not indispensable. It is not valuable. It is not a strong performer.

It is a single point of failure.

That reframe stopped me when I read it. Because it describes something I have done. Something most leaders I know have done. We carry the team because we can. Because it is faster. Because the standard feels important and we are the only ones who can reliably meet it. And we tell ourselves that is leadership.

It is not. It is the promotion trap in its most advanced form. The individual contributor who got promoted and never stopped being one.

The foundational job

Developing people is the primary job of a leader. Not the secondary one. Not the one you get to when the urgent work slows down.

The primary one.

Everything else a leader does either supports that job or distracts from it. The problem is that urgent work is always more visible than developmental work. A crisis solved feels like progress. A team member who grew this quarter is harder to point to. So we keep solving crises and telling ourselves we will get to the development work when things settle down.

Things do not settle down. The crises keep coming because the team has not developed the capability to handle them. And the leader keeps carrying the weight because the team has not been given the framework to carry it themselves.

The firefighter who is always putting out fires never has time to build the system that prevents them. That is not a workload problem. It is a leadership identity problem.

DuFresne frames this in The Phantom Pallet as the difference between a firefighter and an architect. The firefighter solves the immediate problem. The architect builds the system that prevents it. Both roles feel productive. Only one of them scales.

The problem with expert knowledge

Here is why making that shift is so hard for people who are genuinely good at their jobs.

Highly effective people arrive at solutions intuitively. The steps between recognizing a problem and arriving at an answer happen internally, invisibly, without conscious tracking. Years of experience get compressed into what feels like instinct. And that instinct produces good outcomes consistently enough that nobody ever asks to see the work.

Until the leader has to teach someone else to do it.

That is when the invisible steps become a problem. You cannot teach what you cannot see. And you cannot see it because you have never had to. The expert skips steps without realizing it. The learner gets lost without knowing why. The process documentation that results captures what was done but not why, leaving the gap between following instructions and applying judgment permanently open.

This is sometimes called the curse of knowledge. The more deeply you understand something, the harder it becomes to remember what it felt like not to understand it. The steps that feel obvious to you are genuinely not obvious to someone who has not lived them. But you are standing on the other side of the gap and cannot see it from where you are.

DuFresne addresses a version of this in The Phantom Pallet when he asks how organizations capture and transmit expertise that exists only in experienced practitioners' heads. He calls it tribal knowledge. What is lost when veteran employees retire or leave without having transferred what they know. His answer involves building systems that make that knowledge accessible regardless of who is in the building.

That is exactly the problem this article is about. And it is where the method I have been developing comes in.

The thinking extraction problem

I tried for a long time to document my own reasoning processes. To write down how I approach a problem so my team could follow the same path. It did not work well.

The reason is simple. Most of the time I move from need to solution without consciously tracking the steps in between. When I tried to write them down after the fact, I wrote down what I remembered doing, which was not the same as what I actually did. The invisible steps stayed invisible because I could not see them from the inside.

What I needed was something that could ask me the right questions at the right time. Something with enough domain knowledge to recognize when I had skipped a step. Something that would keep asking until the reasoning was complete.

I built a project in Claude with a simple instruction set. I present a technical problem and the solution I arrived at. The AI asks questions to determine how I got there. The output becomes a guide for my team.

What the AI does that I cannot do alone is force the thinking to become sequential and explicit. It does not accept the jump from problem to solution. It asks about the step I skipped. Then the step before that. Then the assumption underneath that step that I did not know I was making.

The AI does not solve the problem. It makes me explain how I solved it. That is a completely different function. And it turns out to be exactly the function that expert knowledge transfer requires.

What the process produces

The first guide that came out of this process surprised me.

It assumed zero knowledge on the part of the reader. Every step was explicit. Every assumption was named. And somewhere in the middle of the document, a reference appeared to the OSI model, a foundational framework taught early in network administration.

I had not set out to teach the OSI model. I had set out to document a troubleshooting process. But because the AI was asking me to explain my reasoning at each step, the underlying framework I was drawing on became visible. The team member reading the guide gets the solution to the specific problem and the mental model that produced it.

That is a fundamentally different kind of document than a standard troubleshooting guide. Most process documentation captures what was done. This approach captures why. And the why is where the transferable learning lives.

Why AI works where other methods do not

I have tried other approaches to this problem. Writing documentation after the fact. Talking through a problem with a colleague. Recording myself explaining a solution.

None of them produced the same result. And I have thought carefully about why.

A peer asking structured questions about your reasoning can feel like an interrogation. A manager asking the same questions can feel judgmental. Both situations carry social friction that shapes what you say and what you leave out. You edit yourself without realizing it.

The AI has no agenda. It is not judging the quality of your reasoning or the efficiency of your process. It is just asking the next question. That removes the friction that makes honest expert thinking extraction so difficult in human-to-human interactions.

The domain knowledge matters too. An AI that understands network architecture can recognize when a troubleshooting step is missing in a way that a generalist facilitator cannot. It knows what question to ask because it understands what should come next.

The process is still new. I do not yet have a case study where a team member followed one of these guides and solved a problem they would have escalated before. But the quality of the first document suggests the method is sound. The proof will come with time and reps.

The destination

In The Phantom Pallet, the moment that marks Dave's transformation as a leader is not a technical breakthrough. It is a baseball game.

His plant faces a chiller crisis. His team handles it. He stays at his son's game.

That is the destination. Not a leader who is indispensable. A leader who has built a team that does not need them to be present for every crisis. DuFresne calls this the shift from firefighter to architect. The firefighter's value is in being there. The architect's value is in what they built before they left the room.

Making your thinking visible is how you make that shift. Not all at once. Not perfectly. But progressively, one guide at a time, one problem at a time, one team member who can now solve something they could not solve before.

If your team could handle the chiller crisis without you, what would you do with the time and energy that freed up? How much more productive could your team become with a framework built from your best thinking rather than dependent on your presence? How much more could you scale the company if the knowledge that lives in your head lived in your systems instead?

The firefighter cannot answer those questions. The architect already has.

That shift does not happen overnight. It happens one guide at a time, one problem documented, one team member who can now solve something they could not solve before. The method is simple. The discipline to use it consistently is not.

But the leaders who do the work will find themselves with something most never achieve. A team that grows without them in the room. A company that scales because the knowledge lives in the system, not just in their head.

That is worth the effort.

About this series

This is the fourth article in the Leadership Journey series. Article 01 introduced the transition from individual contributor to leader. Article 02 examined the environment that shapes development. Article 03 named the promotion trap. Article 05 will explore the owner mindset and what it looks like when a team stops waiting for direction.

Reference

DuFresne, Dylan. The Phantom Pallet: A Manufacturing Fable About Data, Trust, and Transformation. Abelara, 2025. Available on Amazon.com.