Every executive I sit down with wants to talk about AI tools. Which one is fastest, which one benchmarks best, which one their competitor just adopted. I keep steering the conversation somewhere they do not expect, and it starts with a question I learned at a logistics company in Indianapolis when I was twenty-three years old, driving a forklift and writing P H P in the same shift. The question has nothing to do with software. It has everything to do with why your AI investment is underperforming.
This started back in Indianapolis in twenty ten. I graduated college around twenty oh eight and moved to Indianapolis to work at a small logistics company as a programmer. If you have never worked at a small logistics company, let me paint the picture for you.
You are not just a developer. You are the developer who also runs second shift because someone has to, who drives the forklift because Marcus called in sick and the truck is already at the dock, who somehow knows the difference between L T L and F T L freight. That stands for Less Than Truckload and Full Truckload, for those of you who were lucky enough to never learn this. You learn what a bill of lading is, and why the driver just refused your dock appointment.
You learn way too much about logistics. Freight hauling, carrier rates, last-mile delivery windows, the entire unglamorous machinery that moves physical things from one place to another. And somewhere in there, between writing code and shrink-wrapping pallets, you develop an intuition about transportation that sticks with you permanently.
Fifteen years later, I am sitting across from Chief Technology Officers and Vice Presidents of Engineering who are trying to figure out which AI tool will transform their software development lifecycle, and I keep asking them the same question I learned on that loading dock. They do not expect a logistics question. But it is the right one.
In logistics, there is a deceptively simple question that determines everything. You are the last-mile carrier, you are running the final leg of the delivery, what type of transportation do you need? In Indianapolis, the answer depends on what you are carrying. If you are delivering food, probably a moped. If you are delivering freight, a fifty-three-foot semi. If you are delivering important legal documents across town in thirty minutes, maybe a Porsche.
The fastest form of ground transportation depends on the cargo. That part is obvious. It is the same logic executives use when they evaluate AI coding tools. What am I trying to carry? Code generation, test automation, documentation, refactoring? Pick the tool that matches the cargo. But that logic is incomplete. It also depends on where you are operating.
On my honeymoon, we rented a car in the south of France, in Marseille. The rental company handed us the keys to a Citroën C four Cactus. If you have not seen one, look it up. It is a real car. It is small, even by European standards, and it has these puffy air-bump panels on the doors like it is wearing a life jacket. The entire vehicle looks like it was designed by someone who expected you to hit things. This turned out to be prescient.
Marseille is one of the oldest cities in France, founded around six hundred B C by Greek sailors. The streets in the old city were laid out for people. Maybe donkeys. Maybe a horse if you were feeling ambitious. They were not designed for cars, and they were certainly not designed for the tiny, life-jacketed Citroën C four Cactus.
The streets curve without warning. They narrow until two walls are brushing your mirrors, they dead-end into staircases, and they angle at intersections that make no geometric sense. They emerged over centuries from foot traffic and stone walls and the simple human desire to get from the market to the harbor without walking uphill.
I drove the Cactus into a house. Not at speed, not dramatically. Just a gentle, inevitable crunch as I tried to navigate a corner that was not designed for anything with four wheels. The air bumps absorbed most of it. The house did not seem to notice.
Indianapolis is a grid. You can navigate it in a semi truck with your eyes half closed because the streets were designed with logic, with intention, with the assumption that vehicles would use them. Marseille's streets were designed a thousand years before the internal combustion engine existed.
Now, ask the last-mile question again. What is the fastest form of ground transportation in Marseille? It is not a fifty-three-foot semi. It is not a Porsche. The streets do not care how fast your vehicle can go because the streets were not designed for vehicles at all. You might honestly need a helicopter. Ground transportation, no matter how advanced or powerful or expensive, cannot overcome streets that were never built for it.
Look. Your organization is Marseille. The tool is a commodity. The organizational adoption expertise is not. And every executive conversation I have starts with the wrong question. Which tool is the Porsche? You are standing in Marseille, a city with streets laid out over centuries by people who never imagined your vehicle, and you are asking which car has the best zero-to-sixty.
I recently worked with a company where a change took thirty-four days from idea to production. The AI tool generated the code in about four hours. The remaining thirty-three days were approvals, reviews, environment provisioning, a security scan queue, and two rounds of manual Quality Assurance. They had optimized zero point five percent of their cycle time and left ninety-seven percent untouched.
And this is not just an engineering problem. Your marketing team's content approval chain has the same disease. A campaign that an AI tool can draft in an afternoon sits in brand review for eleven business days, then legal for another eight. Your customer service operation has a knowledge base that requires four sign-offs to update, so your agents are reading answers that were written before the product shipped its last three releases. Those are all streets. Different departments, different vehicles, same underlying constraint.
Right. I need to be careful here, because fixing your streets is not the same thing as tearing everything down. Some of your gates are load-bearing. If you are in healthcare, your clinical validation process exists because patients die when it fails. If you are in financial services, your Sarbanes Oxley controls exist because regulators will shut you down. If you are running critical infrastructure, your change management exists because the lights go off.
I have found that about forty percent of gates in a typical enterprise approval chain are genuinely load-bearing. They catch real problems. You redesign those to be faster, but you do not remove them. The other sixty percent are scar tissue. Someone got burned, someone added a gate, the incident was resolved five years ago, but the gate remained. Nobody remembers why it is there. Nobody wants to be the person who removes it. Knowing the difference is the entire job.
Here is the thing. You are measuring the wrong things. I sat in a meeting last quarter where a Vice President of Engineering told me his team had just finished a six-month tool evaluation. They surveyed two hundred engineers, ran satisfaction scores, measured developer experience across four platforms, and chose the one that scored highest on happiness.
I asked him one question. How long does it take a change to get from your best engineer's laptop to production? He did not know.
His developers were happy with the tool. They were also shipping once every three weeks because the deployment pipeline had eleven gates, two of them manual, one of which required a committee that met on alternating Tuesdays. The tool was generating code faster than the organization could absorb it, and nobody had noticed because they were measuring the wrong thing.
Developer happiness with a specific AI tool is measuring how much your team enjoys driving the Porsche around the parking lot while the streets remain impassable. And it is not the only measurement problem I see.
A Chief Technology Officer walks into a board meeting and presents D O R A metrics. That stands for Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery. The engineering team is proud. The numbers are up and to the right. The Chief Financial Officer looks at the slide and asks one question. What did that do to our margin?
Silence.
These metrics measure how well your engineering organization moves code. They do not measure whether that code generated revenue, reduced cost, improved customer retention, or expanded margin. If your AI adoption strategy is oriented around improving those technical scores, you are presenting engine R P M numbers to someone who asked about fuel economy.
The organizations that get AI adoption right do not report that they deployed forty percent more frequently. They report that they reduced time-to-market on new product features by sixty percent, which contributed to a twelve percent increase in net revenue retention. Or they say they cut their cost per feature by half, which improved gross margin by two hundred basis points. Same data, different framing. One of them gets your budget renewed. The other gets a polite nod and a follow-up email asking what it actually means for the business.
If your AI adoption goals are not framed around margin, revenue, cost reduction, or customer outcomes, you are building a dashboard that impresses engineers and confuses everyone else. That is not a technology problem. That is a leadership alignment problem.
Let me put a number on the cost of not fixing your streets. Because talking about it without a dollar amount is just philosophy. If your engineering organization has two hundred people at a fully loaded cost of two hundred thousand dollars per engineer per year, including salary, benefits, and overhead, you are spending forty million dollars a year on engineering. If sixty percent of your cycle time is wait time in approval queues and handoffs, and that sixty percent is conservative based on what I have measured, that is twenty-four million dollars a year in wages spent waiting.
Your competitor who fixed their streets six months ago is spending the same payroll on two to three times the output. That gap compounds every quarter. In eighteen months, the difference is not twenty percent or thirty percent, it is multiples. The compounding is the part that boards underestimate.
OK. I am not going to hand you a ninety-day roadmap because those are fiction. But I will give you the four questions I ask in every engagement, and they work whether you are a Chief Technology Officer, a Chief Operating Officer, a Chief Marketing Officer, or a Chief Product Officer. The streets problem does not belong to engineering. It belongs to whoever owns the process.
Zero. What is the business outcome? Before you map a single workflow, answer this. What business result is this AI investment supposed to produce? Not an engineering metric. Not developer satisfaction. A business outcome that your Chief Financial Officer can put in a board deck. Think revenue growth, margin improvement, cost reduction, or time-to-market compression. If you cannot articulate the business outcome in one sentence, you are not ready to evaluate tools, redesign streets, or spend a dollar. Everything that follows depends on this answer, because this is how you will know whether any of it worked.
First. Map the wait. Pick one workflow that matters to that business outcome. Map every step from idea to live. Mark which steps are work and which steps are waiting. In my experience the ratio is usually fifteen to twenty percent work and eighty to eighty-five percent waiting. If your number is better than that, congratulations. If it is not, you now know where the problem is.
Second. Sort your gates. For every approval, review, or handoff in that workflow, ask what this gate catches. If nobody can name a specific incident in the last two years, it is probably scar tissue. Could this gate be automated, parallelized, or reduced from a committee to a single owner? Most gates that were designed for a five-person review can be handled by one person with the right context and a clear escalation path.
Third. Ask who benefits from the current design. This is the uncomfortable one. Some gates exist because the people who operate them derive authority, headcount, or budget from their existence. Removing the gate threatens someone's role. That is not cynical, that is organizational physics. You cannot fix the streets without understanding who built their house on the current road. Those people need a role in the new design, not a pink slip.
That third question is the one most consultants skip. It is also the one that determines whether the redesign sticks. Because streets are not just process, they are people. The fifty-one-year-old engineer who has run that approval gate for fifteen years is not an obstacle. He is a subject matter expert who knows why the gate was built. Put him on the redesign team. He will tell you which gates are load-bearing faster than any audit will.
You are the last-mile carrier. You are trying to deliver working software, faster products, and better customer outcomes with AI tools that did not exist two years ago. What do your streets look like? Were they designed with intention, for the vehicles that will use them? Or were they designed a thousand years ago, by people who could not have imagined what you are trying to drive?
Because if you do not know the answer to that question, it does not matter what you buy. You are going to end up like me in Marseille, gently crunching into a four-hundred-year-old wall in the most advanced vehicle the rental company had to offer, wondering why the car did not save you.
Pick a partner who will help you fix your streets, not a vendor who will sell you a faster car for roads that cannot support it. What happens to your organization if you do not?