How I Help Teams Move Fast Without Breaking Everything

Speed and stability aren't opposites — they're in tension, and managing that tension is a skill. Here's what actually enables fast, reliable delivery across the teams I've worked with.

The False Tradeoff

Teams often frame it as a choice: go fast or build robust systems. Move quickly to hit the roadmap, or slow down to do it right. This framing almost always leads to bad decisions, because it's wrong.

The teams that actually move fast — not for one sprint, but sustainably, quarter after quarter — are not the teams that cut corners. They're the teams that invest correctly in the things that let them move fast without accumulating drag.

And the teams that "go fast" by skipping tests and ignoring debt tend to spend an increasing proportion of their time dealing with the consequences of that decision, until at some point they're slower than the teams that went slower.

Small Changes, Often

The single practice that most consistently enables fast, safe delivery: small, frequent changes rather than large, infrequent ones.

A small change is easier to understand. It's easier to review. It's easier to test. When it breaks something, the blast radius is smaller and the cause is easier to identify. When it needs to be rolled back, the rollback is simpler.

Large changes compound every risk. The review takes longer. The merge conflicts are worse. The debugging surface when something goes wrong is enormous. The rollback might require unwinding a week of work.

I push teams toward smaller PRs — not by demanding it, but by making the case concretely. A PR that would have taken one day to review and three days to debug if it caused an incident, split into five PRs, can be reviewed in hours and diagnosed in minutes.

Small changes aren't just safer — they're actually faster in aggregate.

The Tests That Pay for Themselves

Not all tests are equal in terms of their return on investment. Some tests are expensive to write and maintain, and they catch categories of failure that almost never happen. Others are cheap and catch failures that would absolutely happen.

The tests that reliably pay for themselves:

• Tests that cover core business logic — the calculations, the validations, the state transitions the product depends on
• Tests that cover known failure modes — edge cases that have already caused incidents
• Integration tests that verify the contracts between services, not the internals of each one

Tests that often don't pay for themselves:

• Implementation tests that verify how something works rather than what it produces — these break on every refactor
• Tests written to hit a coverage percentage metric
• Full-scenario end-to-end tests that are fragile and slow and rarely tell you exactly what broke

The goal is a test suite that gives you confidence fast, not one that makes coverage reports look good.

Deployment Infrastructure Is a Productivity Investment

Teams that treat deployment as a ceremony slow themselves down without realizing it. If deploying requires manual steps, a coordination window, and a post-deployment check ritual — the frequency of deployments will drop, which means changes will batch up, which means each deployment gets riskier and slower.

One of the first things I evaluate when joining a team: how long does it take to get a change from merged to production? If the answer is hours or days, that's a significant productivity constraint.

Investing in automated deployment pipelines, automated rollback capability, and feature flags — these feel like platform work, not product work. They are platform work. They're also what enable the product work to go faster.

Your deployment infrastructure is part of your development velocity. It's not separate from it.

Clear Service Boundaries, Not Just Microservices

One of the things that slows teams down more than almost anything: systems where changing one thing requires understanding and testing many others.

This isn't solved by microservices specifically — it's solved by clear, respected service boundaries. Whether you have one service or twenty, the question is whether a change in one area requires understanding another area to implement or test.

When services have well-defined interfaces, documented contracts, and don't depend on each other's internals, teams can work in parallel. When services are coupled — passing data structures across boundary lines, sharing database tables, calling each other's internal methods — every change potentially touches everything, and teams slow to a crawl trying to coordinate.

Establishing and maintaining clear boundaries is maintenance work that doesn't show up on the roadmap. It's also the structural foundation that makes roadmap work go faster.

Incident Culture That Enables Learning

Teams that move fast and stay stable tend to treat incidents differently from teams that don't.

The teams with bad outcomes: incidents trigger blame, which triggers defensive behavior, which means information gets suppressed, which means the system doesn't learn.

The teams with good outcomes: incidents trigger curiosity. What actually happened? Where did our assumptions break? What would let us catch this earlier? What would reduce the impact when it happens again?

The goal after an incident is not accountability in the blame sense — it's understanding that prevents the next one.

Fast teams run detailed post-mortems, implement the learnings, and build monitoring that catches the next variant of the problem earlier. The investment in understanding what went wrong pays back in reduced incident frequency and reduced incident duration.

Moving fast isn't about skipping the things that slow you down — it's about building the systems that make speed sustainable.