Chapter 6: Why Have We Stopped?
tsep unblocking escalation project-management migrations sunk-cost definition-of-done
Status: Notes complete
Overview
Projects stop. They get blocked, they lose direction, they quietly drift toward declaring victory prematurely. Chapter 6 is a diagnostic and resolution guide for all these failure modes. As the project’s driver, a staff engineer is responsible for identifying why a project has stopped and getting it moving again.
The chapter also notes that you can apply these skills to projects you’re not leading — a small investment of your organizational knowledge and relationships can sometimes unblock a project in a single conversation. Choose these interventions carefully though; doing too many of them fills your time and leaves no space for your own accountable work.
Core Concepts
Four unblocking techniques: The universal toolkit for all types of blockages — understand & explain, make the work easier, get organizational support, make alternative plans.
Rollup: A concise summary of all information on a topic in one place, including explicit interpretations and conclusions. Creates clarity from scattered information.
“Beware of Leopard” projects: Solutions that exist but are impossible to discover — named after a Douglas Adams quote about plans hidden in a cellar. Created when teams build something and consider the documentation milestone done, but users can’t find it.
Definition of done: Explicit agreement on what state a feature or project must be in before it can be declared complete. Includes deployment, documentation, monitoring, and user validation — not just code being written.
Sunk cost fallacy: The tendency to continue a failing project because of prior investment, even when stopping would be the better decision.
The Four Universal Unblocking Techniques
Regardless of the type of blockage, these four techniques apply:
| Technique | What it means |
|---|---|
| Understand and explain | Debug what’s happening; make sure everyone has the same understanding |
| Make the work easier | Reduce what other people need to do; remove friction from the path forward |
| Get organizational support | Demonstrate value to get priority; escalate constructively if needed |
| Make alternative plans | Accept the blockage and find a different way to succeed |
Being Blocked
Blocked by Another Team
Three root causes of team-level blocks:
| Cause | Description |
|---|---|
| Misunderstanding | The team doesn’t know there’s a dependency, a deadline, or what exactly is needed |
| Misadventure | Life happened — someone left, the team is overloaded, or they have their own downstream block |
| Misalignment | Your project is lower priority for them than their own work |
Resolution path:
- Have a synchronous conversation (not just emails)
- Explain the business impact, the deadline, what specifically you need
- Ask if you can reduce the scope of your request
- If unresolved, escalate to a mutual leader — without complaining, just presenting facts
Blocked by a Decision
The decision you need can’t be made because:
- The decision-maker doesn’t understand the question well enough to answer
- The decision-maker is waiting on input from someone else
- Multiple stakeholders disagree and no one wants to resolve it
Resolution:
- Reframe the question using pictures, examples, or user stories
- Help the decision-maker understand the impact on their goals, not yours
- Offer to make your best guess and document it if waiting is too costly
- Accept that some decisions indicate the project can’t proceed in current form
Blocked by a Single Button Click
You’re waiting on an approval or configuration change that takes 10 minutes — but the team that needs to do it hasn’t done it. Remember: their work looks different from their side. They have many requests, they need lead time, and when they approve your request they may be accepting accountability for the outcome.
If you need to skip the queue:
- Ask politely with an apology for the short notice
- Make the request as easy to approve as possible (clear context, minimal reading)
- If you get help, thank the team publicly
- Escalate only as a last resort, and mitigate the relationship damage afterward
Blocked by a Single Person
The assigned work is sitting on one person’s desk. The real reasons are often not the stated ones — the person may be intimidated, unclear on requirements, stressed personally, or secretly deprioritizing your project.
Resolution:
- Learn what’s actually blocking them before trying to solve it
- Break the work into smaller steps; help them get started
- Pair with them — sometimes sitting together for an hour gets past the psychological wall
- Escalate to their manager only if the project is genuinely at risk
Blocked by Unassigned Work
The work nobody owns. Everyone in related teams has opinions about it; none of them have committed to doing it.
This is an organizational problem, not a technical one. More designs and planning don’t help until someone owns the work.
Resolution:
- Write a rollup — collect all facts, interpret them explicitly, surface conclusions that haven’t been stated yet
- Advocate loudly for an owning team
- Offer to mentor or advise whoever takes it on
- If no owner materializes, accept the project is blocked until the organization makes it a priority
Key insight: If you can’t solve the organizational problem, no amount of technical work helps. The impassable ridge is the lack of staffing, not the technical challenge.
Blocked by a Migration (Huge Crowd)
You need every team using an old system to migrate to a new one. Not all of them will cooperate.
Resolution:
- Tell both sides of the story: why the migration matters AND why it’s hard for the teams being asked to migrate
- Do as much work as possible for the migrating teams (automate steps, provide specific instructions for each team)
- Make the new way the default; update documentation and examples to remove references to the old way
- Show a progress graph — social proof motivates remaining teams
- Consider making “last out” teams own and maintain the old system
- Escalate to organizational goals only if the migration genuinely justifies it
Being Lost
Don’t Know Where You’re Going
A large group with a large mandate but no shared direction. Everyone has opinions; nobody can agree on what the goal actually is.
Solutions:
- Clarify roles first: Get explicit authorization to be the decider; or get your sponsor to confirm it
- Choose a strategy before discussing implementation: No implementation details until the problem is defined
- Choose a problem: Any real, specific problem is better than the amorphous mandate
- Choose a stakeholder: Solve for one team completely before trying to solve for everyone
Don’t Know How to Get There
The destination is clear but the path isn’t. You’re technically stuck.
Solutions:
- Articulate the problem in writing — precision reveals constraints
- Revisit your assumptions — are you artificially constraining the solution space?
- Take time away from the problem; sleep on it
- Schedule dedicated deep work time with optimal conditions
- Look for prior art: other teams, other industries
- Try a different angle (technical → organizational, organizational → technical)
- Ask for help — amortize the learning from others who’ve solved similar problems
Don’t Know Where You Stand
You’re not sure if the project is still supported or even still happening. Signs: sponsor is less engaged, project isn’t mentioned in all-hands, teammates talk about it as “if” not “when.”
It might also just be that no news is good news — a project that’s on track often gets less attention.
Solutions:
- Directly ask your manager or sponsor: “Is this project still on track?”
- Clarify your role explicitly — being an “unofficial lead” means you’re not the lead
- Ask for the organizational recognition you need to do the work
- If the team is demoralized, deliberately refuel: new milestone framing, new team member, “welcome to Phase 2”
Done but Not Really Done
Code Complete but Not Usable
The classic “it’s done… but you can’t use it yet.” The code is written, the PR merged, the milestone marked green — but it’s not deployed, not documented, not monitored, not approved for production.
Root cause: Engineers think of “done” as “code written.” Users think of “done” as “I can use this.”
Resolution:
- Define “done” explicitly before starting: what must be true before we declare success?
- Use a definition of done checklist (deployed, tested, documented, monitored, user-validated)
- Celebrate landings (users using it), not launches (code merged)
Waterhouse insight: “Nobody wants to use software. They want to catch a Pokémon.” The software is a means to an end.
Nobody Is Using It
The solution exists and works — but users don’t know about it or can’t find it. The “Beware of Leopard” pattern: the information exists, but it’s hidden in a cellar behind a locked door with no signage.
Solutions:
- Tell people it exists — repeatedly
- Make it discoverable (link from everywhere users look; set up shortlinks for all plausible names)
- Show testimonials from early adopters
- Understand objections and show you’ve addressed them
- “Harvest” your crop — stop after planting; take it to people
Shaky Foundation
Users can use it, but the engineering quality is poor — untested, unscalable, or architecturally hacked. The team has moved on; the technical debt is frozen in place.
Key insight: There is no such thing as a temporary solution. Whatever state the code is in when the team moves on is the state it will be in forever, or until an extraordinary effort fixes it.
Solutions:
- Set quality culture by asking for tests, monitoring, and documentation consistently
- Make cleanup part of user stories, not separate “tech debt” tickets
- Use fix-it weeks, 20% time, or dedicated rotation slots for quality work
- Frame quality improvements in terms of user impact, not technical purity
Deliberate Endings
Not all project stops are failures. Four legitimate ways to end:
| Ending | Description |
|---|---|
| Done enough | The project has reached the point of diminishing returns; declare success and move on |
| Wrong journey | The project cannot achieve its goal; stop before sinking more cost. Write a retrospective. |
| Canceled | The organization has decided to stop it. Handle feelings, communicate directly with the team, document what was learned, support team members’ transitions. |
| Victory | You actually finished. Double-check you’ve really reached the destination, then celebrate properly. |
Key Takeaways
- Four universal unblocking techniques work across all types of blocks: understand & explain, make work easier, get organizational support, make alternative plans.
- Organizational blocks (unassigned work) require organizational solutions — more technical work doesn’t help until someone owns the problem.
- Half-finished migrations need both sides of the story told and maximum friction-removal for migrating teams.
- Being lost (lost direction, lost path, lost standing) has different solutions for each type.
- “Done” must be defined before work starts; code complete ≠ user can use it.
- The Beware of Leopard pattern: solutions that exist but nobody can find.
- There is no temporary solution — quality at end of project is quality forever.
- Stopping deliberately (done enough, wrong journey, canceled) is not failure when done with clear reasoning.
Related Resources
- ch05-leading-big-projects — Project structure that prevents some of these failure modes
- ch04-finite-time — Chapter 6 references Chapter 4’s warning about too many side quests
- ch07-role-model — Reliability and ownership as individual attributes