I am running six AI projects across my supply chain division right now. Each project targets a different process domain. Five are led by senior people from my team. The sixth one is mine. I kept one project for myself because I do not believe in asking people to do something I am not willing to do. If I want my leaders to explore AI, test tools, and learn from mistakes, I need to go through the same process. It also gives me a much better understanding of the technology, so when they come to me with questions, my answers are grounded in real experience, not assumptions.
Each leader got one instruction that changed the dynamic completely: this is your project. You define the path. You choose the tools. You decide how to engage users. Come to me when you need me. Do not wait for me to tell you what to do next.
Some of them lit up. Others froze.
That reaction told me more about the real challenge of AI transformation than any technology assessment ever could.
The freedom nobody asked for
When people talk about AI transformation, they focus on tools. Algorithms. Data pipelines. Architecture decisions. Those things matter. But they are not where most initiatives get stuck.
They get stuck at the moment when a capable, experienced leader realizes that nobody is going to give them a detailed plan for what to do with AI in their area.
This is not a failure of the person. It is a product of how large organizations work. Decades of corporate hierarchy train people to execute. Follow the process. Deliver against the brief. Hit the milestones. Report upward. Get approval before moving.
That system works well for stable operations. It fails completely for anything that requires exploration, experimentation, and judgment under uncertainty. AI is exactly that.
When I told my five leaders to take ownership of their projects, two distinct patterns emerged.
The first group moved quickly. They started exploring tools, talking to users, sketching out approaches. Not because they were smarter or more experienced. Because they were comfortable with ambiguity. They had worked in environments before where the answer was not predefined.
The second group hesitated. They asked good questions. Detailed questions. "What exactly should the output look like?" "Which stakeholders should I talk to first?" "Can you give me an example of what you expect?" These are not bad questions. In a traditional project, they are exactly the right questions. But in this context, they were a signal. The person was looking for instructions where none existed.
If you are reading this and recognizing yourself in that second group, here is what I want you to know. That hesitation is not weakness. It is a rational response to decades of working in environments that rewarded following instructions and punished independent decisions that went wrong. The fear behind it is specific: what if I make a call and nobody has my back? That fear deserves a direct answer. If your director gave you ownership, ask them one question: what happens when I make a mistake? If the answer is "we fix it together," you are safe to move. If the answer is vague, that is a different problem. And it is not yours to solve.
The hardest part of this phase was not managing the second group. It was resisting my own instinct to help them by giving them exactly what they were asking for.
Why the instinct to direct is the problem
When a leader on your team hesitates, every management instinct says the same thing: step in. Clarify. Give direction. Unblock them.
That would have solved the immediate problem. And it would have guaranteed that the same person would come back next week asking for the next set of instructions. And the week after that.
The pattern would repeat until the project becomes something I run through six people, instead of six people running six projects.
I have seen this happen before. Not with AI. With any initiative where the scope is unclear and the path is not predefined. The director who "helps" too much ends up being the bottleneck. Every decision flows through one person. The team executes precisely what they are told. Nothing more. Nothing less.
That is not a team that scales. That is a team that depends on one person's capacity.
So I chose the uncomfortable option. When someone asked me for detailed instructions, I did not give them. I said: "What do you think the right approach is? Try it. If it does not work, we adjust."
That answer is not satisfying. Not for the person asking. Not for me watching them struggle with it. But it is the only answer that builds something that lasts.
Available, not directive
There is a difference between giving people freedom and abandoning them.
I did not disappear. I made it clear that I am available whenever they need me. If they hit a wall, if they are unsure about a decision, if they need to pressure-test an idea, I am there. Every one of them knows that.
But there is a specific boundary I maintain. I answer when asked. I do not volunteer the solution before they have tried to find it themselves.
This distinction sounds small. In practice, it changes everything.
When a leader comes to me and says "I am stuck, here is what I have tried, what do you think," we have a productive conversation. They have done the thinking. They have a position. I can challenge it, refine it, or confirm it. Either way, they leave with a decision they own.
When a leader comes to me and says "What should I do," I push back. Not harshly. I ask: "What have you considered so far? What are the options you see?" If they have not thought it through yet, I tell them to come back after they have.
I know how this looks from the other side. When your director responds to your question with another question, it can feel like a test. Or like they do not care enough to help. That is not what is happening. What is happening is that I trust you to think it through. And I know that if I give you the answer now, I take away the one thing that will make you stronger next month: the experience of solving it yourself. The pushback is not rejection. It is the opposite.
This is not a management technique I read in a book. It is the only way I have found to build leaders who think for themselves instead of waiting for approval.
The discomfort is real. Sometimes they take a direction I would not have chosen. Sometimes they spend a week on something I could have solved in a day. That is the cost of building independence. And the cost is worth paying.
From project leader to product owner
This connects to something I wrote about a few weeks ago. The structural shift from project leader to product owner.
In a traditional AI project, someone builds the tool, launches it, and moves on. The project closes. Adoption becomes nobody's problem. I described this pattern in detail and proposed a structural fix: one person who owns the project from start to sustained adoption.
What I am doing now takes that idea further.
Each leader on my team does not just deliver an AI tool to their domain. They own the full lifecycle. They build it. They launch it. They train users. They collect feedback. They iterate. They fix what does not work. They expand what does. And I do the same with my own project. When a leader asks me how to handle a situation where users resist the tool, I can speak from my own current experience, not from something I read or managed years ago.
This is a bigger ask than most directors realize. You are asking an executor to become an entrepreneur inside a corporation. You are asking someone whose career has been built on following well-defined processes to define a new process from scratch.
Not everyone is ready for that on day one. Some need weeks before they find their stride. Some need to fail at something small before they understand that failure is part of the model, not a career risk.
But the ones who make it through that transition become something that large organizations desperately need: leaders who own outcomes, not tasks.
Six projects that only work together
There is one more layer to this that makes the structure more complex and more powerful.
The six AI projects are not isolated from each other. They are designed to connect.
Each one targets a different process in the supply chain. Different tools. Different user groups. Different problems. On the surface, they look like six separate initiatives.
In practice, they feed each other. When one project improves data quality in its domain, the next project gets cleaner inputs. When the planning project produces more reliable outputs, the operations project makes better decisions. When the operations project automates routine checks, it frees up time for the team working on capacity analysis.
This interconnection is deliberate. It means that success in one area multiplies across the division. But it also means that each leader needs to understand not just their own project, but how it connects to the others.
That requires something that autonomy alone does not produce: collaboration without coordination from the top.
My leaders talk to each other about their projects. Not because I scheduled a sync meeting. Because they figured out that their outcomes depend on each other. The planning lead needs to know what the data quality lead is building. The operations lead needs to understand how the planning outputs will change. These conversations happen because the structure creates natural dependencies, not because I drew a RACI matrix.
If each leader only looked at their own project, the result would be six isolated tools. Useful individually. Limited collectively. The multiplication effect only happens when people see beyond their scope. That is another skill that micromanagement prevents. When you tell people exactly what to do, they stop looking sideways. They optimize their piece. They do not think about the system.
What this costs in the short term
I want to be honest about the price of this approach.
Right now, things move slower than if I dictated every step. Some decisions take longer because my leaders are working through problems I have already solved in my head. Some paths turn out wrong. I watch that happen and do not intervene unless they ask.
There are days when I wonder if it would be faster to just tell them what to do. Give them the plan. Let them execute. Save three weeks of learning curve.
It would be faster. For now. And it would guarantee that in six months, the same team would still need me to tell them what to do next.
There is one question I know every director reading this is asking: how do you sell this to your own boss? I do not hide the approach. I explain that we are building leadership capacity alongside technical capability. That the first quarter will show slower delivery on individual projects. But that by the second quarter, I will have five people who can run initiatives independently instead of one person running five things through proxies. Most senior leaders understand that math when you frame it as scalability, not experimentation.
The compound effect of independence works like the snowball effect I described in the adoption playbook. It starts small. In the first weeks, the investment looks bigger than the return. A leader spends two days exploring an approach that I knew would not work. A meeting runs longer because three people are brainstorming instead of one person directing.
But the gains are not linear. They compound.
A leader who found the right approach on their own will defend that approach with conviction. They will troubleshoot it themselves when problems appear. They will improve it without being asked. Because it is theirs. Not something they were told to build.
Multiply that by five. And add the sixth project where I go through the same process myself. Five people who think independently. Five people who assess risk before escalating. Five people who propose solutions instead of waiting for instructions. Plus one director who stays sharp by doing the work, not just overseeing it.
That creates organizational capacity that one director thinking for six people never could.
The mindset shift nobody warns you about
There is one thing I did not anticipate.
The hardest mindset shift is not the team's. It is mine.
I am a person who has strong opinions about how things should be done. I have been running supply chain operations for years. I know what works and what does not. When I see someone heading in a direction I consider suboptimal, my first impulse is to correct it.
Having my own AI project helps with this. When I struggle with a tool or make a wrong call in my own domain, it reminds me that the learning process is not straightforward. It makes me more patient when I see my leaders go through the same thing.
Holding back that impulse is the real discipline of this model.
Not because I am always right. I am not. Some approaches my team tried that I was skeptical about turned out better than what I would have done. That experience has been humbling and useful.
But even when I am right, stepping in too early takes away the learning. The person never discovers why the approach does not work. They just follow my direction and move on. Next time a similar situation comes up, they ask me again. Nothing changed.
The real test of this leadership model is not whether the team delivers results. They will. The real test is whether I can stay patient long enough for the compound returns to arrive.
What this looks like in practice
I do not want this to sound theoretical. Here is how a typical week looks.
Monday, I check in with each leader individually. Not a status meeting. A conversation. "Where are you? What is the biggest question you are working through? Do you need anything from me?" Most of the time, they do not need anything. They update me on their progress and move on.
Tuesday through Thursday, they run their projects. They talk to users. They test tools. They make decisions. Some of those decisions I find out about later. That is fine. If they made the wrong call, we address it. If they made the right call, I do not need to have been involved.
Friday, the team meets. Not to report to me. To share with each other. What they learned. What failed. What they need from a colleague's project. These Friday sessions started stiff and formal. After a few weeks, they became the most productive meeting on everyone's calendar. Because the content is real. Nobody is presenting slides to impress the boss. They are solving problems together.
The week I stop being necessary in those Friday meetings is the week I will know this model works.
If you are building something similar
You do not need six AI projects to apply this. The principle works with one.
If you are a director or VP running any kind of transformation initiative, ask yourself one question: if you disappeared for two weeks, would your team continue making progress, or would they wait for you to come back?
If the answer is "they would wait," the bottleneck is not your tool, your budget, or your timeline. It is your management model.
The fix is not a framework. It is a decision. Stop giving answers and start asking questions. "What do you think we should do?" "What are the risks you see?" "What would you try first?"
Then let them try it. Stay close enough to catch them if they fall. Far enough to let them learn to walk.
And if you are on the other side of this. If you are the leader who just got handed a project and a level of freedom you did not expect. Here is one thing that helped my team. Do not wait until you have the perfect plan. Start with the smallest useful action. Test one thing. Report what happened. Ask for feedback on your approach, not for instructions on what to do next. That shift, from "what should I do" to "is my approach right," is the moment when ownership becomes real.
The first few weeks will be uncomfortable for everyone. On both sides. That is the signal that something is actually changing.