In , an industrial engineer named Frank Gilbreth studied the movements of bricklayers. He measured the number of motions required to lay a single brick. He reduced these motions from eighteen to five.
The efficiency of the individual worker increased by 320 percent. However, the completion date of the building projects remained largely unchanged. The site became a graveyard of perfectly laid bricks that waited for mortar that had not yet arrived.
Efficiency at the local level (red bricks) creates piles of work that cannot be completed due to missing system components (mortar).
The speed of the bricklayer was not the speed of the building. The individual was faster, but the system remained slow.
The Dashboard Delusion
Tom sits in a windowless conference room at on a Tuesday. He watches a screen share from a software vendor. The account executive points to a graph showing seat adoption.
The graph shows that ninety-four percent of his engineers use the AI tool every day. This number represents a successful rollout in the eyes of the vendor. The vendor is happy because the licenses are being used. High usage suggests that the renewal of the contract is likely.
Tom looks at his second monitor. He views his own DORA metrics for the insurance platform he manages. The deployment frequency has not moved in . The cycle time remains stuck at 19 days.
His engineers are typing faster than they did last year. They are not shipping more software to the customers. The work is being created at a higher velocity, but the work is not reaching the end of the line.
The Volume of Friction
The account executive continues to speak about acceptance rates. He says that forty-two percent of the code in Tom’s repository is now generated by the AI. This metric measures the volume of suggestions that a developer accepts.
“
Acceptance is a measure of friction, not a measure of value. The vendor is compensated for the acceptance of these suggestions. They are not compensated for the success of the business.
It does not measure the quality of the logic. It does not measure the necessity of the code. We have built a category of purchase where the vendor’s success metric and the buyer’s success metric are different.
This is a structural flaw in the market. The vendor wants more seats and more activity. The buyer wants more features and fewer bugs. These two goals do not always overlap. Sometimes they move in opposite directions. A tool can make every individual keystroke faster and change nothing about the delivery date.
I watched a video buffer at 99 percent this morning. The progress bar suggested the task was nearly complete. The final one percent took longer than the first ninety-nine.
Delivery Progress
99%
The final 1% is where the actual shipping happens.
This is the nature of software delivery in a brownfield environment. The easy part is visible and fast. The difficult part is hidden and slow. AI tools focus on the easy part of the process. They focus on the writing of the characters.
The Bottleneck is the Queue
Writing the characters is rarely the bottleneck in a complex system. The bottleneck is the queue. The bottleneck is the review ritual. The bottleneck is the release window.
A developer writes a function in six seconds. The AI tool provides the logic for the database query. This developer submits a pull request to the repository. The pull request contains eighty lines of generated code.
A senior engineer must now review these eighty lines. The senior engineer is already busy with four other reviews. The code sits in the queue for . The speed of the initial typing has been lost to the wait.
The wait is the true cost of the process. The faster the developers type, the longer the queue becomes. The system becomes congested with code that has not been verified.
The Ghost of
Tom manages a legacy insurance platform. The codebase contains logic written in . Much of this code is undocumented and brittle. AI tools suggest modern syntax for ancient problems.
These suggestions often break the hidden dependencies within the system. The developer spends an hour debugging a suggestion that took one second to accept. The adoption graph records a successful interaction. The project timeline records a delay.
Nobody in the purchase chain is compensated for noticing this. The procurement department looks at the cost per seat. The engineering manager looks at the adoption rate. The vendor looks at the revenue.
Everyone is satisfied with the numbers on their own screens. The customer remains frustrated by the slow pace of updates. The customer does not care about the adoption rate of the tools.
Measuring Outcomes, Not Hours
A different approach is required for a real transformation. The focus must shift from the activity of the individual to the throughput of the team. This requires a measurement of the baseline.
You must know how fast you are shipping before you introduce a new tool. You must know the cycle time of a feature. You must know the frequency of your deployments. If these numbers do not move, the tool is a cost without a benefit.
This is why some organizations are changing how they partner with engineering firms. They are moving away from buying hours and moving toward buying outcomes.
operates on this principle of evidenced gains.
They place a two-person delivery pod directly inside a client’s existing team. They do not simply provide developers who use AI. They provide a senior engineer and an AI delivery architect who focus on the process.
The Scientific Approach
The AI delivery architect looks at the pipeline. They identify the approval rituals that serve no purpose. They remove the friction from the release window. They take a baseline in week one and compare it to week eight.
The engagement model is also different. It is a month-to-month partnership with no long-term lock-in. They commit to a productivity lift of at least fifteen percent within . If that lift is not delivered, they invoice nothing for the work.
This aligns the incentive of the partner with the goal of the business. The partner only gets paid if the team ships faster. The partner is not paid for the number of seats they occupy.
Facing the Throughput Chart
This model forces a confrontation with the truth. It requires the leadership team to look at the throughput chart instead of the adoption dashboard. It requires them to admit that typing is not the same as shipping.
Most companies are afraid of this confrontation. They prefer the comfort of the usage graph. The usage graph is always positive. The throughput chart is often disappointing.
The software development life cycle is a series of interconnected steps. When you accelerate one step, you often create a pileup at the next step. If you increase the amount of code being written, you must increase the capacity for testing.
You must increase the capacity for security reviews. You must increase the capacity for deployment. If you do not balance the system, you only create more waste.
“An engine is useless if the wheels are not connected to the drivetrain.”
AI tools are engines. An engine is useless if the wheels are not connected to the drivetrain. Many engineering teams have powerful engines that are spinning in the air. The engine makes a lot of noise. It consumes a lot of fuel. The car does not move forward. The vendor sells the engine. They do not sell the movement of the car.
The Cost of the Ritual
Tom hears himself say “this is great” during the renewal call. He hates the sound of his own voice. He knows that he is participating in a ritual. He is confirming that the budget was well spent.
He is protecting his own decision to buy the licenses. He is not solving the problem of the 19-day cycle time. He is simply agreeing to pay for another year of activity.
The cost of this ritual is high. It drains the energy of the engineering team. Developers know when they are being measured on the wrong things. They know when their “acceptance rate” is being used to justify a corporate strategy.
They feel the friction of the review queue. They feel the frustration of the broken dependencies. They want to ship software, not generate suggestions.
The Distance Traveled
True productivity comes from the redesign of the process. It comes from the removal of the bottlenecks. It comes from the alignment of incentives between the buyer and the seller. If you want your team to ship faster, you must pay for shipping.
You must not pay for the act of being in the seat. You must not pay for the number of times a developer clicks a button. The graveyard of perfectly laid bricks is a warning. It is easy to optimize the individual motion. It is difficult to optimize the completed building.
The building requires the mortar, the frame, and the labor. It requires a vision of the finished structure. It requires an understanding of how the parts become a whole.
Tom closes the meeting. The screen share ends. He looks at his deployment frequency chart one last time. It is still flat. It is the only number that matters to the customers who use the insurance platform.
He decides to look for a partner who will measure the same chart. He decides to stop paying for the heat of the engine and start paying for the distance traveled.
The transformation of an engineering department is not a software update. It is a structural change. It requires a baseline and a commitment to the result. It requires a willingness to stop doing the things that do not work.
It requires a partner who is willing to walk away if they cannot provide a lift. This is how the 19-day cycle time becomes a 14-day cycle time. This is how the bricks become a building.