Why projects slip quietly
People don't like delivering bad news, especially when they think they can still catch up. So status stays green while the real picture gets worse. By the time it turns red, the options are worse too.
So make it easy to say "we're behind" early, and notice when nobody is saying it.
The 8 signs
1. "On track" with no evidence
The status is green, but there's no demo, no merged code, and no finished milestone to point at. Green should mean "here's what's done." If it means "we feel OK," treat it as unknown.
2. Work stuck in "in progress"
The same tickets have sat in progress for a long time. Or tickets keep getting split into smaller tickets that also don't close. The board looks busy, but nothing is finishing.
3. The scope keeps growing
New "small" asks keep landing. Nobody pushes back, and the date doesn't move. Something has to give, and usually it's quality or the deadline.
4. Decisions that never got made, or never got written down
The team keeps revisiting the same question. Or people remember a decision differently. Undecided or undocumented decisions turn into rework later.
5. A dependency nobody owns
The project needs something from another team, a vendor, or a platform change. Nobody has a date for it. Everyone assumes someone else is chasing it.
6. Questions go unanswered
Engineers ask questions in chat or tickets and wait days for a reply. If people stop asking, that's worse, because now they're guessing.
7. One person is carrying it
All the reviews, all the context, all the late-night commits land on one person. If they get sick, take leave, or burn out, the project stops. See how to tell if your team is burning out.
8. Meetings about the project get shorter or disappear
Check-ins get cancelled "because there's nothing new." Or they turn into status recitals with no questions asked. Quiet can mean things are fine, or it can mean nobody wants to be the one to say they aren't.
A 15-minute slip check
Pick one project. Answer these honestly.
- Can I name the last thing that was actually finished, and when?
- Is the next milestone date still the same as it was a month ago?
- Has scope been added since the date was set? Did the date change?
- Are any tickets stuck in progress much longer than usual?
- Is every outside dependency owned by one person, with a date?
- Are the key decisions written down somewhere the team can find?
- Is more than one person able to keep this moving?
- Did the last check-in include any bad news or open questions?
Two or more boxes you can't tick is your cue to dig in.
What to do once you spot it
Ask, don't accuse
Talk to the project lead first. Keep it neutral and specific.
- "The search work has been in progress for a while. What's in the way?"
- "If we had to ship in two weeks, what would we cut?"
- "What's the thing you're most worried about on this project?"
- "Is there a dependency you're waiting on that I can help chase?"
The last question matters. It tells them you're there to help, not to grade them.
Get to a real date
Ask for a date built from the remaining work, not the original plan. If the team can't give one, that's the finding. Agree on what you need to learn to get one, and by when.
Choose: cut, add, or move
There are three real options.
- Cut scope. Ship less, on time.
- Add help. Only works if the work can be split and the new people can get up to speed fast.
- Move the date. Tell the people who depend on it now, not later.
Pick one. "Work harder" is not an option, because it usually leads to burnout and more slipping.
Write it down
Record the decision, the reason, and who was told. A short note in the project doc is enough. It stops the same argument from happening again next month.
Tell people early
Tell anyone affected now. Early bad news gives them time to plan around it. Late bad news costs you their trust.
What you can say: "Heads up. Search v2 is going to land later than planned. We're cutting X to hold the date, or we're moving it to [date]. Here's why."
Make it easier to see next time
- Define green. Agree that "on track" means something finished you can point to.
- Ask for one risk every week. "What's the one thing that could make us late?" makes risk normal to talk about.
- Review weekly. Run your top projects through a quick weekly review. See how to run a Monday priorities review.
- Track decisions. Keep a simple decision log per project: what, who, when, why.
- Thank people for bad news. If the person who flags a slip gets grilled, the next one won't.
FAQ
How is "quietly slipping" different from just late?
Late is when everyone knows. Quietly slipping is when the signs are there but nobody has said it yet. The earlier you catch it, the more options you have.
Should I skip the project lead and check the board myself?
Look at the board, but talk to the lead before acting on it. Boards are often out of date, and going around the lead damages trust.
What if the project lead insists it's fine?
Ask what evidence would show it's fine, and when you'll see it. Then check on that date.
How often should I run the slip check?
For your top few projects, weekly is reasonable. For smaller ones, monthly or at each milestone.
Want in early?
I'm building Sasshi, an iPhone app for engineering leaders. It's in the works, with invite-only early access. Its AI, Scout, reads your calendar, email, Slack, meeting notes, project boards and code activity, read-only. Each morning it surfaces 3 to 5 blind spots, like silent risks, duplicate work and undocumented decisions, with receipts and a one-tap next step. Nothing is sent without you. See how it works.
Only used to contact you about Sasshi. No spam, no sharing. Ask me to delete it anytime.
Sources
No outside sources are cited. This is practical guidance, not research.