The Slow Death
There is a particular kind of lie that projects tell themselves. It goes like this: we are still working on it. The meetings are still in the calendar. The Jira board still has tickets in "In Progress." The weekly status update is still going out. Nobody has said the project is cancelled. Therefore, the project is not dead.
But if you look closely, nobody shipped anything last week. Or the week before. The last real decision was made six weeks ago. The team has been in a loop of "we need to align on X before we can do Y" for longer than anyone wants to admit. And the people who were most excited about this project in January have quietly redirected their energy to other things.
This is a stalled project. Not a cancelled project. Not a failed project. A stalled project — one that has stopped moving without anyone deciding to stop it.
It is one of the most common and most destructive states in large-scale software work. It is more damaging than an outright cancellation because it consumes resources — people's time, energy, hope, and trust in leadership — without producing anything. People wake up every morning and do the work, and nothing gets closer to done. That experience, over weeks and months, is deeply demoralizing. It makes your best engineers want to leave.
A company decides to replace its legacy data pipeline. Six months into the project, four engineers are assigned to it. Every Friday there's a status update that says "on track." But in reality, the team has been debating the same schema design decision for three months. The person who needs to sign off on it is "too busy" to get in a room. Nobody has written that to the weekly update, because nobody wants to be the one who says the project is in trouble.
Twelve months in, a new VP asks why this hasn't shipped yet. There is no good answer. The engineers who know the most have moved on. The ones still on the project are demoralized. The original problem the pipeline was meant to solve has gotten worse. The project is eventually restarted from scratch with a new team — who then get stuck on the same schema design question six months later.
You might be laughing because you have seen this exact story. The names change, the technology changes, but the structure repeats. The goal of this chapter is to make sure you can see the pattern before you are twelve months in.
What Stall Actually Looks Like
The tricky thing about a stalled project is that it does not look stalled from a distance. Activity continues. People are busy. Meetings happen. But there is a specific difference between a project that is moving slowly and one that has actually stalled.
A slow project is producing output at a lower rate than expected. A stalled project is not producing output at all — it is producing motion that mimics output. Think of a hamster wheel. There is real physical movement. Energy is being spent. But the wheel is not connected to anything. Nothing is closer to done when the hamster stops.
The Signals
These are the actual behavioral signals that tell you a project has stalled. Not all of them appear at once. Two or three appearing together should put you on alert. Five or more is a crisis you have been ignoring.
- The same decisions keep resurfacing in meetings. You discussed the right approach for the auth layer three weeks ago. Last week you discussed it again. This week the calendar has another "alignment meeting" on auth. A project that is moving would have made that decision and built past it by now.
- The "blockers" section of your status update is longer than the "progress" section. One or two blockers is normal. A list of five blockers that has been carrying over for three weeks with no resolution is a sign that the project has no one actively removing those obstacles.
- Key people start missing meetings. This is the one people notice but rarely say out loud. The senior engineer who was the most excited about this project has stopped showing up to the weekly sync. The PM is now double-booking the slot. Unconsciously, the people with the most options are starting to disengage. They have already assessed the situation. They are just too polite to say it.
- Nobody can articulate the next concrete deliverable. Ask anyone on the team: what specifically will be done by the end of the sprint? Vague answers like "we're working on the platform layer" are a red flag. A project that is moving always has a next concrete thing that will be shipped or decided.
- The plan keeps getting updated without a shipped output. If the project plan has been revised four times in the past eight weeks and nothing has been demoed or deployed, the planning is a substitute for doing, not a preparation for it.
- There is a single dependency that has been "almost resolved" for more than two weeks. Dependencies do not stay in "almost resolved" for two weeks unless nobody is actually driving them to closure. Something has frozen, and the project has frozen around it.
- The team has stopped escalating problems. When things are going wrong but nobody is raising them, it means people have privately concluded that raising problems leads nowhere. This is one of the most dangerous signals. It means your feedback loop is broken.
Leaders often confuse activity with progress. A team that is active — sending messages, attending meetings, updating tickets — looks healthy in the reports. The real question is whether the state of the world is changing because of their work. Is the feature closer to launch? Is the migration closer to complete? Is the decision made? If the answer is no, it does not matter how busy people look.
The Five Causes of Stall
Stall always has a cause. It does not happen spontaneously. Something specific froze the project, and until you identify that specific thing, any attempt to restart will fail — or will temporarily unstick things only for the project to stall again in the same place.
After watching dozens of projects stall across different companies, five root causes show up over and over. They feel different from the inside, they require different fixes, and misdiagnosing one for another is one of the most common mistakes experienced engineers make.
Direction Rot
Direction rot happens when the original clarity about what the project is for quietly erodes over time. It does not happen all at once. It happens in a hundred small moments: a stakeholder adds a requirement in a side conversation, someone decides to "while we're in here" add a feature, the company's priorities shift by 15 degrees in Q3, someone new joins and asks a question nobody has a clean answer to anymore.
None of these moments feel like a crisis. But after six months, the team is working from eight different mental models of what success looks like. The backend engineer thinks the goal is to reduce latency. The product manager thinks it is to unlock a new market. The VP thinks it is a cost-reduction play. They are all doing real work, but the work is no longer aimed at the same target.
Direction rot is the sneakiest kind of stall because it looks like productive disagreement from the outside. The debates in the meetings are real. People are genuinely trying to do the right thing. But because the fundamental goal is no longer shared, every decision triggers a meta-debate about what the project is actually for. Nothing gets decided because deciding would require admitting that the direction was unclear all along.
The tell: If you ask five people on the project separately "what does success look like at launch?" and you get five meaningfully different answers, you have direction rot. It is not a disagreement about approach. It is a disagreement about destination.
Decision Debt
Decision debt is what accumulates when a project keeps moving forward while leaving key decisions unresolved. The team decides to "park" a contentious question and come back to it. They make progress on the parts they can agree on. But the parked decisions pile up, and each one blocks more and more of the project as the project matures.
Eventually the project arrives at a point where it cannot ship anything because shipping requires resolving the decisions that were parked. And those decisions are now much harder to make because a lot of code was written on top of assumptions that may turn out to be wrong.
The most common version of decision debt involves a single unresolved question that the team dances around for months. What data model do we use? Which team owns the API contract? Do we support multi-tenancy in version one? These questions feel too risky to decide without more information, so they stay open. But the longer they stay open, the riskier they become to decide, because more and more of the project depends on the answer.
The tell: You can describe the decision that needs to be made in a single sentence, you know who needs to make it, and you could have made it three months ago with the information you had then. The decision has not been made because making it requires someone to take a stand, and nobody wants to be wrong.
Energy Drain
Every project has a small number of people who provide most of its energy. They are not always the most senior. They are the people who think about the project outside of work hours, who proactively unblock things, who pull the rest of the team forward through enthusiasm as much as authority.
When those people leave — through a team change, a promotion, burnout, or disillusionment — the project loses its engine. What is left is a group of people doing what they are told, completing their tickets, attending their meetings. But the driving force is gone. Nobody is making judgment calls. Nobody is connecting the dots. The project moves in a technically correct but directionless way until it stops moving at all.
Energy drain is especially insidious because it often follows a period of conflict or disappointment. The person who cared the most finally got the wrong decision forced on them one too many times. They did not quit the company. They just quietly stopped investing in this particular project. From the outside it looks like the project is running fine. The same names are still in the meeting invite. But the energy that held it together is gone.
The tell: Ask yourself who on this project would be visibly upset if it was cancelled tomorrow. If the answer is "I'm not sure anyone would be that upset," you have an energy drain problem. Projects need people who care too much, not just people who care enough.
Invisible Blockers
Not all blockers appear on the blockers list. Some blockers are things people know but have not said in a meeting yet: a dependency on a team that has privately deprioritized this project. A technical assumption that one engineer knows is wrong but has not raised because they are worried about the reaction. A budget question that is stuck in finance but does not appear on any project tracking doc. A key vendor who said they could do something but cannot.
These invisible blockers are sometimes invisible because the person who knows about them is afraid to surface them. The junior engineer knows the architecture will not scale as planned, but they are new and do not want to be seen as obstructing the project. The PM knows the business case numbers were inflated but raising it now feels like career suicide.
More often, invisible blockers are invisible simply because nobody has been asking the right questions. The project moves forward under a set of assumptions, and nobody has explicitly checked whether those assumptions still hold. The team finds out three months later, when it is much more expensive to change course.
The tell: The project's stated blockers are all "in progress" but nothing is actually resolving. There is an uncomfortable undercurrent in team discussions that does not match the cheerful status updates. Ask the most honest person on the team, privately: "Is there anything stopping this project that we have not said out loud?" Then listen carefully.
Political Freeze
Political freeze happens when the project requires two or more people — or two or more teams — to agree on something, and those parties are not aligned in a way that makes agreement likely. It is different from decision debt because the decision is not just hard to make. It is hard to make because of the organizational dynamics around the decision, not the technical complexity of the decision itself.
The clearest form of political freeze involves two senior leaders who are not aligned. Both teams involved in the project know this. Neither team wants to be the one to raise the conflict because that would mean publicly acknowledging that leadership is not aligned, which feels politically dangerous. So the project bobs up and down in status meetings while everyone waits for the org chart to resolve itself — a merger, a promotion, a departure, anything that changes the political landscape and makes it safe to move.
A more subtle form involves two peer teams with overlapping ownership. Team A owns the data layer, Team B owns the API layer, and the project requires a change that touches both. Neither team wants to cede decision-making authority. Both teams are polite about it. Nobody escalates. The meetings keep happening, and the project keeps not shipping.
The tell: When you draw the decision that needs to be made on a whiteboard, two names or two team logos always end up on it, and those parties have a history of not agreeing. The decision keeps getting "kicked up" to a joint meeting that never produces a resolution.
How to Diagnose Your Stall
Knowing the five causes is only useful if you can figure out which one you are dealing with. The symptoms overlap. A project with direction rot also tends to develop decision debt. An energy drain often follows a political freeze. You need a systematic way to cut through the noise and identify the root cause.
The diagnostic process has two phases: observation and conversation.
Phase 1: The Observation Audit
Before talking to anyone, spend two hours reviewing what has actually happened on the project in the last four weeks. Read the status updates. Look at what shipped. Look at the meeting notes. You are trying to answer one question: where did work arrive at a decision point and not proceed?
Almost every stall has a specific, identifiable point where work arrived at a junction and then stopped instead of turning either left or right. Find that junction. It might be a specific ticket that has been open for six weeks. It might be a design doc that received comments but never reached a conclusion. It might be a meeting that was scheduled for a decision and produced only "need to discuss further." Find the frozen junction and you have found your stall point.
Phase 2: The Three Conversations
Once you know where the project stopped, you need to understand why. Have three conversations — not a group meeting, not a survey, just three separate one-on-one conversations with people who have different vantage points on the project.
Conversation 1: The engineer doing the work. Ask them: "What is the most important thing that needs to happen for this project to move forward?" Engineers who are closest to the work usually know exactly what is blocking them. They often will not say it in a group setting because it sounds like a complaint about a stakeholder. In private they will tell you the truth.
Conversation 2: The most frustrated stakeholder. Find the person who seems most disengaged or most impatient with the project's progress. Their frustration is information. Ask them: "What were you expecting to see by now that you have not seen?" Their answer will tell you whether the root issue is about expectations (direction rot) or delivery (invisible blockers or decision debt).
Conversation 3: The person with the most information about org dynamics. This is usually not the most senior person. It is the person who has been around the longest, who attends the most cross-team meetings, who has relationships with all the relevant teams. Ask them: "Is there anything in the org that is making this project hard to move forward on?" They will tell you about the political freeze, if one exists.
| Cause | What You Hear in Conversations | Fix Direction |
|---|---|---|
| Direction Rot | Different people describe success differently. "We keep re-litigating scope." | Rewrite and re-ratify the goal statement |
| Decision Debt | "We need X decided before we can do Y." The same blocker keeps appearing. | Force the specific decision; own the outcome |
| Energy Drain | "Everyone is busy." Low energy in meetings. Key people are hard to reach. | Inject a champion; reconnect to why it matters |
| Invisible Blockers | "We're making progress." But nothing ships. Vague optimism without specifics. | Run a structured assumption audit |
| Political Freeze | "We're waiting on alignment." The same two parties keep not aligning. | Escalate, or design around the dependency |
You will often find more than one cause. That is fine. Address them in order of severity. Direction rot is almost always the most important to fix first, because no other fix will hold while people disagree about where they are going.
Restarting Momentum
Once you have diagnosed the cause, you need to restart the project's momentum. This is where most people make a mistake that undoes all the diagnostic work they just did.
Skip the Big Reset Meeting
The instinctive response to a stalled project is to schedule a big reset meeting. Get all the stakeholders in a room (or on a call). Acknowledge that the project has not been moving. Rebuild alignment. Recommit to a new timeline.
This rarely works. Here is why.
A big reset meeting announces to everyone that the project was in trouble. That is fine. But it also puts all the reasons for the stall on the table simultaneously, in public, with everyone present. This activates defensiveness. The stakeholders who contributed to the freeze start protecting themselves. The engineers who were frustrated start venting. The meeting consumes three hours and produces a new set of commitments that nobody believes and that will be just as hard to keep as the last set.
More importantly, a reset meeting treats the stall as a motivation problem — a failure of commitment. But as we established in the diagnosis section, stall is never a motivation problem. It is a structural problem. The team was not insufficiently committed to the project. Something specific broke down. A motivation meeting cannot fix a structural problem.
What Does Not Work
- Scheduling a 3-hour all-hands reset meeting
- Asking everyone to recommit to the timeline
- Creating a new project plan before fixing the root cause
- Adding more people to a confused project
- Increasing meeting frequency
- Sending a strongly-worded email from a VP
What Actually Works
- Identifying and resolving the single root cause
- Making one concrete decision in the next 48 hours
- Shipping something small — anything — to break the inertia
- Reducing scope until forward motion is possible
- Removing the human bottleneck, not around it
- Reconnecting the work to a concrete and near-term outcome
The One-Move Restart
The most reliable way to restart a stalled project is what I call the one-move restart. The idea is simple: instead of trying to fix everything at once, identify the single move that will, by itself, cause the project to start moving again. Make that move. Then use the momentum from that move to make the next move.
This sounds obvious but is psychologically hard. When a project has been stalled for weeks, there is enormous pressure to "fix it" comprehensively. You want to address all the underlying issues, rebuild alignment on all dimensions, produce a credible new plan, and restore confidence all at once. That ambition is itself a stall mechanism. It creates a pre-launch checklist for the restart that is so long that the restart never launches.
The one-move restart asks a simpler question: what is the smallest thing I could do in the next 48 hours that would cause the project to be visibly moving by the end of the week?
The answer will vary by cause:
- For direction rot: Write a one-paragraph goal statement and get two key stakeholders to sign off on it by end of day tomorrow. Not three paragraphs. Not a full project brief. One paragraph. "We are building X so that Y happens, and we will know we succeeded when Z is measurable." Force the conversation that surfaces the disagreement, resolve it in writing, and circulate it.
- For decision debt: Pick the most load-bearing unresolved decision. Call a one-hour meeting with only the decision-makers. Go in with a recommendation — your own recommendation, informed by your analysis — and say "we are making this decision today, in this meeting. Here is my recommendation. I want your input, but we are leaving with a decision." If you get pushback, ask: "What would you need to see to be comfortable deciding today?" Then produce that thing.
- For energy drain: Find or become the project's new champion. Reach out to the person on the team who used to care the most and find out what dimmed their enthusiasm. Often there is one specific thing that disappointed or frustrated them. Address that thing directly, in a one-on-one conversation, before trying to restart anything else. One re-energized person who was previously checked out is worth more to the restart than five new participants.
- For invisible blockers: Run a 45-minute assumption audit. List every assumption the project is currently operating under. For each one, ask: is this still true? Who has checked this recently? You will find, almost every time, one assumption that has been silently false for weeks or months. Surface it, discuss it, and decide what to do about it. Teams are almost always relieved when invisible problems become visible ones, because visible problems can be solved.
- For political freeze: Find the lowest point in the hierarchy at which the alignment question can be resolved and escalate to exactly that level. No higher, because going over people's heads creates new political problems. Escalation should be framed not as "they are not cooperating" but as "we have a decision that requires a call from someone with authority over both teams." That framing is accurate, does not assign blame, and gives the decision-maker something specific to do.
When restarting a stalled project, commit to making something concrete happen within 48 hours of your diagnosis. Not a meeting to plan the restart. An actual output: a signed-off goal statement, a made decision, a shipped prototype, a resolved blocker. The 48-hour window forces you to pick something small enough to actually do. It also tests whether your diagnosis was right — if you cannot produce a concrete output in 48 hours, you probably identified the symptom instead of the cause.
Reclaiming Clarity About the Goal
If your stall is rooted in direction rot — and this is very common in projects that have been running for more than six months — the restart work is fundamentally about rewriting the project's goal statement and getting explicit sign-off on it from the people who matter.
The goal statement is not a vision document. It is not a manifesto. It is a short, specific, falsifiable description of what you are building, for whom, and how you will know if it worked. It needs to be specific enough that if two engineers read it, they would make the same architectural decision when faced with a choice.
A bad goal statement: "Improve the data pipeline to be more scalable, reliable, and cost-effective."
A good goal statement: "Replace the batch nightly pipeline with a streaming pipeline that processes events within 60 seconds of ingestion, handles 3x current peak volume without manual intervention, and reduces compute cost per event by at least 40%. We are not building self-serve access for analysts in this phase."
Notice what the good version does. It has a specific measurable outcome (60 seconds, 3x volume, 40% cost). It explicitly states what is not in scope. That "we are not" sentence is as important as the rest of it. Direction rot often accelerates because people keep adding things to the scope while nobody writes down what is excluded.
Once you have the goal statement, send it to every stakeholder with the subject line: "Project goal statement for your sign-off." Ask them to reply with either "I agree" or "I disagree with X, and here is the alternative I would support." This email is a forcing function. It turns implicit disagreements into explicit ones, which is the only way to resolve them.
Making Progress Visible Again
When a project has been stalled for a while, the team's confidence in the project's ability to ship has eroded. Even after you fix the root cause, that erosion does not reverse automatically. You need to actively demonstrate that the project is moving again by making progress visible, frequently, to the people who matter.
The fastest way to make progress visible is to ship something small and concrete within the first week of the restart. It does not have to be the most important part of the project. It has to be something real that did not exist before: a demo that works, an API endpoint that is live, a migration that completed on a subset of data, a decision that was made and documented.
The small ship does something psychologically important. It reminds everyone — including the team — that this project can ship things. It converts "we are planning to restart" into "we have already restarted." It gives you something concrete to point to in the next status update. And it filters out the stakeholders who were waiting for an excuse to withdraw their support: they will often respond positively to a concrete output even if they were skeptical about the restart.
"Momentum is not restored by a meeting. It is restored by a shipped output that proves motion is possible again."
After the first small ship, establish a cadence. If the project ships something concrete every week — even small things — confidence restores quickly. The weekly status update transforms from "here is our current state of alignment" to "here is what shipped this week." That transformation changes how stakeholders perceive the project's health more than any amount of communication about plans and timelines.
When to Kill a Project
Not every stalled project should be restarted. Some projects should be killed. This is one of the most important — and most avoided — decisions in large-scale project work. The avoidance is understandable. Killing a project feels like failure. It can feel like abandoning the people who worked on it. It involves conversations that nobody enjoys having.
But failing to kill a project that should die is worse. It keeps resources tied up on something that will not deliver value. It demoralizes the team. It wastes the months that could be spent on something better. And it destroys credibility — both the team's credibility for not escalating, and leadership's credibility for not acting.
Signs a Project Should Die, Not Restart
There is a practical difference between a project worth restarting and one that should be ended. The restart is right when the core problem the project is solving is still important, and the stall was caused by fixable structural problems. The kill is right when one or more of the following is true:
- The underlying problem no longer exists or is no longer important. This happens more often than people admit. The business landscape changes, a new tool solves the problem better, or a competitor did something that made the whole project irrelevant. The right response is to acknowledge it and move on, not to keep going out of sunk-cost reasoning.
- The project requires an alignment between stakeholders that is not achievable in the current org structure. Some political freezes can be escalated out of. Others cannot. If the project requires two teams to deeply collaborate and those teams have a structural reason not to — competing incentives, a history of conflict, leaders who will not align — you can unfreeze the project for a week but it will refreeze the following week. A project that requires an org change to succeed is not a project you can fix by being smarter about execution. Fix the org first, or design the project to not need that alignment.
- The original business case has been invalidated. Cost projections were wrong. Volume assumptions did not hold. The customer research that justified the project showed something different when done with a larger sample. If you were starting the project today with the information you now have, you would not start it, the right thing is to stop it.
- The engineering team has no remaining belief that it will ship. This is a hard one to assess because teams are often publicly optimistic even when privately pessimistic. But if the people doing the work have genuinely concluded — not because they are tired, but because they have looked at the technical reality — that this project will not ship in a form that is useful, that assessment deserves respect. Experienced engineers are not usually wrong about this.
- The opportunity cost is now obvious. You had a team of four engineers working on this for ten months. In that same ten months, three other important projects were not started because the people were occupied. If starting the project today would mean explicitly choosing it over those other three projects, would you make that choice? If the honest answer is no, you have your answer about whether to keep going.
The most common reason projects that should die do not die is the sunk cost fallacy: "We have already invested so much in this, we can't stop now." This is one of the most well-documented cognitive biases in human decision-making, and it affects experienced leaders and engineers as much as anyone else. The money and time already spent are gone regardless of what you decide. The only question is whether spending more will produce something valuable. Evaluate that question on its own merits.
Killing a Project Gracefully
If you conclude that a project should be cancelled, the way you cancel it matters enormously — both for the people who worked on it and for the organization's ability to make good decisions in the future. A badly handled cancellation teaches people that admitting failure is dangerous. A well-handled cancellation teaches people that honest assessment is valued and that stopping a bad investment early is a sign of good judgment, not weakness.
The following sequence works well:
Write down the reasons clearly before any conversation
Articulate in writing exactly why the project is being cancelled. Be specific. "The business case no longer holds because X" is better than "priorities have changed." Writing it down forces clarity, prevents the decision from being relitigated in the announcement meeting, and gives you a document to share so that people hear the real reason, not a rumor version of it.
Tell the team before you tell anyone else
The engineers and PMs who worked on this project should hear about the cancellation directly from you, before they hear about it from a calendar invite being removed or an all-hands announcement. This is basic respect. It is also practically important: you want to understand how they are feeling and what questions they have before those feelings and questions surface in a public setting.
Honor the work without pretending it succeeded
There is a dishonest version of project cancellation that says "we learned so much from this, it was valuable even though we did not ship." This is sometimes true and often false. The team knows the difference. What genuinely honors the work is identifying specifically what was built, what was learned, and how that knowledge will be used. If there is code that can be reused, name it. If there is a technical insight that will inform the next project, write it down in a post-mortem.
Give people a next thing immediately
One of the worst things about a project cancellation is the feeling of purposelessness that follows it. What do I work on now? Before you cancel the project, have an answer to this question for every person on the team. It does not have to be perfectly planned. It has to be real and available immediately. People recover from disappointment much faster when they have something to do with their energy.
Run a lightweight post-mortem, not a debrief
A post-mortem focuses on what the organization can learn and do differently. A debrief focuses on what happened and who did what. You want the former, not the latter. A good post-mortem on a cancelled project asks: Why did this get as far as it did before we caught the problem? What signals were there earlier that we missed or ignored? What would we change about how we launched this project? Those questions are about organizational learning. They are worth an hour of everyone's time.
A senior engineering leader at a large company was running a major platform migration. Twelve months in, it became clear that a fundamental architectural assumption was wrong — the latency requirements of the new system were incompatible with the storage technology they had chosen, and no amount of engineering could bridge the gap without a complete rewrite.
He did not schedule a big meeting to discuss options. He wrote a two-page document describing what had been discovered, why it changed the calculus, and what he recommended. He shared it with the team before sharing it with anyone else. He acknowledged in the document that he had personally advocated for the storage technology choice and that he now believed it was wrong. He proposed cancelling the migration and described a different approach.
The cancellation was announced with that document attached. The team's reaction was almost entirely positive — not because they were happy the project was cancelled, but because they had been watching the latency problem grow for months and were relieved that someone with authority had finally looked at it clearly. The decision earned more trust than the original project had.
Chapter Summary
Stalled projects are not a niche edge case. They are one of the most common states in large-scale project work. Understanding them — being able to recognize them early, diagnose their cause accurately, and respond correctly — is one of the highest-leverage skills a principal engineer can develop.
The core ideas from this chapter are:
- Stall is different from slow. A slow project produces less than expected. A stalled project produces motion that looks like progress but is not. Learn to tell the difference.
- Stall always has a specific structural cause, not a motivation cause. The five causes are direction rot, decision debt, energy drain, invisible blockers, and political freeze. Each requires a different fix.
- Diagnose before you act. Two hours of observation and three conversations will tell you more about why your project is stalled than any amount of planning.
- Skip the big reset meeting. Momentum is restored by a specific structural fix followed by a concrete shipped output, not by a recommitment ceremony.
- The one-move restart: find the single action that will cause visible forward motion in 48 hours. Do that action. Use its momentum to make the next action.
- Some projects should be killed. The signals are specific: the underlying problem is gone, the alignment is structurally unachievable, the business case has been invalidated, the team does not believe it will ship, or the opportunity cost is now obvious.
- How you kill a project matters. Do it with clarity, honesty, respect for the work, and a next thing ready for the people involved. Done well, cancellations build trust. Done badly, they make it harder to make good decisions in the future.