DEV Community: mjodeh

Why “Move Fast” Is Not an Engineering Strategy

mjodeh — Mon, 03 Aug 2026 13:57:03 +0000

When a release slips, the usual response is predictable: shorten the deadline, add more work to the sprint, and ask engineering to move faster.

That response confuses urgency with strategy.

A team can increase activity without improving delivery. Developers can open more pull requests, managers can increase sprint commitments, and product leaders can mark more work as urgent. None of that guarantees that a useful, reliable change reaches production sooner.

“Move fast” describes a business need. It does not explain how engineering should respond.

A credible software delivery strategy must answer harder questions:

What outcome matters most?
What work should stop?
Where is delivery actually slowing down?
Which risks are acceptable?
Which quality boundaries cannot be crossed?
How will the organization know whether it became faster?

The central argument is simple: engineering speed is a property of the delivery system, not a personality trait of the people inside it.

“Move Fast” Is Too Vague to Guide Engineering Decisions

The instruction to move fast leaves the most important decisions unresolved.

Does the organization need to release more frequently? Validate a product assumption earlier? Recover from incidents faster? Meet a fixed regulatory deadline? Reduce the time required to onboard customers?

These are different problems.

A team trying to validate demand may need a narrow prototype and limited rollout. A team trying to improve reliability may need better observability and rollback procedures. A team trying to deliver a committed roadmap may need to stop lower-priority work.

Using the same response for every form of urgency usually creates the wrong optimization.

Define the type of speed required

Before changing the engineering process, leaders should identify the result they need.

For example:

Faster learning: Reduce the time between an idea and evidence from users.
Faster releases: Reduce the time between completed code and production.
Faster delivery: Reduce the full time from an approved need to a usable outcome.
Faster recovery: Reduce the time required to detect and resolve production failures.
Faster response: Reduce the time needed to react to market, customer, or regulatory changes.

A team may improve one while making another worse.

Releasing more frequently does not guarantee faster learning if nobody measures user behavior. Coding faster does not improve recovery time if the system is difficult to observe. Starting more initiatives does not improve delivery if shared dependencies block all of them.

Make trade-offs explicit

Urgent work usually requires a trade-off. The mistake is pretending that no trade-off exists.

A team may reduce scope while keeping reliability requirements intact. It may accept a temporary manual operation to validate demand before automating it. It may choose a reversible implementation instead of a more elegant long-term design.

Those choices can be responsible.

The irresponsible version is allowing teams to infer that testing, security, maintainability, or operational readiness should be reduced because the date has not changed.

Engineering leaders should state clearly:

What can be reduced
What can be deferred
What must remain unchanged
Who accepts the resulting risk

Without this, “move fast engineering” becomes an exercise in hidden risk transfer.

Coding Speed Is Not Software Delivery Speed

Engineering organizations often focus on coding because it is visible.

Pull requests can be counted. Tickets can be closed. Story points can be discussed in planning meetings. Waiting is harder to see.

Consider a feature that requires ten working days of implementation but takes eight weeks to reach production.

The remaining time may include:

Five days waiting for product clarification
One week waiting for another team’s API
Four days waiting for code review
One week waiting for a stable test environment
Several days waiting for security approval
One week waiting for a release window

In this example, asking developers to implement the feature 20% faster saves two days. Removing one approval delay may save a week.

That is the difference between local productivity and end-to-end software delivery speed.

Measure where work waits

A useful delivery review should reconstruct the actual path of completed work.

For a small sample of recent features, record:

When the work was requested
When it became clear enough to start
When implementation began
When the first review was requested
When review completed
When testing completed
When the change became deployable
When it reached production
When meaningful feedback became available

The goal is not to create a perfect measurement system. The goal is to find the largest delays.

This often reveals that the main constraint is not engineering capacity. It may be unclear ownership, unavailable environments, centralized approvals, or too many concurrent priorities.

Use velocity metrics carefully

Story points can help a team plan its own work. They are weak evidence of organizational productivity.

A team can increase reported velocity by changing estimation behavior, splitting work differently, or taking on more predictable tasks. None of those necessarily improve customer outcomes.

Engineering leaders should prefer a balanced view that includes:

Lead time
Cycle time
Time waiting for review
Time blocked by dependencies
Deployment delay
Rework
Release predictability
Production failure patterns
Time to restore service
Evidence of customer or business impact

These metrics should diagnose the system. They should not be used to rank individual developers.

