The Cost of Moving Faster in the Wrong Direction

Speed is an amplifier

Faster execution feels like progress because motion is visible. Reports arrive sooner. Drafts multiply. Work moves through a queue without waiting. Yet speed has no independent value. It creates value only when the underlying direction, decision, and process are sound. When they are not, acceleration makes the error travel farther before anyone has time to question it.

This has always been true of automation, but AI raises the stakes. A conventional automation repeats a defined rule. A generative system can produce varied outputs, infer patterns, and appear persuasive while doing so. That flexibility expands the number of tasks it can touch. It also makes weak assumptions harder to notice because the result may look polished and reasonable.

The leadership problem is not how to slow the organization down. It is how to distinguish useful speed from indiscriminate speed. That requires clarity about the destination, the constraints that matter, and the signals that reveal whether the organization is learning or merely producing more activity.

The blast radius grows with speed and scale

A failure at human pace is often visible before it spreads. A failure at machine pace can become an enterprise event. The best-known examples predate today's generative AI, but the operational lesson is directly relevant: automated systems magnify both good controls and missing controls.

In an enforcement action involving Knight Capital, the U.S. Securities and Exchange Commission described how a deployment failure caused an automated system to send millions of erroneous orders while attempting to fill 212 customer orders. In about 45 minutes, the company lost more than $460 million. The SEC identified weaknesses in testing, deployment, financial controls, incident response, and the handling of warning messages.

Knight Capital was an automated-trading failure, not a generative AI case. It belongs in this discussion because the failure equation is the same. A direction or control error is multiplied by execution speed and operating scale. As AI systems gain permission to act across tools and workflows, staged release, monitored limits, and a reliable stop mechanism become business necessities rather than technical preferences.

Automation makes a rule systematic

Every workflow contains rules, including rules no one has written down. A sales process assumes which opportunities deserve attention. A staffing model assumes what good performance looks like. A forecasting process assumes that historical categories still describe the future. When AI enters the workflow, it does not arrive above those assumptions. It operates through them and often makes them more consistent.

Consistency is beneficial when the rule is legitimate and the data reflects the real decision. It can become harmful when the rule is biased, incomplete, or pointed at the wrong target. The U.S. Equal Employment Opportunity Commission alleged that iTutorGroup's programmed screening software automatically rejected female applicants at age 55 or older and male applicants at age 60 or older. The case, which involved more than 200 applicants, ended in a settlement with payment and corrective requirements.

A settlement is not a trial finding, and one case does not describe every automated hiring system. It does show why removing a person from a step does not remove judgment from the system. Someone still chose the rule, data, threshold, and response. Automation can make that choice easier to repeat and harder for an affected person to see or challenge.

Capability has a jagged edge

Organizations often talk about AI capability as though it rises evenly. In practice, performance can be excellent on one task and unreliable on a nearby task that appears equally difficult. Research with consultants described this as a jagged technological frontier. Participants working on tasks inside that frontier completed more work, moved faster, and produced higher-quality results. On a task outside it, people using AI were less likely to reach the correct answer.

That finding changes the meaning of rapid deployment. A team cannot assume that success in summarization proves readiness for financial analysis, that strong drafting proves reliable policy interpretation, or that a convincing explanation proves a correct conclusion. Each use case needs its own evidence. The closer a task gets to ambiguous context, hidden constraints, or consequential judgment, the less useful broad capability claims become.

The frontier also moves. Models improve, products change, source data shifts, and people adapt their behavior around the tool. A decision that was reasonable six months ago may need to be tested again. Speed without monitoring can lock yesterday's assumption into tomorrow's workflow.

Perceived speed can hide real delay

One of the most instructive warnings comes from a randomized study of experienced open-source developers working in mature codebases they knew well. With access to early-2025 AI tools, the participants took longer on the assigned tasks, even though they believed the tools had made them faster. The setting was narrow and should not be generalized to all software work, but the contrast between perception and measured time matters far beyond coding.

AI can make a task feel easier by reducing the discomfort of a blank page, producing a quick first answer, or creating visible progress. The correction, verification, integration, and exception work may arrive later and be distributed across other people. A manager sees a draft in minutes. A reviewer spends an hour tracing unsupported claims. A representative closes a case quickly. A supervisor handles the escalated customer two days later.

This is why local productivity is an incomplete measure. Leaders should follow the work across the full system. Did total cycle time improve? Did quality hold? Did rework move downstream? Did experienced people gain capacity, or did they become a cleanup layer for faster output upstream? The correct unit of improvement is the business outcome, not the moment where AI was used.

What this looks like inside a business

Imagine a distributor that wants faster weekly demand forecasts. Analysts currently spend two days assembling spreadsheets, so leadership adds an AI forecasting layer and reduces preparation to two hours. The first month looks successful. Reports are early, formatting is consistent, and leaders can review more scenarios.

The deeper system tells a different story. Product categories are maintained differently across branches. Promotional orders are not consistently separated from normal demand. Sales teams update opportunity stages to satisfy local reporting habits. The new system processes these inputs quickly and generates precise recommendations, but inventory decisions become less reliable because the uncertainty is hidden inside a cleaner output.

A direction-first approach begins with the decision the forecast must support, such as which inventory commitments can be made with acceptable risk. The business repairs definitions, shows confidence ranges, assigns ownership for exceptions, and tests recommendations against actual outcomes. AI may still accelerate the analysis. Now it is accelerating a process with clearer inputs, visible uncertainty, and an accountable decision owner.

Useful friction protects the outcome

Not every delay is waste. Representative testing, a second approval for consequential actions, an exception queue, a spending limit, or a short waiting period before release can be useful friction. These controls give the system a chance to reveal a problem before the problem reaches every customer, employee, or transaction.

The right control depends on consequence and reversibility. A low-risk internal draft may need only a quick human check. An automated action that affects hiring, pricing, safety, customer eligibility, money, or legal obligations needs stronger evidence, explicit authority, monitoring, appeal, and a dependable way to pause or roll back. A person should not be described as the final reviewer unless that person has the time, information, training, and authority to disagree.

NIST recommends testing before deployment and during operation, evaluating performance under conditions similar to real use, documenting limitations, gathering feedback, and assigning responsibility for systems that produce inconsistent outcomes. These practices are not a rejection of speed. They make useful speed sustainable.

Replace rollout velocity with learning velocity

A fast organization is not one that deploys the largest number of tools. It is one that shortens the distance between a decision and reliable learning. That usually means a bounded pilot, a comparison point, direct observation of the work, and a scheduled decision about whether to expand, redesign, pause, or stop.

The pilot should test the riskiest assumption, not the easiest demonstration. If value depends on employees trusting the output, test trust and override behavior. If value depends on accurate source retrieval, test difficult and incomplete cases. If a process affects customers differently, examine those differences. If the benefit is supposed to free experienced people for higher-value work, measure whether that time actually becomes available.

Before accelerating, leadership should be able to answer a few questions. What outcome are we trying to improve? Which metric could improve while that outcome becomes worse? Where can an error cause material harm? Who owns the final decision? How will we detect when rework moves somewhere else? What evidence will make us expand, and what evidence will make us stop?

AI can help an organization move with extraordinary speed. That is exactly why direction matters more now. Velocity compounds whatever the system contains: good judgment or weak assumptions, clear ownership or hidden ambiguity, useful learning or polished noise. The work of leadership is to decide what deserves to be multiplied.