Someone had bought it. Someone had launched it. A whole team had been told this was the thing that would finally let them keep up with the work. By the time I arrived, it sat there unused, the way a treadmill sits unused. Not because anyone decided to stop. Because no one had ever really started.

I asked what happened. The answer came slowly, and then all at once.

The first thing I learned was that the people who were supposed to use the tool had never been in the room. Not when it was chosen. Not when someone decided how their work would change, where it would happen, which parts of their day would look different by Monday. The decisions about their jobs got made in a room they were never invited to. Then the finished thing was handed to them, and everyone acted surprised when they set it back down.

The second thing I learned was quieter, and worse.

The technical team had said, before launch, that they could not move the data the way the new system required. Not “we would rather not.” Could not. The old information lived in one place. The new tool expected it somewhere else, on rails that did not exist yet and that no one had been given time to build. They put it in writing. They said it in the flat, specific language of people who fix things for a living. And the people who could have slowed down to hear it had left no room in the plan to hear anything.

So the concern went into a document. The document went into a folder. The launch went ahead on schedule.

· · ·

Jeff Hiatt spent the back half of his career on a single, stubborn observation. Organizations do not change. People do.

It sounds like a slogan until you sit with it. A company cannot adopt anything. Only the individual people inside it can, one at a time, each on their own clock. What we call organizational change is just the sum of a few hundred private decisions to work differently than you did yesterday. Miss enough of those private decisions and the change you announced never actually happens, no matter how good the thing you bought.

Hiatt’s other contribution was to map what one of those private decisions actually requires. Before a person genuinely takes on a new way of working, they have to understand why it is happening. They have to want it, or at least not fight it. They have to know what to do differently. They have to be able to do it, with the time and the tools and the skill the change demands. And then it has to be reinforced, or they quietly drift back to the old way the first week things get busy. Skip any one of those and the person stalls. Enough stalled people is a dead tool on a shelf.

Read my first week back through that lens and the failure is almost embarrassing in its clarity.

The people expected to use the tool were never made to understand why. They were never asked whether they wanted it. They were never taught what to do. They were handed the finished thing at the very last step and expected to already be standing there. And the technical team had the skill but not the capacity. They were able in every sense except the one that mattered, which was time. Nobody reinforced anything, because nobody had built a way to hear that it was breaking.

Here is the part of Hiatt’s work that people tend to skip. His careful sequence only helps an organization that is actually willing to run it. Do it as a checklist inside a place that has already decided, quietly, that the date matters more than the truth, and all you produce is paperwork. A folder full of readiness that was never real. The plan assumed nothing would go wrong, which is the one assumption a plan is never allowed to make.

So the honest question was never whether the organization finished its readiness steps. It was whether the organization could tell itself the truth about what it was not ready for.

· · ·

Nobody in my first-week story lacked ambition. Nobody lacked budget. They had the tool, they had the plan, they had the date on the calendar. What they never did was take the inventory.

That is not a niche failure. Deloitte surveyed more than three thousand leaders across two dozen countries this year and found that access to sanctioned AI tools had climbed from under 40 percent of workers to around 60 in a single year. The readiness of the people expected to use those tools did not climb with it. Only about one in five leaders said their workforce was highly prepared. The appetite scaled overnight. The readiness stayed exactly where it was.

Willingness is a feeling. Readiness is an inventory.

They never asked the team what it could hold and what it would have to put down to make space for a new way of working. They never asked the technical people what could actually be built in the time that existed, on the systems that actually ran. They mistook the wanting for the being ready. In a planning meeting the two are identical. The week after launch they stop being identical.

I would like to tell you I learned that by watching other people fail. Mostly I learned it by doing it myself. I have stood in front of a team that wanted a change so badly I could feel it in the room, and I have called that readiness, and I have been wrong. Wanting is loud. It fills the space. It is very easy to mistake for the quieter thing, which is an honest account of what you can carry right now and what you have to set down first.

· · ·

The organization in that story did what organizations do. It blamed the tool. It started looking for a better one.

The next tool will be better. It usually is. That was never the question.

They were buried in manual work. Whole processes that ran on memory and spreadsheets and the same few people staying late to hold it together. You know the kind of place. Everyone can see the system is running on effort, and no one has the time to fix the reason it has to.

We came in with new technology. And somewhere in those early discovery conversations, the project stopped feeling like a deployment and started feeling like play. We were not only turning manual work into automated work, the obvious win. We were using the tool in ways it was never built for. Functions meant for compliance reporting, bent into engines for analysis. Features designed to do one thing quietly doing three. I had used software to make work faster before. I had never watched a tool become something larger than its own manual, in real time, with the people who would use it sitting right there.

It worked. We finished in half the time a build like that usually takes. Everyone was happy. Everyone was using it. The business could do things it had never been able to do before. By every measure anyone in that room was tracking, it was a win. It was mine. I was proud of it.

I still am, mostly.

Six years later, I went back and looked at that implementation. And what I saw first was not the success. It was everything we left on the table. How much more it could have been. Not for the employees who used it every day. For the people those employees were there to serve.

Here is the thing I never did. At no point in that entire project did I stop and ask how any of it would land for the person the organization actually existed to support. We built the whole thing around the employee. Faster for them. Cleaner for them. Fewer late nights for them. All real, all good. And not once did we ask, just as hard or harder, what this software would mean for the person on the other end of that employee’s work.