AI Can Accelerate Work and Still Slow Delivery

AI-assisted development changes implementation capacity, but it does not remove the rest of the delivery process.

A team may use AI to generate code, tests, migration scripts, or documentation faster. That can be valuable.

But imagine that the team doubles its pull-request volume while senior review capacity remains unchanged. The review queue grows. Integration conflicts increase. Test environments become busier. More generated code requires architectural validation.

Implementation became faster. Delivery did not.

The correct question is therefore not:

How much code did AI generate?

It is:

Did AI reduce the total time required to deliver a correct, maintainable, production-ready change?

This distinction matters for organizations adopting AI-assisted software development. AI can improve engineering velocity when it reduces a real constraint. It can also move the constraint into review, testing, architecture, security, or production support.

A practical approach is to introduce AI into a specific part of the workflow and measure the effect on the entire path.

For example:

If AI generates tests faster, did review time fall or rise?
If AI drafts migrations, did deployment confidence improve?
If AI creates more pull requests, did lead time decrease?
If AI supports code review, did defect escape increase?
If AI helps with debugging, did recovery time improve?

The benefit should be measured at the system level, not only at the point where the tool is used.

What a Software Delivery Strategy Must Contain

A software delivery strategy should turn urgency into a set of operating decisions.

It does not need to be a large transformation document. It needs to define how work will move from an identified need to production feedback.

1. A clear outcome

Every significant initiative should answer:

What problem are we solving?
Who is affected?
What evidence would show improvement?
What is the smallest valuable result?
Which assumption is most likely to be wrong?

This prevents teams from delivering a large amount of functionality before discovering that the original assumption was weak.

2. A real priority order

If five initiatives are all called critical, none of them is truly prioritized.

Real prioritization requires leadership to decide:

Which work receives capacity now
Which work is paused
Which work is reduced in scope
Which commitments are displaced by new urgent work

Adding a new priority without removing an old one is not prioritization. It is queue growth.

3. Limits on concurrent work

Too much work in progress creates context switching, coordination overhead, and dependency queues.

Suppose five initiatives all need the same platform engineer and the same test environment. Starting all five does not increase throughput. It creates five partially completed streams competing for the same constraint.

A more effective decision may be to finish two initiatives before starting the remaining three.

This can feel slower because fewer projects are visibly active. It is often faster because valuable work reaches completion sooner.

4. Smaller delivery units

Large changes delay feedback and increase the cost of failure.

Teams should look for ways to release:

Thin vertical slices
Smaller pull requests
Backward-compatible API changes
Incremental migrations
Features behind flags
Limited-audience rollouts

The objective is not to split work into meaningless technical tasks. Each slice should either deliver value, validate an assumption, or reduce a known risk.

5. Clear decision ownership

Work often waits because nobody knows who can decide.

A delivery strategy should distinguish between:

Decisions teams can make independently
Decisions requiring consultation
Decisions requiring explicit approval
Decisions that must be escalated immediately

For example, a team may be free to choose an implementation approach within agreed architectural and security boundaries. A change to shared customer data may require broader approval.

This reduces unnecessary escalation without removing governance.

6. Non-negotiable quality boundaries

Teams should not renegotiate basic safety for every deadline.

Typical non-negotiable boundaries may include:

Authentication and authorization
Data integrity
Backward compatibility
Critical automated tests
Monitoring and alerting
Rollback capability
Regulatory requirements

The exact boundaries depend on the system. A marketing experiment and a payment service should not receive identical treatment.

The principle is to match assurance to risk, reversibility, and impact.

7. A feedback loop

The strategy should define how the organization will learn whether the change worked.

Shipping is not the end of delivery. The team needs evidence.

That may include:

Adoption
Conversion
Reduced operational effort
Fewer support requests
Lower failure rates
Faster processing
Improved customer completion rates

Without feedback, the organization can become faster at delivering the wrong thing.

How Engineering Teams Move Faster in Practice

The most useful question is not, “How can the team work faster?”

It is:

What causes work to wait, expand, or return?

That question leads to practical interventions.

Reduce work before increasing capacity

Start by listing active initiatives and assigning each one a clear status:

Continue
Pause
Reduce
Cancel
Complete before starting new work

This is often more effective than immediately hiring more developers.

Additional engineers help when implementation capacity is the main constraint. They may make matters worse when the bottleneck is review, product clarification, architecture ownership, or deployment.

