When you work with a dev team — especially overseas — you're mostly relying on signals. Updates. Tickets. Status changes. The problem is: not all signals mean the same thing. Some reflect real progress. Others just reflect movement.
Here are the 5 signals I look at to understand what's actually happening.
1. Ticket movement vs actual completion
Tickets moving across a board is not the same as work being completed. I look for:
- Whether core functionality is actually delivered
- Whether tickets represent real milestones or just steps
- Whether "done" actually reduces project risk
2. Commit patterns
The codebase tells a different story than the PM tool. I look at:
- Frequency of commits
- Size and structure of changes
- Whether work is continuous or compressed at the end
Mismatch example
5 days marked "in progress" — but most commits land on the last day.
That's usually not real 5-day effort.
3. Deployment activity
Are things actually being deployed? Or just built locally and described as "done"?
- Low deployment frequency with high ticket movement often means progress is not production-ready
- Real progress deploys — it doesn't just get marked complete
4. Dependency flow
Projects don't move linearly. I look for:
- Unresolved dependencies hidden as "in progress"
- Blocked components that aren't flagged
- Sequences that don't align with real execution order
This is where most delays originate — long before they become visible.
5. Effort vs output — especially in the AI era
This is becoming more important every month. Some tasks that used to take hours can now be done in minutes. So I look for:
- Inflated estimates on tasks that AI can accelerate
- Work that should be fast but is stretched
- Repetitive patterns that suggest inefficiency rather than complexity
The takeaway
You don't need more updates. You need better interpretation of signals. Because the difference between activity and real progress is where most projects go wrong.