That person was never in a discovery conversation. Never a line in a requirements document. Never the subject of a single decision we made.

We optimized for the organization. Not because anyone decided the organization mattered more. Because the organization was the only thing anyone had pointed at.

That is what took me six years to see. When no one says out loud who the work is for, the work aims itself. And it aims at the nearest target, which is almost always the organization’s own convenience. Not from bad intent. From silence. The direction was never set, so the default took over. The default is always us.

Not long ago, a sandwich chain called Jersey Mike’s passed Chick-fil-A in customer satisfaction, ending an eleven-year run at the top. Their founder, who bought the first shop at seventeen, gets asked constantly what the secret is. His answer has not changed in decades. At every meeting, in front of corporate staff and store owners alike, he names the same few things. Fresh bread. Clean store. And then: share your life with the customer.

That company later spent close to a hundred and eighty-five million dollars on technology and infrastructure. The technology did not set the direction. It inherited it. The aim was already fixed on the person across the counter, so when the tools arrived, they amplified the aim.

My tools arrived too. They inherited what I gave them. And what I gave them was an aim pointed at everything except the person we were there for.

The software was never the variable. It did exactly what we asked of it. The only variable was whether anyone had decided, and said out loud, who all of it was for.

A tool can only point where the organization is already pointed. Give it clarity and it multiplies the clarity. Give it a building full of capable people who have never named who they serve, and it multiplies that instead. It makes you faster at going wherever you were already going. Even when no one ever decided where that was.

The implementation succeeded. I am still proud of the speed.

But fast is not the same as aimed. And six years is a long time to learn the difference between a project that worked and a project that mattered.

Sources. Satisfaction ranking: American Customer Satisfaction Index, Restaurant and Food Delivery Study 2026 (released June 16, 2026), theacsi.com. Jersey Mike’s debuts at 84, ahead of Chick-fil-A at 83, ending an eleven-year run as the top quick-service brand. Technology investment and the “IT company” framing: QSR Magazine, “Culture Fuels Jersey Mike’s Rise to the Sandwich Elite.” “Share your life with the customer”: Peter Cancro, on the Jedburgh Podcast.

It was a roundtable at the Salesforce Connections conference. To my right, the architects. To my left, the marketing team. I sat in the middle, next to the moderator, and watched a room sort itself the way rooms do when nobody is paying attention. The architects had the quiet, careful posture of people who live in systems. The marketing folks leaned in, talked with their hands, finished each other’s thoughts. Every stereotype you hold about both groups was sitting at that table. I could not have staged it if I tried.

I’d like to say I noticed something was wrong. I didn’t, at first. The sides felt normal. They always do.

Then one of the marketing people started talking about the data she couldn’t reach. The information she needed to do her job was somewhere in the building. It just never arrived in a form she could use. She wasn’t angry about it. She was resigned. This was simply how it worked.

I looked to my right.

The architects’ faces told the whole story. They knew the answer. They had known it before she finished her sentence. And they were not going to say it, because the question had not been pointed at them. It had been said to the room in general, the way people complain about the weather.

So I pointed it at them.

I asked one of the architects how he would approach it. Not whether it was possible. How he would do it. I watched him decide whether to lean in.

He leaned in. He started describing how he’d reshape the data so it could actually be used, turning a pile of scattered records into something a person could build a message around. It wasn’t complicated for him. It was Tuesday.

I looked back at the marketing person.

Her eyes had changed. She had more questions. She had better questions. The thing she’d filed under impossible had become a conversation, and the conversation was happening in real time, across a table, between two people who had been sitting four feet apart the whole time.

Then the architect said the thing I haven’t stopped thinking about.

He told me he works at a Fortune 500 company. He has tools most people only read about. And then he said this: “I wish I could have more interactions with the marketing folks. The solutions I could deliver might be better than what I build from a static request that comes through my inbox.”

He was not describing a tooling gap. His company has every tool. He was describing the inch of air between two people who never talk to each other, and the way that inch quietly degrades everything built across it.

The request goes into an inbox. The answer comes back as a guess. And both people privately decide the other side just doesn’t get it.

Nobody is lying. Nobody is incompetent. The marketing team knew exactly what they needed. The architect could build almost anything. Put them in the same conversation for ninety seconds and you get something better than either of them would have made alone.

We proved it at that table. By accident.

But the part that stayed with me is this. The connection didn’t form on its own. Someone had to carry the question across the line. Left alone, that table stays two tables. The marketing person goes home still resigned. The architect goes back to his inbox, still building from guesses, still wishing.

Here is what makes it stubborn. The inbox is not a failure of effort. It is the channel both of them were handed. The architect answers tickets because tickets are what reach him. The marketing team writes tickets because a ticket is the only door they can find. Each one is doing exactly what the system was built to ask of them. And the system was never built to put them in the same room.

In most organizations, no one is responsible for that crossing. We hire for both sides of the table and quietly assume the conversation between them will happen on its own. It doesn’t.

The tools were never the bottleneck. The table had everything it needed. There was just a line down the middle of it, and everyone already knew which side was theirs.