Hiring into the wrong constraint increases coordination without increasing throughput.

Replace large releases with thin slices

Suppose a team plans a three-month customer onboarding redesign.

Instead of releasing the entire flow at once, it could first release one improved step for a limited customer segment. That may reveal whether the expected drop-off point was correctly identified.

The result informs the rest of the investment.

This is a concrete way to improve delivery speed without sacrificing quality: reduce the size of the decision, not the level of care.

Move routine decisions closer to the team

If every security, architecture, and deployment question requires a committee meeting, work will wait.

Create reusable boundaries:

Approved implementation patterns
Standard threat checks
Defined data classifications
Deployment templates
Service ownership rules
Clear escalation triggers

The team should not need executive involvement for a decision it makes repeatedly.

Automate the path that blocks delivery

Automation should be selected based on delay, not enthusiasm.

If deployments are manual and risky, automate deployment and rollback.

If developers wait days for environments, automate environment creation.

If a slow test suite delays every pull request, improve test execution before adding more coding tools.

If product clarification causes repeated rework, automation is not the first answer. Better decision-making is.

Review the system regularly

Once per month, select a few completed and delayed items and examine:

Where they waited
Why they returned for rework
Which dependencies blocked them
Which decisions arrived late
Which controls added value
Which controls added delay without reducing risk

Then improve the largest current constraint.

Do not launch ten process initiatives at once. The improvement system can suffer from the same excessive work in progress as the delivery system.

How to Move Fast Without Breaking Things

The phrase “move fast without breaking things” is sometimes treated as unrealistic.

It is realistic only when “without breaking things” does not mean eliminating every failure.

Complex systems will fail. The practical goal is to reduce the probability, impact, and recovery cost of failure.

Teams can do this by making changes:

Smaller
Easier to observe
Safer to reverse
Continuously validated
Released to limited audiences first

A small change behind a feature flag can be tested with a limited group and disabled quickly. A large tightly coupled release has a wider failure surface and fewer recovery options.

Quality and speed are not automatically aligned. Poorly designed quality gates can create delay without reducing meaningful risk. Weak quality practices can also create incidents and rework that destroy delivery speed.

The engineering task is to apply the right level of assurance to the specific risk.

What Engineering Leaders Should Say Instead

Leaders do not need to remove urgency. They need to make it actionable.

Instead of saying, “Move faster,” ask:

What is the main constraint on this work?
What should stop so this becomes the priority?
What is the smallest valuable release?
Which assumption should we test first?
Where is the work waiting?
Which dependency requires leadership intervention?
Which risks are reversible?
Which quality boundaries cannot change?
How will we know the outcome was achieved?
What did we learn from the last delayed initiative?

These questions convert pressure into decisions.

They also make accountability clearer. Engineering owns technical execution and risk. Product owns problem clarity and value. Leadership owns priority conflicts, organizational constraints, and accepted trade-offs.

Speed improves when those responsibilities are explicit.

Conclusion: Do Not Ask for Speed Before Finding the Constraint

“Move fast” is a valid expression of urgency. It is not a plan.

A strong software delivery strategy does not begin by asking developers to produce more. It begins by identifying why valuable work is not reaching production sooner.

Sometimes the answer is implementation capacity.

Often it is something else: unclear priorities, too much concurrent work, late decisions, shared dependencies, unstable environments, manual release processes, or feedback that arrives too late.

The practical sequence is straightforward:

Define the outcome.
Map the delivery path.
Find the largest delay.
Improve that constraint.
Measure the end-to-end effect.
Repeat.

Before asking an engineering team to move faster, find the place where the work has stopped moving.

Discussion question: What is the largest source of delay in your delivery system today: implementation, decisions, dependencies, validation, or release?

The Hidden Cost of Starting Development Too Early

mjodeh — Fri, 31 Jul 2026 17:53:24 +0000

On Monday, a feature moves to In Progress.

By Tuesday, the repository has a new module, a database migration, and a set of endpoints. On Wednesday, the first pull request is open. By Friday, the happy path works in a demo.

The work looks healthy. The board is moving. Code is accumulating.

But the team still has not agreed on what should happen when a request is repeated, a dependency times out, an event arrives out of order, or a user changes state halfway through the operation.

That is not a small planning gap. It means implementation began before the product's behaviour was defined.

Early coding often creates an illusion of progress because it produces visible artifacts: commits, screens, endpoints, and passing tests. At the same time, it quietly converts unresolved decisions into implementation assumptions.

