Your team hasn’t shipped anything meaningful in weeks.
Nobody is openly panicking. People look “busy”. There are meetings, docs, tickets, maybe even a burndown chart that looks sort-of fine. But when you zoom out, nothing important is reaching production. The roadmap is moving in slides, not in reality.
Before you decide this is a “motivation problem” or start rewriting the process from scratch, it helps to slow down and read the silence.
This is an essay about how to look and what to ask when a capable team stops shipping.
Step 1: Separate symptoms from causes
Most of the loud signals are just symptoms:
- Lots of meetings, few decisions
- PRs that sit open for days
- “Almost done” tasks that never close
- People saying “it’s complicated” but struggling to explain why
Treat these as clues, not as root causes.
A useful starting frame:
“This is a normal response to something in the environment, even if I don’t see that something yet.”
Instead of jumping to solutions (“we need more standups”, “we should estimate better”, “we need stricter deadlines”), spend a bit of time mapping the environment your team is operating in.
Some quick ways to do that:
- Calendar archaeology – how much time is in meetings vs deep work?
- Work surface scan – how many tickets / PRs are in “in progress”?
- Decision trail – for the last 2–3 big bets, can you point to the decision, the decider, and the tradeoffs?
You’ll usually find hints of the real problem hidden there.
Step 2: Look at the work, not just the people
When delivery slows, it’s tempting to zoom straight into individual performance. But most of the time, the work is the problem, not the humans.
Some questions that help:
1. Is the work too chunky?
If every task is a multi-week monster, you’ll feel busy but ship nothing.
Red flags:
- Tickets that say “Build v1 of X” with no smaller steps
- A “phase 1” that is basically the whole project
- Work that can’t be demoed until the very end
If you can’t see a path to a visible change in 3–5 days, the work is probably too big.
2. Is the work too scattered?
The opposite problem: everything is split, nothing is aligned.
Red flags:
- Everyone is working on unrelated mini-projects
- No shared “this is the thing we’re trying to move this month”
- Context switches every day between 3–4 priorities
Here, the team isn’t blocked technically, they’re blocked by fragmentation.
3. Is the work too vague?
People are bouncing off the edges of ambiguity.
Red flags:
- Specs that read like vibes, not decisions
- “We’ll figure it out as we go” but nobody owns the figuring-out
- Stakeholders with very different mental pictures of “done”
In this mode, a lot of energy goes into reconciling different expectations that were never made explicit.
Step 3: Listen for fear, not just status
Once you’ve looked at the work, talk to people — 1:1 and in small groups.
You’re not asking “are you productive?”
You’re asking “what feels risky or unclear to you right now?”
Some questions that often surface the real blockers:
-
“What are you avoiding touching?”
There is almost always a part of the system, organization or problem that people are quietly avoiding. That’s where the drag lives. -
“If we ship the wrong version of this, what’s the worst that happens?”
Sometimes the team has internalized a huge downside risk (“if we break this, we’ll be paged for days”) that you’ve never explicitly discussed. -
“What feels unfair at the moment?”
People will slow down rather than step into situations that feel structurally unfair: unclear expectations, uneven on-call, constant rework from upstream chaos.
Pay attention to emotional words: “exhausting, pointless, whiplash, scary, no control”. They’re often more diagnostic than any metric.
Step 4: Check the surrounding system
Teams don’t operate in a vacuum. They can be stuck because of forces outside their direct control.
Some common patterns:
1. Stakeholder turbulence
- Priorities change every week
- Every senior person has a different pet ask
- The team is saying “yes” to all of it
Result: nobody wants to commit to a path, because history says it will change. So everything stays in the “explore / spike / draft” zone.
2. Tooling friction
- Local dev is painful
- Deploys are brittle or slow
- Debugging production issues is guesswork
Result: even small changes feel heavy, so people batch them into large, risky drops. Shipping slows because the feedback loop hurts.
3. Hidden second jobs
- Senior folks carrying unspoken glue work
- One person doing 80% of the coordination with other teams
- Someone quietly firefighting legacy systems that aren’t on any roadmap
Result: on paper you have 5 engineers; in reality, you have 2.5.
Step 5: Design a small restart, not a grand fix
Once you’ve mapped the landscape, the temptation is to design a big re-org, a new process, a full rewrite of how you do planning.
Resist that.
When a team has stopped shipping, the most powerful thing you can do is help them ship one small, meaningful thing, quickly and safely.
You’re trying to demonstrate:
“We can still move. Here is proof.”
Some concrete patterns that work:
1. Pick a narrow, real outcome
For example:
- “Reduce alert noise on service X by 30% this week”
- “Ship a tiny visible improvement to onboarding that we can A/B”
- “Retire one deprecated path end-to-end”
Make it something that matters, but is realistically doable in 3–7 days.
2. Clear a path
Temporarily:
- Cancel or decline meetings that don’t serve that outcome
- Take on some of the political or stakeholder conversations yourself
- Make sure the team has the access, context and support they need
You’re not doing this forever; you’re making it unusually easy to succeed once.
3. Make the learning explicit
When you ship that first thing, don’t just celebrate. Ask:
- What made this easier than the last month?
- Where did we still feel drag?
- What should we do more of next week?
You’re looking for repeatable moves, not just a one-off heroic push.
Step 6: Protect trust while you intervene
The fastest way to make a stuck team worse is to send the message:
“Leadership thinks you’re lazy / not good enough / need to be pushed.”
People stop sharing what’s really going on, and you lose the ability to fix the system.
A few guardrails:
-
Own your part.
If priorities shifted a lot, say so. If the roadmap was fuzzy, admit it. If you’ve been absent, acknowledge it. It makes it safer for others to be honest. -
Describe behaviours, not identities.
“We’re juggling too many priorities” is very different from “this team is unfocused”. -
Intervene with the team, not to the team.
Co-design the small restart: “If we wanted to make shipping one useful thing this week almost guaranteed, what would we change?” -
Don’t suddenly become a micromanager.
Increased visibility is fine (“let’s review the board together twice a week for a bit”). Taking away all autonomy is not.
A simple checklist you can reuse
When you notice a team has gone quiet on delivery, you can walk this in order:
-
Map the symptoms
What looks stuck? Where is work piling up? -
Look at the w