It ran above the stations, a thin line you could reach without looking up. Pull it and a light came on and a sound went out and someone came walking. Pull it and leave it, and the line itself would stop. Thousands of dollars a minute, stopped, because one person at one station saw something that was not right.

I assumed, the first week, that pulling it was the thing you were never supposed to do. The nuclear option. The cord you get shown in training and then spend a career avoiding.

It was the opposite. Pulling it was the job.

The first time I watched someone pull it, I waited for the consequence. The consequence was that a team lead jogged over, looked at what the person was pointing at, and agreed with them. The defect did not travel down the line. The problem got solved at the station where it was seen, by the people standing closest to it, in the minute it appeared.

What I was watching, though I did not have the words for it then, was an organization that had decided in advance to believe the person at the station.

Not believe them in the abstract. Believe them enough to build the belief into the floor. Enough to wire a cord to it. Enough to lose the money.

Most organizations have a cord too. It is just not wired to anything.

You can raise your hand. You can say the thing in the meeting. You can write it in the survey, name it in the review, put it in the report that goes up. The cord is there. You are allowed to pull it.

And then nothing comes back.

No light. No sound. No one walking over. The thing you named travels up into the quiet and does not return, and you are left at your station holding a problem that is somehow still yours.

People are not slow. They learn this in one or two pulls. They learn that surfacing a problem costs them something and changes nothing, and they make the only rational decision left to them. They stop pulling. They let the defect move down the line, because moving it down the line is cheaper than naming it.

The meetings still happen. The surveys still go out. The reviews still run on schedule. And nothing true gets said inside any of them, because everyone has already learned what happens when you say a true thing.

Here is the part I missed for a long time, even after the line.

I thought trust was about whether the truth could travel up. Whether it was safe to pull the cord. That is half of it. The half almost everyone forgets is the second one.

The signal has to come back.

The cord worked because pulling it produced a response the person could see, in a form they recognized, at the station where they were standing. Not a policy change announced three levels up. Not a value printed on a wall. An answer, returned to the person who raised it, that proved the truth had landed and done something.

Closing that loop is what keeps the loop open. The first time the truth goes up and nothing comes back down, you have not just lost one problem. You have taught the most capable witness you have, the person closest to the actual work, to stop telling you what they see.

This is the first condition, and it is first for a reason. Everything else sits on top of it.

Can the organization tell the truth about itself.

Not whether people are kind to each other. Not whether the culture survey scores well. Whether what is actually happening can travel to the people who can act on it, and travel back, intact, fast enough to matter.

I think this is the condition the new tools expose first, because the new tools are built directly on top of it.

A system learns your organization from its records. From what got written down, reported, logged, and said out loud. If the real situation never made it into any of that, because the people who saw it had already learned to go quiet, then the tool does not uncover the truth you were missing. It inherits the version you preferred. Then it repeats that version back to you, confidently, at a scale and a speed you have never had before.

The dashboard makes the comfortable number look more true than ever.

You cannot automate your way to honesty. A tool will only ever be as truthful as its inputs, and the inputs are a trust problem. They always were. The technology just removed the years of lag that used to let you pretend otherwise.

So here is the question I am sitting with, and the one I would ask you to answer.

Think about the last time someone on your team named a real problem out loud. Not a safe one. A real one.

What came back to them?

Reply and tell me. I am collecting these across industries right now, from people who have nothing in common except the cord and the silence that follows it, and the pattern in the answers is getting hard to ignore.

Next time, the second condition. Direction. What happens when the truth can travel, but no one has decided where the organization is actually trying to go.

Not the full framework. Not five named dimensions with research attached to them. Just a sentence in a grad school paper that said, essentially: there is something that has to be true before any of this works.

I was reading Alan Hirsch’s The Forgotten Ways at the time. Hirsch was writing about what makes institutions thrive when their external conditions collapse. The ideas were sharp, practical, unusually honest for that genre.

But something kept pulling at me.

It took another twelve years to name what it was.

Since then, I have worked inside five radically different organizational environments.

A BMW assembly line during a global pandemic. Churches in Utah and New Jersey with nothing in common except their struggle. A higher education consulting practice. A university enrollment division in the middle of an AI transformation.

These contexts share nothing. Different tools. Different languages. Different stakes. Different political configurations entirely.

Every one of them was failing for the same reason.

Not the technology. Not the strategy. Not the wrong vendor or the wrong platform.

They were failing because they had never answered the upstream questions. The ones that determine whether anything downstream has a chance.

RAND says more than 80 percent of AI projects fail. MIT puts the number for generative AI pilots at 95 percent failing to reach production. Sixty-one percent of knowledge workers say their organization’s AI strategy is not aligned with what they actually do every day.

The standard interpretation is a technology problem.

I want to offer a different one.

The organizations failing at AI are not failing because they selected the wrong model or configured the wrong workflow.

They are failing because they started without answering the questions that would have told them what they actually needed.

That is not a technology gap.

That is a leadership one.

Twelve years after that grad school paper, I put a name on the pattern.

The Leadership Layer.

Not a methodology. Not a checklist. Not a before-you-start module in a project plan.

A set of organizational conditions that have to exist before any complex initiative, technology-driven or otherwise, has a real chance of succeeding.

I have seen them absent everywhere the implementations failed. I have seen them present everywhere they held.