And code is one of the most expensive places to store ambiguity.

A ticket can be detailed and still not be decision-ready

Many tickets describe the shape of a feature without defining its behaviour.

Consider a seemingly simple operation:

POST /subscriptions/{id}/activate

202 Accepted

That contract looks implementable. It is not—not yet.

The endpoint says nothing about the questions that determine the real system:

Is activation synchronous, asynchronous, or eventually consistent?
Is the operation idempotent? What happens when the client retries after a timeout?
Can a subscription be cancelled while payment is pending?
If payment.succeeded arrives after cancellation, which transition wins?
Are events delivered at most once, at least once, or without an ordering guarantee?
Which service owns the authoritative state?
What does the caller observe during partial failure?
What evidence proves the feature is accepted?

Two experienced engineers can implement the same ticket correctly and still build incompatible systems because each filled in those blanks differently.

The problem is not coding ability. The problem is that a product decision was allowed to masquerade as an implementation detail.

Four agreements should exist before production implementation

A team does not need a hundred-page specification before writing code. It does need enough shared precision to prevent each engineer from inventing a different product.

At minimum, four things should be agreed.

1. Behaviour

Behaviour defines what the system does from the user's or caller's perspective.

For stateful features, prose is rarely enough. Make the transitions explicit:

draft -> pending_payment -> active
                    |          |
                    v          v
                 cancelled   suspended

Then challenge the diagram:

Which commands are valid in each state?
Which transitions are reversible?
What happens on duplicate, late, or out-of-order events?
Which outcomes are visible to the user?

If the team cannot answer those questions consistently, the behaviour is not yet ready to encode.

2. Constraints

Constraints are the invariants and operating limits the implementation must preserve.

They include business rules—such as plan limits, permission boundaries, and legal restrictions—but also system properties such as latency budgets, data residency, transaction boundaries, availability targets, and compatibility requirements.

A technically correct implementation can still be unusable if it violates a constraint that surfaced too late. Discovering after development that an operation must be atomic across two stores, complete within 200 milliseconds, or run without transferring data across regions is not refinement. It is redesign.

3. Integration contracts

An integration contract is more than a request and response schema.

It should define ownership, versioning, failure semantics, timeout behaviour, retry policy, idempotency, ordering guarantees, and compatibility expectations. For event-driven systems, it should also answer who may emit an event, what makes it unique, how consumers recover, and how schema evolution is handled.

The happy-path payload is usually the cheapest part of an integration. The expensive part is everything that happens when the network behaves like a network.

4. Acceptance criteria

Acceptance criteria should make success observable and falsifiable.

“The user can activate a subscription” is a summary, not a testable criterion. Stronger criteria describe the initial state, the action, the expected outcome, and the important failure cases.

For example:

Given a subscription is pending payment
And the user has cancelled it
When a delayed payment-success event is received
Then the subscription remains cancelled
And the payment is queued for refund exactly once
And the decision is visible in the audit trail

This single scenario aligns product behaviour, the domain state machine, integration semantics, idempotency, and observability. It removes far more uncertainty than another day of speculative implementation.

Why early coding feels faster

Implementation has a psychological advantage: it is concrete.

A team can count pull requests, story points, endpoints, components, and passing tests. Agreement work produces fewer visible artifacts, even when it removes the uncertainty most likely to delay delivery.

That makes it easy to confuse activity with progress.

Early implementation also tends to move quickly because engineers choose convenient defaults for every unanswered question. The first version may look efficient precisely because it has not yet encountered the decisions it postponed.

Tests can reinforce the illusion. A test suite proves that the code behaves as its authors expected. It does not prove that those expectations were shared, complete, or correct. If the team never agreed on the behaviour, green tests may simply preserve the wrong assumption more rigorously.

The branch is moving. The decision graph is not.

Rework grows across surfaces, not files

The cost of an unresolved decision is not limited to rewriting a function.

A useful engineering heuristic is:

Expected rework ~= unresolved decisions
                  x affected surfaces
                  x cost of reversal

Suppose the team initially treats subscription activation as synchronous, then later agrees that it must be asynchronous and resilient to duplicate delivery. That decision can change:

the domain state model;
database schema and existing records;
public API responses;
event schemas and consumer logic;
client-side loading and error states;
retry and idempotency mechanisms;
tests and test data;
metrics, alerts, and operational runbooks;
analytics definitions and support documentation.

