The Speed Assumption
Every AI vendor pitch contains a version of the same sentence: "do in minutes what used to take weeks." The sentence is often true. It is also incomplete in a way that is creating a generation of organizations that have learned to move fast without learning to move carefully.
The implicit assumption in "move fast" culture - borrowed from early software startup mythology and never seriously examined since - is that speed is net positive: that moving fast produces more learning, more iteration, and ultimately more value than moving carefully. Eric Ries formalized this as the Build-Measure-Learn loop. The lean startup movement made it a religion. It was correct for a specific context: early-stage products with small user bases, where the cost of a wrong move was a small number of users experiencing a bug, and the benefit of speed was surviving long enough to find product-market fit.
That context does not generalize. An early-stage product with 200 users operates in a completely different risk environment than a mid-stage product with 200,000 users, a security tool deployed on 8.5 million machines, or a regulated financial service touching real customer accounts. Scale does not change the desirability of speed. It changes the blast radius of a mistake.
AI amplifies capability uniformly. It makes legal drafting faster, code generation faster, customer communication faster, and deployment faster. It does not automatically identify which of these accelerations are safe and which are not. That judgment is still human work - and most organizations are not doing it systematically.
The question is not "how fast can we move?" The question is "what is the cost of being wrong at this speed, in this process, with this blast radius?"
What Fast Actually Costs - Three Cases
CrowdStrike, July 2024: Update Velocity Meets Global Infrastructure
On July 19, 2024, CrowdStrike deployed a content configuration update to its Falcon sensor - cybersecurity software running on Windows machines worldwide. The update contained a logic error in a channel file. Within hours, approximately 8.5 million Windows devices crashed into a boot loop, taking down Delta Air Lines (later reporting $500 million in losses), hospitals across the UK and US, banks, broadcasters, and emergency services in multiple countries.
The update was pushed to all production machines simultaneously - not through a staged rollout that would have exposed the error in a small cohort before it reached the full install base. A phased deployment to 1% of machines first, then 5%, then 25%, would have caught the error at a cost of a few thousand affected machines and a fast rollback, instead of a global infrastructure failure that required manual intervention on every affected device.
The lesson is not that CrowdStrike moved carelessly. It is that the update process - regardless of how carefully the content was reviewed - belonged in the Deliberate Slow lane because of its blast radius. A security tool deployed on millions of machines has a surface area large enough that even a small error has catastrophic reach. Staged rollout is not optional for processes with this blast radius. It is the entire safety architecture.
Air Canada, February 2024: AI-Generated Customer Commitments Create Legal Liability
A passenger named Jake Moffatt asked Air Canada's customer service chatbot about the airline's bereavement fare policy. The chatbot told him he could purchase a full-price ticket, travel for the bereavement, and then apply for a discounted bereavement fare retroactively. This policy did not exist. Air Canada's actual policy required the discounted fare to be booked before travel.
Moffatt traveled, paid full price, applied for the retroactive discount, and was refused. He sued. Air Canada argued in its defense that the chatbot was a "separate legal entity" for which the airline was not responsible, and that its website contained a disclaimer noting chatbot information might be incorrect.
The British Columbia Civil Resolution Tribunal rejected this argument. It ruled that Air Canada was responsible for all information provided on its website - including its chatbot - and ordered the airline to pay Moffatt the difference between the full fare and the bereavement rate, plus costs.
The ruling matters far beyond the dollar amount. It establishes that AI-generated customer communications carry the same legal weight as human-authored ones. Speed of generation is not a defense. Incorrect policy information sent to one customer costs a court case. The same information sent to 50,000 customers through an AI-powered support bot is a class action.
Knight Capital, August 2012: One Missed Verification Step Destroyed a Company
Knight Capital Group deployed a new automated trading system on August 1, 2012. During deployment, engineers enabled new code on seven of eight servers but failed to deactivate old code (the "Power Peg" algorithm) on the eighth. When trading opened, the eighth server began executing a loop of unintended orders at high speed.
In 45 minutes, Knight Capital executed approximately 4 million unintended transactions, accumulated a net long position of $3.5 billion in 154 stocks, and lost $440 million. The loss exceeded the firm's net capital. Knight Capital was acquired less than two months later.
The deployment checklist had been followed on seven of eight servers. One verification step was missed. The time between the error and the moment any human could intervene was shorter than a typical Slack response time. The firm no longer exists.
The SEC investigation concluded the firm lacked adequate controls to manage the risk of its own deployment speed. That sentence is the verdict on every team that moves fast without mapping its processes to their blast radius first.
The Velocity Risk Matrix
Jeff Bezos, in Amazon's 2015 annual shareholder letter, introduced the most useful single framework for thinking about decision speed: the distinction between one-way doors and two-way doors. A two-way door decision is reversible: if it turns out wrong, you walk back through and try again. A one-way door is not: once you go through it, returning is difficult, expensive, or impossible. His argument: large organizations make the mistake of treating all decisions like one-way doors - applying slow, committee-based review to everything, including things that are easily reversible and therefore should be fast.
The Velocity Risk Matrix extends this into an operational tool by adding a second axis - blast radius - and a compounding modifier. The result is a four-lane classification system for any process in your organization.
Axis 1 - Reversibility: If this process produces the wrong output, how hard is it to undo? Score from easily reversible (feature flag rollback in minutes) to permanently irreversible (legal communication sent, data deleted, financial transaction executed).
Axis 2 - Blast Radius: How many people are affected if it goes wrong? Score from contained (internal test environment, single user) to wide (all customers, regulators, partners, the public, or critical infrastructure simultaneously).
Lane 1 - Fast Lane (high reversibility + contained blast radius): Prototype, iterate freely, ship fast, learn, adjust. A feature behind a flag visible to 1% of users. An internal tool used by two people. A draft that never left a text editor.
Lane 2 - Staged Lane (high reversibility + wide blast radius): Canary deployment to 1%, then 5%, then 25%, then full. Feature flags that let you roll back in minutes if signals go wrong. Blue/green deployments. Staged email campaigns to list segments. Rollback procedure documented before the staged rollout begins.
Lane 3 - Checkpoint Lane (low reversibility + contained blast radius): Human review required before proceeding. Limited deployment until the review clears. One-way doors that affect few people - a contract with a single vendor, a configuration change on a non-critical internal system. The gate is a person, not a system.
Lane 4 - Deliberate Slow (low reversibility + wide blast radius): Legal review. Security audit. QA window. Support briefing. Rollback procedure documented even when rollback is hard. Every gate checked before proceeding. No exceptions based on deadline pressure. The cases above all belong here - and were not treated as if they did.
The Compounding Modifier: Ask one additional question for any process: if this produces harm, does the harm grow over time or resolve on its own? A security breach compounds: the longer it is undetected, the more data is exposed, the higher the regulatory fine, the wider the reputational damage. A legal error in a mass communication compounds: every new customer who receives it is another potential plaintiff. If harm compounds, drop the process one lane toward slower regardless of where it lands on the two primary axes.
The matrix is not a bureaucratic checklist. It is a forcing function for having the right conversation before moving. The question is never "should we move fast on this?" The question is "which lane does this process belong in, and are we operating in that lane right now?"
Managing Processes to Prevent Breakage
Knowing the classification system is necessary. It is not sufficient. The gap between knowing that a process is Deliberate Slow and actually treating it that way - especially under deadline pressure, resource constraints, and the organizational inertia of "we have always shipped it like this" - requires an operational layer that turns classification into real gates, real owners, and a real feedback mechanism.
What follows is a six-step process management system for building that layer. It is designed to be implemented incrementally. Start with your highest blast-radius processes: production deployments, customer communications, security configuration changes, compliance-triggering releases. Get those classified, gated, and owned first. The system compounds value as you extend it to the rest of your process register.
Step 1 - Build a process inventory. You cannot manage what you have not named. Document every recurring process that touches customers, data, security, or compliance: code deployments, configuration changes, data migrations, customer-facing communications, dependency updates, access control changes, third-party integrations, and regulatory submissions. One row per process type: name, frequency, who executes it, who is affected if it goes wrong, whether it is currently automated. This is your process register. Without it, lane classification is done informally and inconsistently - and the high-blast-radius processes are the ones most likely to slip through unclassified.
Step 2 - Score each process on the matrix. For each entry in the register, score reversibility (1 = feature flag rollback in minutes, 4 = permanently irreversible) and blast radius (1 = internal test environment or single user, 4 = all customers, regulators, or critical infrastructure simultaneously). Add the scores. 2-3 = Fast Lane, 4-5 = Staged Lane, 6-7 = Checkpoint Lane, 8 = Deliberate Slow. Apply the compounding modifier before finalizing: if the harm grows over time rather than resolving, drop one lane toward slower. A single number per process is the output. That number determines every gate that applies to it.
Step 3 - Define gates with specificity, not intent. "Legal review required" is not a gate. It is a wish. A gate is: the specific person or role who reviews, the specific question they are answering, the specific output that constitutes cleared, and the specific consequence if the process is pushed before the gate clears. "The company's designated legal reviewer has confirmed in writing that this communication does not create unintended contractual obligations, before it is sent to any customer" is a gate. Vague gate definitions fail under deadline pressure because they leave room for interpretation. Specific ones hold because they do not. Every process in the Checkpoint or Deliberate Slow lane needs this level of specificity in writing.
Step 4 - Assign owners, not just executors. Every process needs two named roles: the executor who runs it, and the owner who is accountable for ensuring the gate is respected and for reclassifying the process when its blast radius or reversibility changes. Without an owner, gates drift under deadline pressure. The executor is incentivized to ship on time. The owner's accountability is to the classification - and to the consequences that follow if a Deliberate Slow process is treated as Fast Lane because no one is watching the gate.
Step 5 - Run a post-incident reclassification loop. Every incident - a security event, an incorrect mass communication, a bug with significant blast radius, an emergency rollback, a customer complaint that reveals a process was not operating in its correct lane - is evidence about classification accuracy. After any incident, answer two questions: Was this process correctly classified before the incident occurred? If not, what is the correct classification now? Update the register. Update the gate definitions. The process management system is not a static document. It is a record of what the organization has learned about its own processes. It only compounds value if it is updated when evidence contradicts the current classification.
Step 6 - Make classification visible across the team. A process register that lives in one person's spreadsheet does not protect the organization. Lane classification belongs in the deployment runbook, the release checklist, the change management documentation, and the team onboarding materials. Every person who executes a process needs to know what lane it is in and what gates apply. When a process changes - new automation, higher customer volume, a new regulatory jurisdiction, a new integration dependency - classification review is part of the change, not an afterthought to be handled after the next incident forces the question.
The five sections that follow apply this system to the domains where the cost of misclassification is highest. Each section identifies the blast radius and reversibility profile specific to its domain, the most common failure mode when that domain is treated as a faster lane than it belongs in, and the specific gates that must hold when deadline pressure is at its peak. Legal exposure and customer-facing commitments are covered first because they compound fastest and are most frequently underestimated by product teams. Security and infrastructure follow, where the blast radius is widest. Undetected bugs and support unpreparedness close the domain coverage because they represent the failure mode that most directly damages user experience and organizational reputation over time - quietly, without a single dramatic incident to trigger the reclassification loop.
The Legal Fence
AI makes legal drafting genuinely faster. A terms of service update that previously took a lawyer two days to draft can now be drafted in thirty minutes with AI assistance and reviewed by a lawyer in half a day. This is a real productivity gain. The review step is not optional.
The process that must stay slow is not the drafting. It is the review before any legally binding language reaches customers or counterparties.
What belongs in the Deliberate Slow lane:
- Terms of service changes - any modification to terms that customers agree to
- Privacy policy updates - especially under GDPR, CCPA, and equivalent frameworks where notification and timing requirements are legally mandated
- Pricing changes with contractual implications
- Any customer communication that could be interpreted as a policy commitment (see: Air Canada)
- Vendor contracts, partnership agreements, SLAs
- Regulatory submissions and filings
The compounding modifier applies to all of these. A legal error in a ToS that goes undetected for three months has been "agreed to" by every customer who accepted the terms during that window. The blast radius grows with every day it is live.
The gate: no legally binding language ships to customers or counterparties without legal review. AI drafts. Legal clears. In that order, every time.
The Security Gate
Security changes are the highest-stakes category in the Velocity Risk Matrix because they score maximally on both axes and always carry the compounding modifier. A security misconfiguration is typically hard to reverse cleanly (affected data may already be exposed), affects users broadly (often the entire customer base), and compounds immediately (every hour of exposure is more data accessed, more regulatory liability, more reputational damage).
What belongs in the Deliberate Slow lane:
- Any change to authentication or access control configuration
- Production security tooling updates - see CrowdStrike. Staged rollout is not optional for tools with this blast radius.
- API key rotation, credential changes, firewall rule modifications
- Dependency updates in production - automated dependency updates without security review have introduced supply chain vulnerabilities to production systems repeatedly
- Any change that affects data encryption, data residency, or data retention
The DORA research program's 2023 State of DevOps Report identifies change failure rate as one of four primary measures of software delivery performance. Elite performers maintain a change failure rate of 0-15%. The organizations that achieve this are not moving slowly on every change. They are moving deliberately on the changes that count.
The gate: for any security-adjacent change, staged rollout is required, rollback procedure is documented before deployment starts, and monitoring is active from the moment the change goes live. A human is watching the first hour of any security change in production - not a dashboard that somebody checks in the next morning's standup.
Customer Communications
This is the category most organizations are getting wrong fastest, because AI makes mass customer communication trivially easy to produce and send - and because the legal, brand, and customer service implications of sending wrong communications at scale are severe and compound immediately.
The Air Canada case is the clean example for policy-carrying communications. But the failure mode is broader than legal liability. Consider:
- Incorrect information shipped at scale: An AI-drafted product announcement with wrong pricing, wrong feature descriptions, or wrong availability dates sent to 100,000 customers creates 100,000 customer service tickets, requires a correction email (which itself requires review), and damages trust in all future communications.
- Tone and timing failures: AI has no awareness of what else is happening in the news cycle, in your market, or for your customers at the moment of send. A promotional email sent on the day of a major customer outage is not a timing coincidence - it is a brand event.
- Support team unpreparedness: A communication announcing a new feature or policy change, sent before the support team has been briefed, guarantees that the first questions customers ask will be answered incorrectly.
- Regulatory communications: In any regulated industry, customer communications may be subject to regulatory review, record-keeping requirements, or disclosure obligations. Speed of generation does not change these requirements.
1. Accuracy review: Has a human verified that every factual claim in the communication is correct - pricing, dates, availability, policy language? AI drafts accurately on average. The tail risks are costly.
2. Support briefing: Has the support team been briefed on this communication and its implications? Are they ready to answer the questions it will generate?
3. Legal review: Does this communication make any commitment, state any policy, or imply any contractual terms? If yes, legal must clear it before send.
4. Timing check: Is there anything happening in your market, product, or the news cycle that makes this timing problematic? This is a human judgment that AI cannot make.
5. Rollback plan: If this communication contains an error, what is the plan? A correction email requires its own review cycle. Know the plan before the send.
Undetected Bugs and Support Unpreparedness
These two failure modes compound each other so reliably that they belong in the same section.
Undetected Bugs
AI-assisted code generation is faster. It is not more correct. GitHub's 2022 research showed developers complete tasks 55% faster with Copilot. Separate research into AI-generated code has consistently found that it introduces bugs at rates comparable to human-written code - sometimes higher in specific categories like security vulnerabilities and edge case handling.
Fast shipping compresses the QA window. A compressed QA window means bugs that would have been caught in a full regression cycle reach production. In regulated industries, a bug that affects financial calculations, medical records, or access control is not a sprint retro item. It is a regulatory event, a potential data breach, or a financial liability.
The question every team shipping AI-assisted code must answer honestly: has the QA window been sized to the blast radius of the feature, or has it been sized to the release schedule? These are different answers and most organizations are choosing the schedule.
Atul Gawande, in The Checklist Manifesto (2009), documented how aviation and surgery dramatically reduced error rates not by adding expertise but by adding structured checklists that enforce the steps that experts know should happen but skip under time pressure. The software industry has the equivalent in automated test suites, pre-release checklists, and code review gates. AI does not reduce the need for these. It increases it, because the speed of generation means more code is being shipped per unit of time - and the ratio of test coverage to shipped code tends to decrease when velocity goes up.
The Testing Foundation
The Velocity Risk Matrix classifies which lane a process belongs in. But the lane assignment assumes you have the infrastructure to detect when something goes wrong - before it reaches the full blast radius the process was classified for. Without automated testing and simulation environments, Fast Lane processes do not become safe. They become fast with no early warning system. That is a different thing entirely.
Three infrastructure components are prerequisites for any lane to function as designed:
Automated test suites with mandatory CI/CD gates. Every deployment to production must pass a suite of automated tests before proceeding. This is not a nice-to-have for Fast Lane processes - it is what makes Fast Lane operation safe. Without it, every deployment is a bet that the change did not break something you did not think to check. The speed of AI-assisted code generation means more code is being written per unit of time. If test coverage does not grow at the same rate, the ratio of tested behavior to deployed behavior decreases with every sprint, and the Fast Lane becomes progressively more hazardous regardless of how clean the code looks in review.
Staging environments that simulate production conditions. A Staged Lane deployment - canary rollout, feature flags, phased release - only provides meaningful protection if the environment it stages through accurately reflects production data volumes, traffic patterns, and integration behavior. A bug that does not appear under simulated load may appear under real load. A feature that works correctly against a test dataset may fail against production-scale data with edge case distributions that no one modeled. Staged rollout is a risk reduction mechanism, not a risk elimination mechanism. Its effectiveness is directly proportional to the fidelity of the environment in which the change is observed before expanding.
Post-deployment verification and active monitoring. Deployment is not the end of the safety process. It is the beginning of the observation window. Automated smoke tests running immediately after each deployment confirm that core system behavior is intact. Active monitoring of error rates, response times, and key business metrics in the first fifteen to thirty minutes after any deployment catches regressions at minimum blast radius - before they reach the full user base. The CrowdStrike incident reached 8.5 million machines before the error was caught in part because the window between deployment and confirmed system failure was too short to allow intervention at scale. Monitoring compresses that window. The question is not whether something went wrong. The question is how fast you know.
The relationship between testing infrastructure and the Velocity Risk Matrix is direct: test coverage and staging environment fidelity are what allow a process to be classified toward the Fast Lane with confidence. A release with strong automated coverage and a high-fidelity staging environment can often absorb one lane of additional speed, because the probability of an undetected error reaching full blast radius is lower. A release with thin test coverage or no staging environment should be treated as one lane slower, for exactly the same reason. The compounding modifier applies to testing gaps: every sprint of shipping without adequate test coverage adds another layer of untested surface area - which becomes harder to cover as the codebase and the feature set grow.
Support Unpreparedness
This is the silent cost of fast shipping that almost never appears in a sprint retrospective, because the blast radius lands in the customer service function rather than in product or engineering.
When a product ships faster than the support team can absorb it, the sequence is predictable:
- Feature ships. Documentation is incomplete or non-existent.
- Customers encounter unexpected behavior - bugs, UI changes, missing flows.
- Support ticket volume spikes. Support agents have not been briefed on the new release.
- Agents give inconsistent or incorrect answers, compounding customer confusion.
- Tickets pile up during the support team's learning curve, extending resolution times.
- Resolution times extending means more customers in the unresolved queue, more negative brand experiences, more churned users whose last interaction with the product was a support failure.
The product team sees the feature shipped on time. The customer success team sees a week of support hell. The executive team sees a customer satisfaction dip that nobody can explain. This is support debt, and it compounds exactly like technical debt - quietly, invisibly, until it is too large to ignore.
The minimum viable gate: no feature that changes customer-facing behavior ships without a support briefing document - written in support language, not engineering language - delivered to the support team at least 48 hours before release. Not on the day of. 48 hours before.
The Operator's Pre-Ship Checklist
The following checklist applies before any release that touches the Checkpoint or Deliberate Slow lane. It is not designed to slow everything down. It is designed to ensure that the things that must be slow are actually slow - and that deadline pressure does not silently move a Deliberate Slow process into the Fast Lane without anyone noticing.
Classify first: Where does this release sit on the Velocity Risk Matrix? If you have not answered this question explicitly, you are operating in the Fast Lane by default - regardless of the actual reversibility and blast radius.
Legal: Does this release contain or trigger any change to terms of service, privacy policy, pricing, or customer-facing commitments? If yes - legal review completed and signed off before proceed.
Security: Does this release touch authentication, access controls, encryption, security tooling, or dependency versions? If yes - staged rollout plan documented, monitoring active from release, rollback procedure tested, human assigned to watch first hour in production.
Data: Does this release involve any migration, transformation, or deletion of production data? If yes - backup verified, migration tested on production-equivalent data, rollback procedure documented, blast radius scoped.
Customer communication: Will this release trigger any customer-facing communication? If yes - accuracy reviewed by a human, support team briefed 48+ hours in advance, legal cleared if policy language present, timing checked against market context.
Testing infrastructure: Does an automated test suite exist that covers the behavior this release changes or touches? Do those tests run as a mandatory CI/CD gate before deployment proceeds? Has the release been validated in a staging environment that reflects production data volumes and traffic patterns? If the answer to any of these is no - the release is moving fast without the infrastructure that makes fast safe.
Post-deployment verification: Are automated smoke tests configured to run immediately after this deployment? Is active monitoring in place for error rates and key metrics in the first thirty minutes post-release? Is a named person responsible for watching the first hour in production - not a dashboard that gets reviewed in the next morning's standup?
QA window: Has the QA window been sized to the blast radius of this release, or to the release schedule? If to the schedule - who made that tradeoff consciously, and who owns the risk of a bug that the shorter window missed?
Support readiness: Can the support team answer the top 5 questions customers will ask about this release, correctly, right now? If no - the release is not ready, regardless of whether the code is.
Rollback: If this release needs to be reverted in the first hour, what is the exact procedure? If the answer is "we'd figure it out" - the release is not ready.
None of these gates are slow by nature. A small release with low reversibility risk and a contained blast radius can pass all of them in an hour. A large release with wide blast radius and irreversible customer-facing changes should take as long as it takes to answer them correctly.
The discipline is not in the checklist. It is in resisting the pressure to treat every release like a Fast Lane process because the team is capable of moving fast. Capability and safety are not the same thing. The CrowdStrike team was capable of pushing the update. The question they did not answer adequately was what happens if the update is wrong and it has already reached every machine.
"The question is not how fast can we move. The question is what is the cost of being wrong at this speed, in this process, with this blast radius."
AI has made every organization faster at moving. The organizations that will build lasting, trusted products are the ones that use that speed advantage selectively - deploying it fully in the Fast Lane, staged in the Staged Lane, gated in the Checkpoint Lane, and deliberately, carefully, without deadline pressure overriding the gates in the Deliberate Slow lane.
The slow is not a failure of capability. It is the architecture that makes the fast trustworthy.
This Is the Work I Do
Operating Architecture is the discipline I practice - aligning the people, systems, and processes that actually run a company so growth scales without breaking it. Risk architecture is one of its most important surfaces. I come in when the gap between how fast an organization can move and how safely it is actually moving has grown wide enough that it is starting to show up in customer experience, legal exposure, or engineering fragility.
If this essay surfaced uncomfortable questions about which of your current processes are being treated as Fast Lane when they belong in the Deliberate Slow lane - those are exactly the questions worth a conversation.
Related Reading
- The KPI Trap - How Goodhart's Law turns well-intentioned metrics into organizational risk. Directly relevant to the measurement traps that make teams optimize for speed over safety.
- The Expanding PM - The product manager as knowledge architect, research director, and the role that owns the AI knowledge layer every system depends on - including the knowledge of which processes need which lane.
- The AI Transformation Operator Playbook - Implementation-side AI adoption, including the governance and risk architecture that makes safe acceleration possible.
- Use Cases from the Field - Real patterns from organizational reviews - including regulated industries where the blast radius of a wrong move is not measured in sprint points.
May Mor
Operating Architect. M.Sc in AI, former Technical PM at a digital bank processing 500K+ loan requests with zero critical incidents, and an AI-native adtech company. I help operators align their people, systems, and processes so growth scales the business instead of breaking it - including the risk architecture that determines which processes can be accelerated and which must stay deliberately slow. Full bio →