There are five of them.

Trust. Whether the organization can tell the truth about what it is. Not the all-hands version. Not the slide deck version. The actual truth. Whether the people responsible for a new initiative believe it will survive contact with leadership. Trust is not a culture metric. It is an operational precondition.

Direction. Whether the work is connected to something worth moving toward. Not a goal with a deadline. Something with pull. The reason the initiative matters beyond the project plan. Direction is what separates organizations that implement and organizations that transform.

Readiness. Knowing what to hold and what to release before you start. Readiness is not excitement. It is not capacity on a spreadsheet. It is an honest accounting of what the organization is actually prepared to do, regardless of what the timeline says.

Authority. Whether decision-making is visible and interrogable. Whether the people closest to the problem can name what is blocking them without worrying about what happens next. Authority is not who is in charge. It is whether honest engagement is actually possible.

Ownership. Whether the behavior of the organization matches the message it is sending. Not the stated values. The actual behavior. What happens when the implementation hits the first hard moment and the team is watching to see what leadership does.

Five conditions.

I have never seen an organization that did not struggle with at least one of them.

I have never seen an AI initiative fail that did not have at least one of them missing.

Starting with this issue, Signal & Strategy is going deeper on each one.

Not as abstract principles. As specific organizational dynamics with real decisions attached to them. Moments where the presence or absence of a condition changed the outcome in a way that everyone in the room could feel but no one had language for.

Each issue will take one pillar and make it real.

Not so you can add it to a framework slide. So you can recognize it the next time you are inside an organization trying to do something that has not worked yet.

Five issues. Five conditions.

The pattern has been there the whole time.

Next issue: Trust. What it actually looks like when an organization cannot tell the truth about itself, and what changes when someone finally makes it safe to.

That’s not a comfortable sentence to write. But it’s the accurate one, and accuracy is where this series has always tried to land.

I had submitted a proposal. Not a short one. A comprehensive argument for how the organization should approach automation and AI, what needed to happen before implementation began, how to make sure we were building on ground that could hold it. I had been carrying the core of that idea for years across different contexts. This was the version that finally had a home.

My supervisor read it. He was a twenty-year friend before he was my supervisor, which matters here. He doesn’t say things to make people feel better. He says things because he means them.

He told me: right idea. Wrong time.

I heard him. I just didn’t believe him.

There’s a version of leadership literature that would treat this moment as a failure of organizational communication. The message didn’t land. The feedback loop was broken. Trust infrastructure was absent.

I don’t think that’s what happened.

Andy told me the truth clearly. He told me more than once. What was broken wasn’t the message. It was my ability to receive it.

I had confused “not yet” with “no.” And I had confused the absence of visible progress with the absence of progress.

While I was waiting for approval, the organization was moving. Not on my timeline. Not in ways I could see from where I was standing. But the clarity I had put into that proposal, the specific articulation of the problem and what had to happen before any solution had a chance, had started conversations I wasn’t part of. Work got funded that would have made my proposal easier to execute. Connections were made between departments that my proposal had named as essential. The ground was being prepared.

I didn’t know any of this.

I found out in a single hour, in a conversation with a senior leader who was leaving the institution, who thought to close the loop on her way out. She told me what I hadn’t known. Not because anyone had been withholding it. Because the organization wasn’t built to tell me. And because I had spent the intervening months assuming the silence meant nothing was happening, when the silence was actually a function of distance, not absence.

A few days ago I wrote about Trust as the first pillar of the Leadership Layer.

The BMW story. Any worker could stop production. The expectation was that the person closest to the problem had a mechanism to surface it before the damage was done. Trust, in that frame, runs upward. The organization has to be built so that honest information can move from the people doing the work to the people making decisions.

That frame is real. I believe it.

But Trust runs in both directions.

An organization also has to be built so that honest information can move back down to the person who surfaced it. And the person who received honest information has to be built to receive it, not just to hear it.

I was not built to receive what Andy was telling me. I had been carrying the idea for too long. I had invested too much in the outcome being a specific kind of yes, at a specific kind of speed. I could not see the value in a sentence that gave me neither.

“Right idea. Wrong time.”

That sentence was a gift. I treated it like a delay.

Here’s what I’ve come to understand about the proposal I submitted.

The ask was approval to begin conversations. Not to launch five projects. Not to commit a budget. To begin conversations. To announce the initiative, engage with leaders across the organization, understand what was already happening, start the process of building shared clarity about where we were and where we needed to go.

What I didn’t understand when I wrote that ask is that submitting the proposal was already the first conversation. The clarity I had put into it, the articulation of the problem, the argument for why this mattered now, the acknowledgment of what would make it fail before it started, that had been enough to start things moving that I couldn’t see.

The first conversation in an organization isn’t the one where you present the idea and wait for a verdict. It’s the one where you make the problem clear enough that other people can hold it when you’re not in the room. If you’ve done that, you’ve already started something. You may not know when or how it lands. You may wait longer than you think is reasonable. You may interpret the silence as nothing happening when something is already moving underneath it.

The proposal became an AI strategy. Got funding. Launched capabilities neither I nor anyone else had fully anticipated when the original document was written. It became something larger than what I had submitted, because when the problem is named clearly enough, the organization can act on it in directions the person who named it never imagined.