At that point, calling the work “a refactor” understates it. The team is reversing a distributed decision that has already propagated through the system.

This is why a small ambiguity at the start can become a large delivery cost later. The ambiguity stayed constant; its blast radius grew.

The answer is not heavyweight specification

The alternative to premature implementation is not months of analysis or a demand for perfect certainty.

The goal is a decision-ready slice: the smallest set of artifacts that lets engineering start without inventing product behaviour inside the codebase.

For many features, that can be lightweight:

a few concrete examples covering the main and failure paths;
a state transition sketch for stateful behaviour;
explicit invariants and non-functional constraints;
versioned request, response, or event schemas;
documented timeout, retry, and idempotency semantics;
testable acceptance criteria;
a short list of remaining unknowns, each with an owner.

These artifacts should be reviewed together, not produced by separate functions and thrown across handoff boundaries. Product, design, engineering, and dependent teams need to see the same behaviour from their respective angles.

The objective is not to eliminate learning. It is to decide which uncertainty is acceptable before the cost of changing it multiplies.

Exploration code and commitment code are different

Sometimes coding early is exactly the right move.

A time-boxed spike can test whether a library supports a required protocol, whether a query can meet the latency budget, or whether an external API behaves as documented. A prototype can expose usability questions faster than a meeting.

But exploratory code needs an explicit contract of its own:

What question is it answering?
How long will the exploration run?
What evidence will it produce?
Is the code disposable?
What decision must be made before it becomes production implementation?

Without those boundaries, prototypes have a habit of becoming foundations. Temporary assumptions acquire users, data, and dependencies. The team then has to preserve decisions it never consciously made.

Exploration code can start early. Commitment code should wait until the team knows what it is committing to.

A practical start-development gate

Before a feature enters production implementation, I would expect the team to answer these questions:

Can we describe the user-visible outcome in the same words?
Are the important states and transitions explicit, including retries and out-of-order events?
Are business and technical invariants documented?
Do integration contracts define failure semantics, not only payloads?
Are acceptance criteria objective enough to become tests and observable enough to operate in production?
Are the remaining unknowns named, owned, and deliberately accepted?

If the answer is no, the next step is not necessarily “stop.” It may be a short behaviour workshop, a contract review, or a targeted technical spike.

But it should not be production code pretending the decision has already been made.

Shipping sooner starts with deciding sooner

Starting development early can improve a schedule on paper while making the real delivery date less predictable. The first week looks fast because the team is borrowing time from later weeks—when assumptions collide, interfaces change, data must be repaired, and tests have to be rewritten.

High-performing teams do not delay implementation for ceremony. They delay irreversible commitments until the relevant decisions are explicit.

The best time to discover that two teams mean different things by “activated” is before both definitions are running in production.

The gap between intent and implementation—where behaviour, constraints, contracts, and evidence either align or drift—is the problem space I am exploring with Lopeline. I will share more about that soon.

Teaching Agents to Slow Down Where It Matters

mjodeh — Sun, 19 Jul 2026 09:20:53 +0000

Say "fable-mode" (or "operate carefully," or "high-judgment mode" or "think like fable") in a Claude Code or Codex session, and one line buried in the skill file does most of the work: "Never promote 'plausible' to 'confirmed' in your summary." That single rule is the whole philosophy in miniature — don't let something that merely looks right pass as something that was checked.

Fable-mode is not a tool, a model swap, or a set of new commands. It's a behavioral overlay — a skill file at ~/.claude/skills/fable-mode/SKILL.md or ~/.codex/skills/fable-mode/SKILL.md or any other agent you use, that gets loaded into the turn and changes how the agent scopes work, verifies its own claims, and reports results. Nothing about what Agents can do changes. What changes is the discipline around using it.

What actually changes

The skill is organized into seven blocks, and each one targets a specific failure mode that shows up in normal agent use:

Judgment before action. The first move is classification: is this a question, a problem description, or a change request? For the first two, the deliverable is an assessment — investigate and stop, don't start editing files nobody asked you to edit. Irreversible actions (deletes, pushes, overwrites) require a stop-and-confirm, and specifically: "before deleting or overwriting anything, actually look at the target."

Verification as the non-negotiable core. This is the section that does the heavy lifting. Every "done" claim needs evidence produced after the last edit — a test run before your final change proves nothing about your final change. Claims get graded on a three-tier scale: Confirmed (you ran it and saw the result), Plausible (the code reads right but you haven't executed it), Assumed (inherited from the user's description). The rule is that you report the grade you actually earned, not the one that sounds better.

