Every engineering manager has seen it: a project that's technically active — tickets being worked, commits being made — that's somehow not moving forward. Two weeks in, you realise less has been completed than expected. The team wasn't idle. So what happened?

Usually: drift.

What drift actually is

Drift isn't a team failing to work. It's a team working without clear shared visibility on what progress is supposed to look like right now — today, or in the next two or three days.

In co-dependent builds, where frontend work depends on backend contracts that aren't finalised, or where two streams need to meet at a specific integration point, drift is especially costly. A dependency that isn't surfaced until Friday standup might have been unblockable on Tuesday — if anyone had known to ask.

The problem with weekly tracking alone

Sprint-level tracking tells you where you are at the end of two weeks. That's too late to catch the kind of drift that compounds mid-sprint.

Retrospectives tell you what went wrong after it's already over. Useful for learning, but the project already paid the cost.

What you need is a mechanism that answers one question consistently: are we actually moving forward right now?

Rolling 2–3 day milestones

The structure we use is straightforward:

  • At the start of the week, define concrete milestone targets for each team or work stream — expected to hit by Wednesday or Thursday
  • Make targets specific: not "working on authentication" but "OAuth flow complete and tested against staging"
  • Surface dependencies between teams explicitly: "backend needs the user endpoint ready before frontend can continue"
  • Daily communication focuses on one thing: are blockers emerging before they drift?

This isn't a new methodology. It's a specific application of a simple principle: track progress at the granularity that lets you catch problems before they compound.

What this looks like in practice

Monday planning sets the week's direction and establishes the 2–3 day targets. Daily syncs — short, 10 to 15 minutes — answer three questions: what did you complete, what are you working on today, and what do you need from another team?

Thursday is a milestone check: did we hit the mid-week targets? If not, why — and what adjusts in the second half of the week?

Friday is refinement and blockers review: what's unresolved, what carries forward, and what does the next cycle need to account for?

Nothing heavy. No process overload. Just enough structure to maintain a consistent shared model of where things stand.

What we've seen

When teams have clear visibility into what progress should look like in the next two to three days, a few things happen naturally:

  • Dependencies get surfaced before they block work, not after
  • Blockers don't sit indefinitely — there's a daily moment to name them
  • Communication improves because people know exactly what they need from each other

Projects don't ship because teams work harder. They ship because the system gives everyone consistent clarity on what forward looks like.

Sometimes you're still waiting on a clarification or an external dependency. That's reality. But instead of things drifting, there's always a clear next step and a defined path forward.

That's usually the difference between a project that drifts — and one that ships.