That is not how I expected innovation to work.

I expected my idea to get launched. What actually happened is that my idea launched conversations. The conversations launched work. The work launched something that made my original idea look modest by comparison.

Innovation isn’t your idea getting launched. It’s your idea launching something greater than it could have been on its own.

This is the last issue in this series.

I started it with a proposal sitting on a drive somewhere, wondering if it had mattered. I wrote five issues trying to work out what I had learned from the experience of building it, submitting it, watching it apparently disappear, and finding out years later what it had actually started.

Issue 1 was about the leadership problem underneath the technology problem. Issue 2 was about what changes when you stop maintaining data and start using it. Issue 3 was about what fails before a project even launches. Issue 4 was about what happens when every team finds their own solution. This issue is about what happens when you submit the proposal, hear “not yet,” and have to decide whether you believe the person who said it.

I didn’t believe it. The proposal worked anyway. I’d like to think I would handle it differently now. I’m not entirely sure I would.

The Leadership Layer is slow work. It asks you to build the conditions before you build the capability. It asks you to have the first conversation before you ask for the first approval. And sometimes it asks you to trust that the conversation has already started something, even when you can’t see it moving.

I’m still learning that last part.

What has someone told you about timing or readiness that you resisted believing? What did it turn out they were right about?

This is the final issue of “AI Isn’t the Hard Part.” The series continues in a new direction beginning with the next issue. If these five issues have been useful, forward this one to someone carrying a proposal they’re not sure anyone is paying attention to. They might need to hear what I needed to hear.

Signal & Strategy is a biweekly newsletter at the intersection of leadership, AI, and organizational clarity. This is the first issue of the AI Isn’t the Hard Part Series, five issues on the human side of organizational change. Subscribe to my substack here. Reply anytime. I read every response.

I was meeting with the provost. Two attempts had already been made at solving the same forecasting challenge for our growing extension site programs. Both had failed. Administration was frustrated. Nobody wanted the responsibility anymore. The problem had become radioactive.

I made the promise anyway.

The people in that room were scared for me. They had watched others make promises there before. They knew what happened when those promises didn’t land. They couldn’t see what I could see, and so they braced for impact.

Two weeks later, I delivered.

Not just a forecast for the extension sites. A forecast that also solved for online enrollment, a part of the institution nobody had thought to connect to this problem. By solving for both, we moved from 80% planned to 97%, with flags for individuals needing exemptions months before those decisions had to be made. Reactive became proactive. A week of analysis. Today I could do it in minutes.

But here’s the thing I keep coming back to.

The technology didn’t create that outcome. The visibility did.

Two separate teams had tried to solve the extension site problem before I walked into that room. Neither of them knew the online enrollment team was facing the same problem. Nobody had looked across both at once. Nobody was positioned to.

That’s not a data failure. That’s a coordination failure.

And it’s quieter than most leaders expect. Nobody sounds an alarm when teams are solving problems independently. Every department can point to effort. Every initiative looks like progress from inside the room where it’s happening. The fragmentation only becomes visible from above, and only to someone who happens to be looking across the whole.

Most organizations don’t build that vantage point on purpose. They assume it will emerge. It doesn’t.

Here’s what I’ve watched happen as AI tools have become accessible to every corner of an organization.

Finance doesn’t get the new tools. Sales does. Support does. The teams with visible, external-facing workflows get the investment, the pilots, the attention. Finance is buried in operations, carrying regulatory constraints, keeping the engine running. Nobody thinks to ask what they might build if given the space.

This is a mistake.

Some of the most boundary-pushing thinking I’ve seen has come from finance departments. Working inside tight regulatory constraints develops a discipline of thought that most teams never build. When those thinkers get access to the right tools, they don’t just experiment. They build things that hold up.

But they rarely get the space. And without coordination, nobody notices they’re being left out of a conversation that will eventually affect them directly.

Meanwhile, the teams that do get access are each finding their own solutions. Different platforms. Different workflows. Different assumptions about what the data means and who owns it. Each one a local win. Together, a coordination problem nobody named until it was expensive to fix.

The instinct when leaders recognize this problem is to form a committee.

I understand why. A cross-functional team feels like the right structural answer to a crossfunctional problem. But committees built around new technology tend to produce a specific kind of friction. Not the productive kind. The kind that comes from people who aren’t starting from the same understanding of what’s even possible.

You can’t coordinate what people can’t yet imagine. And most teams, buried in their day-today, haven’t had the space to imagine it.

The answer isn’t a committee. It isn’t centralized control either. Locking AI adoption behind an approval process kills the momentum that makes any of this worth doing.

The answer is coordinated autonomy.

Teams move with real independence. They research tools, run pilots, build workflows specific to their context. But they move inside a shared architecture. Agreed-upon principles around data ownership, integration standards, and organizational visibility. Not a permission slip. A set of guardrails that let everyone move fast without pulling in different directions.

Coordinated autonomy means the finance team can explore what’s possible without waiting for a committee to catch up. It means the extension site problem and the online enrollment problem get solved together instead of twice. It means someone is always positioned to see across the room.

That forecast I delivered in a week, I could run today in minutes. The technology changed. The requirement didn’t.