Reasoning habits. Hold two hypotheses before committing to a diagnosis. Treat your memory of a library's API as a prior, not a fact, and check the installed version when correctness depends on it. When a result contradicts what you expected, that's flagged as "the most information-dense moment of the task" — chase it instead of smoothing over it.

Anti-patterns as hard stops. Eight explicit bans, including "declare success without a post-change verification run," "fix a bug you can't explain," and "hedge a known failure ('should work now') — either you verified it or you report it as unverified."

The skill closes with a five-item checklist the agent is meant to run before ending any turn — essentially a self-audit against the rules above.

Advantages

Verification stops being optional. The "read before you write" and "check you didn't break the neighbors" rules mean the agent greps for other callers of a function it just changed instead of assuming the diff is self-contained.
Reports get honest, not optimistic. The Confirmed/Plausible/Assumed grading forces a specific kind of intellectual honesty that's easy to skip under normal operation, where "should work" and "verified working" tend to blur together in the final summary.
Scope stays tight. "Prefer the smallest change that fully solves the problem" combined with "expand scope without flagging it" being a hard stop means less unrequested refactoring riding along with a bug fix.
Root-cause bias. The rule that a fix needs a one-sentence causal explanation before it's applied catches the class of fix that happens to make a symptom disappear without addressing why it occurred.
Effort matches stakes. "A one-line fix does not need a design document. A schema migration does not get done on vibes" — the skill explicitly scales its own overhead down for trivial tasks, so it isn't uniformly slower.

Disadvantages

It's a self-reported discipline, not an enforced one. There's no external checker validating that the agent actually ran the test it claims to have run — the whole system depends on the model correctly following its own instructions and honestly grading itself. A model that misjudges "confirmed" vs. "plausible" produces the same failure mode fable-mode was meant to prevent, just with more confident-sounding labels attached.
More tool calls per task. Verifiable increments, post-change re-runs, and neighbor-checking all mean more intermediate steps than an agent optimizing purely for speed. On tasks where the user genuinely wants a fast, rough pass, this overhead is friction, not value.
No built-in tool selection guidance. The skill is explicit that it "governs how work is scoped, verified, and reported — not what tools to use." It won't tell the agent which agent, MCP, or command to reach for; that judgment still comes from elsewhere.
Depends on activation. It's opt-in per session via trigger phrase. A user who forgets to say "fable-mode" on a high-stakes task gets none of it — there's no persistent always-on variant described in the file.
Checklist compliance can become theater. A five-item checklist run by the same agent that did the work is a weaker guarantee than an independent review pass; it catches self-aware gaps, not blind spots the agent doesn't know it has.

What to actually expect

Turn fable-mode on for the tasks where being wrong is expensive: schema migrations, auth changes, anything touching shared code, or a bug you don't yet understand. Expect the final report to distinguish what was actually tested from what merely compiles, expect fewer "while I was in there, I also…" surprises in the diff, and expect the agent to stop and ask before anything destructive rather than assuming consent. Don't expect it to make trivial tasks faster — for a one-line CSS fix, the skill's own "match depth to stakes" rule means it should behave close to normal anyway. The gain isn't speed; it's a report you can trust at face value, on the tasks where that trust is worth paying the extra verification steps for.

Skill File to download

fable-mode

Feel free to contribute

Why faster typing rarely produces faster delivery

mjodeh — Sat, 18 Jul 2026 08:55:32 +0000

A developer finishes the change on Tuesday. The customer sees it three Tuesdays later. What happened in between is the real story of software delivery.

When delivery slows, the instinct is almost always the same: push the engineering team to move faster. Increase velocity. Add developers. Introduce another coding assistant. Reduce the estimate. Ship more story points.
It sounds rational because code is the most visible artifact in software development. But code is only one station on a much longer line. Most delays happen before the first line is written or after the last pull request is merged.

The delivery flow from idea to impact:
DEFINE (Clarity) -> DECIDE (Approvals) -> BUILD (Code) -> CONNECT (Dependencies) -> PROVE (Validation) -> RELEASE (Ownership).

Only one stage is primarily about typing code. Every stage can slow delivery.

