Most technical strategies are excellent at adding work. They promise a simpler architecture, faster builds, better reliability, and more capable teams. Then the same people are expected to keep every old service, dashboard, migration, and support promise running at its current level. The strategy is ambitious; the capacity model is fiction.
A stop-doing list makes that contradiction visible. For every substantial new bet, it names the work that will end, pause, shrink, or move to a different owner. It also names the work that cannot safely stop. This is not a ceremony for saying no to unpopular requests. It is how an engineering leader shows where time will come from and what the organization should expect to change.
The list belongs beside the strategy, not in a private manager's notebook. Product partners, service owners, and staff engineers need to see the tradeoff before they commit to dates or promise users continued support.
Start with capacity, not the project wish list
Suppose a platform group wants to replace a slow build pipeline. The proposal calls for two engineers over a quarter. The planning document shows expected gains in developer feedback time, but it does not say who will answer the existing support queue, maintain the old runner, or finish the half-complete migration already in flight. Those obligations have not disappeared merely because the slide shows a better future.
Put recurring commitments on the same page as proposed investments:
| Commitment | Current cost or constraint | Possible decision |
|---|---|---|
| Old build runner | Break-fix work and version updates | Freeze new features, preserve critical fixes until retirement |
| Developer support queue | Interrupts several engineers each week | Route routine requests through documented intake and a named rotation |
| Half-complete migration | Consumes review and coordination time | Finish a bounded milestone or explicitly pause it |
| New build pipeline | Needs focused design, implementation, and adoption time | Fund only after the displaced work has an owner and date |
The entries are illustrative. The point is to distinguish work that is visible on a roadmap from the operational work that quietly consumes the same people. If the new initiative needs six engineer-months, the plan must find six engineer-months of real capacity, a credible reduction in scope, or new staffing. It cannot borrow that time from an imaginary version of the team.
Do not turn this into a precise timesheet exercise. Estimates are enough to expose the main conflicts. Look at support volume, on-call load, maintenance obligations, active project commitments, and the amount of uninterrupted time the new work actually needs. A half-day scattered across five engineers is not equivalent to a half-day of focused implementation.
Give each item a disposition
“We will deprioritize legacy work” is too vague to help anyone. A useful stop-doing entry has a specific disposition:
- End: Retire the service, report, process, or feature after an explicit exit check.
- Pause: Stop planned improvements for a period while preserving a path for urgent defects.
- Reduce: Lower a service level, release frequency, coverage target, or supported surface.
- Transfer: Move ownership with documentation, access, and an accepted handoff.
- Decline: Tell requesters that a proposed new obligation will not be accepted under this strategy.
Each choice changes what someone can rely on. Write that consequence down. “Pause feature development on the old runner through December; continue security and production fixes; migrate its remaining users before removing it” is an operating decision. “Focus on the new pipeline” is a slogan.
For platform teams, intake is often where hidden commitments begin. A support answer can quietly become a product promise. Platform Intake Triage Should Make the Next Decision Obvious gives a way to route a request before it consumes roadmap capacity.
Separate a stop from an abandonment
Some work carries a duty you cannot wish away. A security obligation, regulatory commitment, production incident response path, or contract with another team needs a safe replacement before the old arrangement ends. If the strategy depends on dropping one of those obligations, the strategy is incomplete.
Write the guardrail with the decision. For a service retirement, that might mean no active callers, a tested migration path, a rollback window, and a named owner for the last exception. For a paused feature, it might mean a security update policy and a date when continued support will be reviewed. For a transferred tool, it means the receiving team accepts the work, has access, and knows the failure modes.
This is why a stop-doing list is more useful than a list of unpopular projects. It forces engineering to distinguish optional investment from required care. When Can You Finally Retire a Developer Tool? goes deeper on the evidence and handoff needed to make one retirement real.
The same principle applies to people. “Stop attending every design review” can free a staff engineer for strategy work, but only if teams know which reviews still need that engineer, who can decide routine questions, and how to escalate a consequential disagreement. Otherwise the meeting disappears while the dependency remains.
Make the tradeoff legible to the people paying it
A stop-doing decision has an affected audience. The old tool's users may face a migration. A product partner may lose a feature date. An operations team may inherit a smaller but more specialized support burden. The plan should name those effects early enough for people to challenge a mistaken assumption.
For each entry, record five things:
- What changes: The concrete work, service, or promise being ended or reduced.
- Why: The new priority that needs the capacity, with the expected benefit and uncertainty.
- Who is affected: Users, teams, and obligations that depend on the current state.
- Who owns the transition: The person who communicates the decision and checks the exit condition.
- When it is reviewed: A date or trigger that prevents “temporary” support from becoming permanent by neglect.
A short decision record beats a beautiful roadmap that conceals the cost. It can be as small as: “We will stop adding plugins to the old CI runner after October. The platform team will support production fixes through January. Service teams must migrate jobs with a documented exception path. If fewer than 90% of jobs have moved by December, we will revisit the retirement date or reduce the new pipeline's scope.” The percentages and dates here illustrate the shape of a decision, not a real organization's plan.
Invite the people who operate the system to pressure-test it. They often know about consumers that the planning meeting missed. A staff engineer's job is not to win the spreadsheet argument. It is to make technical consequences legible before an executive or product owner chooses a path.
Protect the strategy from new exceptions
The stop-doing list can fail a week after approval. Someone asks for “one small change” to the frozen system. Another group needs an exception to the new standard. A third wants support at the old level because nobody told them the policy changed. Each request is understandable; together they restore the workload the strategy was supposed to remove.
Give exceptions an explicit path. Ask whether the request addresses safety, a committed customer obligation, or a new business decision. If it does, show the capacity it will displace and get the appropriate owner to choose. If it does not, route it to the supported path or decline it. The Exception Backlog Is a Developer Platform Roadmap explains why repeated exceptions deserve a product decision, not endless informal accommodation.
Review the list alongside the strategy's evidence. Did the new work get the focused time promised? Did the old workload actually shrink? Are users migrating, or are they silently maintaining both paths? If the expected capacity never appeared, revise the plan. Do not call the strategy successful because the new project launched while the original obligations continued to burn out its owners.
A credible strategy has a subtraction column
Technical strategy is a set of choices about where engineering effort will create the most value. A roadmap is only the addition column. The subtraction column makes the choice honest.
Before approving a new bet, ask what stops, what remains essential, who owns the transition, and what evidence will tell you the decision was wrong. If no one can answer, the organization is promising output without choosing capacity. Put the stop-doing list on the same page as the ambition, and give people permission to hold the strategy to both halves.
For more practical engineering leadership and developer productivity work, visit Slaptijack.