Someone still has to be in the room who can see that two separate problems are actually one. Someone still has to be willing to make the promise when the room goes quiet. And the organization still has to be built in a way that makes that kind of visibility possible.

AI doesn’t create that. Leadership does.

What does coordination look like in your organization right now? Is anyone positioned to see across the silos, or is each team solving its own version of the same problem? I’d genuinely like to know.

We had just run our first online ad for a community event at the church. The engagement was strong. Comments, shares, people saying they’d be there. I read every one of them. I was convinced we were about to have the biggest turnout we’d ever seen.

I drove to the store. I filled the cart. I went back and filled it again.

One hundred people came.

For months after that event, I opened my freezer and stared at the evidence of my miscalculation. Hotdog after hotdog, stacked in neat rows, mocking me every time I reached for something else. I learned things about hotdogs I never expected to know. If you score them before they hit the pan and butter baste them while they cook, the surface area opens up and catches the brown butter. They’re better than they have any right to be. I got creative out of necessity.

What I didn’t do, at least not right away, was ask the right question.

The failure wasn’t the ad. The ad worked. People saw it. They engaged with it. They told me they were coming.

The failure was that I never talked to the people who had hosted events in that community before I bought a single hotdog. If I had, they would have told me something the engagement metrics never could.

People in that community weren’t going to walk into a church building. Not for a casual event. Not yet. The barrier wasn’t awareness. It wasn’t interest. It was the building itself, and the history and discomfort that came with it for a lot of people in that neighborhood.

I measured a real signal. I just measured the wrong one.

Online engagement told me people knew about the event. It told me nothing about whether they were ready to show up.

I see this exact failure pattern inside technology transformations every day.

A leadership team sees strong pilot results. A vendor demo lands well. An internal survey shows employees are excited about AI. The signal looks good. The decision gets made. The project launches.

And then somewhere in the middle of implementation, something surfaces that everyone closest to the work already knew. A data problem that makes the tool unusable. A workflow assumption that doesn’t match reality. A team that was never actually ready for the change, despite what the survey said.

The launch was the problem. Not the execution.

The foundational conversations never happened. The people who knew what leadership didn’t were never asked. The map felt complete because nobody had seen the edges yet.

This is what I’ve come to understand about why change fails before it starts.

It’s not urgency exactly, though urgency is always present. It’s not overconfidence, though that plays a role. It’s something closer to what Donald Rumsfeld once described: not the things we know we don’t know, but the things we don’t know we don’t know. The unknown unknowns. Leaders don’t skip the foundational conversations because they’re careless. They skip them because nothing in their frame tells them the conversation is missing.

I didn’t know to ask about the building. I had no reason to doubt the engagement numbers. My map felt complete. It wasn’t.

The people doing the work almost always hold the knowledge that leadership doesn’t have. But getting to that knowledge isn’t as simple as sending a survey or scheduling a meeting. The people closest to the work are optimized for execution. That’s what the job trained them to do. Shifting from doing to reflecting, even temporarily, isn’t natural for everyone. It requires the leader to create the conditions for a different kind of thinking. Not just ask for input. Build the space where honest input becomes possible.

Most leaders don’t do this. Not because they don’t care. Because it feels slow, and moving feels like leading.

Before you launch your next AI initiative, I want to offer five questions. Not a checklist. Not a framework. Five conversations that change what you build before you build it.

Who already knows what I don’t, and have I actually talked to them? Every organization

has people whose daily work holds answers that leadership hasn’t thought to ask about. Find them before the project plan is written, not after the first obstacle surfaces.

What would stop the people most affected from fully participating, and have I asked them directly? Engagement metrics measure interest. They don’t measure barriers. The people in my community were interested. The building stopped them. Ask directly what would get in the way. You will hear things no survey captures.

Am I measuring a real signal or a convenient one? Online engagement felt like proof. It was activity, not commitment. Before you treat a data point as a green light, ask what it actually measures and what it doesn’t.

Have I created the conditions for honest input, or just the appearance of it? A meeting where people can speak freely looks identical on the calendar to a meeting where they can’t. The difference is in how the leader shows up, what questions get asked, and whether the people in the room believe their honesty will cost them something. Build the space intentionally.

What will I do differently when the first assumption turns out to be wrong? Not if. When. The leaders who navigate change well aren’t the ones who get everything right at launch. They’re the ones who build adaptation into the plan before they need it.

I eventually hosted a different event. One designed around the actual barrier, something that gave people in the community a reason to engage with the building on their own terms, at their own pace. It worked.

And I learned that a scored, butter-basted hotdog is better than anything I would have served that first night.

The freezer full of hotdogs wasn’t a monument to failure. It was evidence that I had moved fast without a complete map. Once I understood what I’d missed, I stopped trying to manufacture a different outcome from the same approach. I changed what I was building.

That’s what happens on the other side of a foundational conversation. You don’t just get better information. You build something different. Something that actually fits the people it’s meant to serve.

The technology was never the hard part. The conversation before it was.

What’s a moment when you realized a project was already in trouble before it launched? I’d

love to hear what you saw, and when you saw it?

The kind of week that shapes everything that comes after. The week where someone decides, quietly and without fanfare, what this job actually is.

Maria had been helping him get oriented. She knew the systems. She knew where the documentation lived and where it didn’t. She knew which vendors responded quickly and which ones you had to chase. She was the person you wanted in your corner on week one.