The keyboard is rarely the constraint
Imagine a feature that requires two days of focused development. It waits three days for a product decision, four days for another team to expose an API, two days for review, and five days for a shared test environment. Making the coding twice as fast saves one day. Fixing the surrounding flow can save fourteen.
That is why teams can become better at producing code without becoming better at delivering outcomes. They optimize the activity while leaving the system untouched.

CLARITY

Unclear requirements are rework in disguise

The team starts moving before everyone agrees where it is going.
A vague requirement does not disappear when development begins. It simply changes form. It becomes a Slack thread, an assumption embedded in the code, a late design debate, or a feature that technically works but solves the wrong problem.
This creates the illusion of progress: tickets move, commits appear, demos happen. Then the questions arrive. What should happen in the edge case? Which system owns the data? Who is the real user? What does success look like? The team rewrites what it already built because it began with motion instead of clarity.
A short, difficult conversation before coding is often faster than a long, expensive correction afterward.

DECISIONS

Approval delays create a hidden queue

Work can be complete and still be nowhere near delivered. A security review waits for a specialist. A product decision waits for a meeting. A pull request waits for someone with the right context. A release request waits for a change window. None of this looks like active engineering work, yet all of it belongs to the delivery timeline.
Most delivery dashboards are excellent at counting activity and poor at measuring silence.
They show how long a task was in development, not how long it sat untouched between people. But customers experience the whole clock, including the waiting.

DEPENDENCIES

Local speed cannot defeat a system dependency

One team finishes. The outcome remains blocked. Modern software is a web of services, data contracts, platforms, vendors, environments, and specialist teams. A team may complete its part quickly and still wait for an API, a schema change, infrastructure capacity, legal language, or a partner release.
This is the trap of local optimization: every group can report that its own work is on track while the customer-facing outcome is late. Delivery speed lives in the handoffs. Define contracts early, reduce unnecessary coupling, and make escalation paths explicit.
The better question
How much time did the work spend moving - and how much time did it spend waiting?
That ratio reveals more about delivery performance than typing speed or story points.

REWORK

The fastest first draft can still be the slowest route

Work returns because feedback arrived after commitment.
Rework is not merely another edit. It reopens design, implementation, review, testing, documentation, and approval. The team pays for the same decision several times because the right people or the right evidence appeared too late.
The aim is not to make the first version perfect. It is to make it directionally correct - by testing assumptions early, reviewing thin slices, exposing risks before they harden into architecture, and letting users react before the solution becomes expensive to change.

OWNERSHIP

Work slows down in the space between teams

When everyone contributes but nobody carries the outcome.

Who resolves conflicting requirements?
Who owns the integration?
Who decides whether a defect blocks release?
Who notices that the approval has been waiting for four days?

When those answers are unclear, work becomes organizational luggage left between gates.
Ownership does not mean one person performs every task. It means one person remains accountable for the journey: clarifying the next decision, surfacing the blocker, finding the owner, and keeping the outcome from becoming an orphan.

VALIDATION

Late validation turns feedback into a bottleneck

Testing at the end makes learning expensive.
When quality assurance, security, accessibility, compliance, and user acceptance are treated as final gates, they become queues. The team discovers fundamental problems only after the solution feels finished. Every finding now threatens a deadline and triggers a larger cycle of rework.
High-flow teams pull validation forward. Acceptance criteria exist before development. Automated checks run while code is changing. Security and operations review risky choices early. Stakeholders see small increments. Releases are observable and reversible. Earlier feedback is not extra process; it is less expensive process.

Optimize the journey, not the keystrokes
If leaders want faster delivery, they need to manage the flow from idea to customer impact. That means looking beyond sprint velocity and asking where time, confidence, and accountability are being lost.

WAIT Where does work sit untouched the longest?
DECIDE Which decisions repeatedly arrive after implementation has begun?
DEPEND Which handoffs or dependencies create the most uncertainty?
RETURN Why does supposedly finished work come back for another cycle?
OWN At what moments does nobody clearly own the next move?
PROVE Which validations happen only when change is most expensive?

AI coding tools can accelerate implementation. More engineers can add capacity. Better development practices matter. But those investments create meaningful speed only when coding is the constraint. Otherwise, they simply send more work into the same queues faster.
THE LEADERSHIP SHIFT

Typing is an activity. Delivery is a system.

The fastest teams create clarity early, make decisions quickly, manage dependencies deliberately, assign ownership visibly, and shorten every feedback loop.

Before asking developers to code faster, follow one feature from idea to production. The keyboard may be the easiest part of the journey.