At some point that week, Maria sent him a Teams message.

“I’m going to need you to start entering users into the platform. I’ll send you the spreadsheet.”

The spreadsheet had names. Dozens of them. Each one needed a username. A temporary password. A follow-up email so they could reset their credentials and actually get in.

Akin got to work.

This was not busywork in the abstract sense. We were implementing a fraud detection platform for our application process. Real stakes. A legitimate organizational need. Leadership had approved it. The vendor was ready. The logic was sound.

The only problem was the implementation required every user to be manually onboarded onto the platform. And we weren’t sophisticated enough at the time to automate it.

So for two, maybe three days, during the week that should have been spent learning our data architecture, jumping on real projects, building the foundation of his role, Akin typed.

Name by name. Username by username. Temporary password by temporary password.

Maria checked his work. Answered his questions. Made sure nothing fell through the cracks. Two capable people, doing exactly what the situation required of them, in a way that the situation should never have required.

I’ve thought about that week a lot since then.

What stayed with me was the cost that never showed up in the project report.

We didn’t lose a deliverable. We lost a week of onboarding. We lost the time Akin should have spent understanding how our data actually works, which systems talk to each other, where the bodies are buried in any new tech environment. That week of foundation-building got quietly replaced by data entry, and nobody called it a loss because the project shipped on time.

That’s the part that’s easy to miss. The loss isn’t always visible. Sometimes it looks like a successful implementation.

Here’s what I’ve come to believe: the shift from data entry to data validation is not primarily a technology story. It’s a leadership story.

The tools to automate that onboarding process existed. They exist now, and they existed then. We just hadn’t invested the time to set them up. Someone, at some point in the planning process, had to decide that manual entry was acceptable. That decision probably took less than thirty seconds and was never revisited.

That’s where the real work is.

Not in the AI platform. Not in the automation tool. In the moment before the project starts, when a leader asks: what are we actually asking our people to do here? What does implementation cost them? And is there a better way?

Those questions don’t require a technology background. They require the willingness to look past the deliverable and see the people delivering it.

We’re in a moment right now where every organization is somewhere on this curve. Some are automating aggressively. Some are watching and waiting. Most are doing both at once, in different departments, with no coordinated strategy.

But almost everyone has an Akin somewhere. Someone whose best hours are going to manual processes that a well-configured system could handle. Someone who was hired for their judgment, their creativity, their ability to see around corners, and who is spending their Tuesday typing usernames into a spreadsheet.

Data entry is not their job. Data validation is.

The question is whether the leaders in the room know the difference. And whether they’re asking.

Today we work to maintain the data.

Tomorrow the data works for us.

That shift doesn’t happen automatically. It happens when leaders decide it will.

Signal & Strategy is a newsletter about what AI actually requires of leaders. If this landed for you, forward it to someone who needs to hear it. New issues every two weeks.

If you’d rather have this in your inbox, subscribe at joshsgrace.substack.com

My first week at a new organization, I found myself in a meeting I hadn’t expected.

It wasn’t an orientation. It wasn’t a welcome lunch. It was a post-mortem on a failed system implementation. A technology the organization had invested in, championed at the leadership level, and rolled out to the people who were supposed to use it every day. And it had landed badly.

Not because the technology didn’t work. It worked fine. It had been stood up and shipped. What it hadn’t been was built for the people who were actually going to use it. The end users, the ones whose daily work this system was supposed to improve, had been handed something incomplete. Something that didn’t fit how they worked or what they needed to get done.

I sat in that meeting listening to a capable team try to figure out what went wrong. They talked about the rollout timeline. They talked about training. They talked about whether the configuration had been right.

Nobody talked about what the system was actually supposed to change for the people using it.

Nobody talked about what had been asked of those people, or what they had needed to succeed, or whether anyone had answered those questions before the project launched. The technology had been the priority. The people had been an afterthought.

The technology worked. What was missing was a bridge between the system and the people who needed to use it.

That meeting stayed with me. Not because it was unusual, but because it wasn’t.

The Story We Tell About AI

Right now, most organizations are in the middle of a story about AI that goes something like this:

The technology is here. We need to adopt it. The people who resist it are the obstacle.

It’s a clean story. It’s also wrong.

Not because people don’t resist change. They do. Not because technology doesn’t create real value. It does. But because the framing puts the technology at the center and asks leadership to orbit around it. When leadership orbits technology, the questions that actually need to be answered never get asked.

Questions like:

• What are we trying to become?

• What does success look like for the people closest to this work?

• What decisions will now happen faster, and are we ready for that?

• What clarity do we need to give people so they can lead themselves through this?

Those aren’t technology questions. They’re leadership questions. And AI doesn’t answer them. AI amplifies whatever’s already true about how an organization is led.

If there’s clarity, AI accelerates it.

If there’s confusion, AI accelerates that too.

What Overwhelm Actually Looks Like

I want to tell you about a different kind of person than the one we usually talk about in conversations like this.

Not the early adopter. Not the resister. The person I want to talk about is buried.

They’re not anti-technology. They’re not afraid of the future. They are three systems deep, toggling between screens, manually transferring information from one place to another because the systems don’t talk to each other. They’re answering the same question for six different people because there’s no shared source of truth. They’re spending their sharpest hours of the day on work that is, at its core, maintenance.

Ask this person what they think about AI, and they’ll tell you they don’t have time to think about AI.

That’s not cynicism. That’s a description of a real organizational condition, and it’s one that no technology rollout addresses on its own.

When people are buried in the work of maintaining systems, they can’t imagine a different way of working. They can’t envision transformation because they can’t see over the top of today.

That is a leadership problem.

The leader’s job, before the tools, before the strategy deck, before the vendor selection, is to help the people closest to the work see a different horizon. To name what’s coming. To explain what it means for them. To answer the questions people are afraid to ask out loud.

AI doesn’t give people that horizon. Leaders do.

Why This Matters More Now

Here’s what changes with AI: speed.

Organizations have always had to manage change. The difference with AI-driven change is the pace at which decisions compound. Faster tools mean faster cycles. Faster cycles mean faster consequences, for good decisions and bad ones.

In that environment, the leaders who will matter most aren’t the ones who know the most about the tools. They’re the ones who can operate with enough clarity, about purpose, about direction, about what they value and why, that their organizations can move quickly without losing coherence.

That’s not a prediction about the future. It’s a description of what’s already happening in organizations that are ahead of this curve.

AI doesn’t replace leadership. It proves it.

The leaders who have done the work of building clarity, who have answered the hard questions about direction, culture, and what they’re actually asking of their people, those leaders are finding that AI gives them leverage. Their organizations can move.

The leaders who haven’t done that work are finding that AI gives their confusion leverage instead.

One Question Worth Sitting With

Before your next technology initiative, before the next rollout, the next pitch, the next “we need to start using AI” conversation, sit with this question:

What would the people most affected by this change need to believe, understand, and feel capable of before they could genuinely get behind it?

Not: what features will we train them on.

Not: what’s the go-live date.

What would they need to believe? Understand? Feel capable of?

If you can’t answer that clearly, the project isn’t ready, regardless of how good the technology is.

---

Signal & Strategy is a biweekly newsletter at the intersection of leadership, AI, and organizational clarity. This is the first issue of the AI Isn’t the Hard Part Series, five issues on the human side of organizational change. If someone forwarded this to you and it resonated, you can subscribe. Reply anytime. I read every response.

Coming up in this series:

Issue 2: Data entry is not your job. Data validation is.

Issue 3: Why change fails before it starts.

Issue 4: The danger of letting every department find its own AI solution.

Issue 5: What I asked my leadership for, and why it was really a question about clarity.

Josh Grace writes Signal & Strategy, a newsletter on leadership and AI strategy. New issues every two weeks.

Follow the conversation on LinkedIn: linkedin.com/in/josh-s-grace

What is less visible is whether their internal structure can support it.

In recent conversations with senior leaders, I have noticed a consistent pattern. The debate centers on tools. Which platform to enable. Which embedded AI feature to activate. Which vendor roadmap to align with.

These are important decisions.

They are not strategic ones.

The deeper question is whether the organization has established the conditions under which AI can create meaningful leverage.

AI does not replace leadership. It reveals whether leadership has produced structural coherence.

Structural coherence means four things:

1. Goals are explicit and shared.

2. Metrics are defined consistently across functions.

3. Data is accessible beyond the boundaries of a single application.

4. Decision rights are clear.

Without these conditions, AI accelerates fragmentation rather than performance.

The Embedded AI Dilemma

Many enterprise platforms now include embedded AI capabilities. Summaries, predictions, automated recommendations.

These features are useful.

However, when intelligence is confined within vendor systems, organizations risk trading capability for convenience.

If AI operates only within individual applications, insight becomes siloed. Leaders consume outputs without examining assumptions. Cross-functional interpretation becomes more difficult, not less.

Data accessibility is a strategic alternative.

When underlying data structures are interoperable and intentionally governed, AI becomes adaptable. Leaders can compose intelligence across systems rather than inherit it from a single vendor’s architecture.

The distinction is subtle but consequential.

Embedded AI optimizes tasks. Accessible data enables strategy.

Leadership in an Agentic Environment

As systems gain more autonomy, leadership shifts.

The central responsibility is no longer decision volume. It is decision clarity.

Agentic systems amplify direction. They do not determine it.

If objectives are ambiguous, automation compounds ambiguity. If definitions are inconsistent, analysis scales disagreement.

I have observed teams spend considerable time debating dashboards, not because calculations were flawed, but because language was misaligned. AI does not resolve semantic disagreement. It operationalizes it.

In this environment, transparency becomes a leadership function. Assumptions must be visible. Definitions must be documented. Outcomes must be prioritized deliberately.

Efficiency is not produced by technology alone. It emerges from alignment.

The organizations that will derive durable advantage from AI will not be those that adopt the most features.

They will be those that invest in structural coherence before accelerating automation.

The question for senior leaders is not whether to deploy AI.

It is whether the organization’s strategy, data architecture, and governance are prepared to withstand the exposure AI creates.

As AI becomes more embedded in your systems, what is it revealing about the coherence of your leadership structure?

Josh Grace writes Signal & Strategy, a newsletter on leadership and AI strategy. New issues every two weeks.

Follow the conversation on LinkedIn: linkedin.com/in/josh-s-grace