Execution: Tracking Progress Without Micromanaging

The last few pages built a plan: you defined done, gathered requirements, broke the work down into a plan, and put honest ranges on the pieces. That plan was your best guess before the work started. The moment the work starts, reality begins editing it.

This page is about the gap between the two — between where the plan said you’d be and where you actually are. Tracking progress is the craft of seeing that gap early and clearly, while there is still time to do something about it. It is not the same as watching people work, and confusing the two is one of the most common and damaging mistakes a new manager makes. This page shows you how to see the truth of the work without hovering over the people doing it.

Why plans drift, and why that is normal

Every plan is a prediction, and predictions are wrong in small ways constantly. A task took longer than estimated. A supplier was late. Someone got sick. A requirement everyone thought was clear turned out to be fuzzy. None of this is failure — it is what “contact with reality” means. The military phrase is that no plan survives first contact; the useful version for managers is quieter: a plan is a starting position you keep updating, not a promise you keep defending.

The danger is not that plans drift. The danger is drifting silently — carrying an out-of-date plan in your head for weeks, telling stakeholders you are on track because the plan says so, and discovering the truth only when the deadline arrives and the work isn’t there. Tracking exists to close the distance between what the plan claims and what is true, and to close it early.

So the whole job of tracking has one aim: find out where the work truly stands, soon enough to act on it.

Measuring real completion (the “90 percent done” trap)

The first skill is measuring progress honestly, and it is harder than it sounds — because the natural way people report progress is deeply misleading.

Ask someone how a task is going and you’ll often hear “about ninety percent done.” Then it stays ninety percent done for a week. Then two weeks. This is so common it has a name in project circles: the ninety-percent-done syndrome. The reason is simple: the first, easy, visible part of a task feels like most of it, while the last part — the fiddly integration, the edge cases, the sign-off, the thing nobody thought about — quietly holds a huge share of the real effort.

The fix is to stop measuring progress by feeling and start measuring it by finished, verifiable pieces.

A weak way to track            A stronger way to track
-------------------            -----------------------
"The report is 90% done"   →   "3 of the 5 sections are written,
                                reviewed, and signed off. 2 to go."

"Almost finished the        →  "The ward has moved 40 of its 60 beds;
 ward move"                     equipment and records still pending."

"Nearly there on the app"  →   "Login and checkout ship and pass
                                testing. Search is built but untested."

The pattern is the same everywhere: break the work into pieces small enough that each one is either done or not done, with no middle ground — and count only the truly-done ones. A task is “done” when it meets its part of the definition of done, not when someone feels close. Half-finished work counts as zero, because half-finished work is exactly where the hidden effort hides.

The common trap — counting effort instead of outcomes

It is tempting to track how much work has gone in — hours logged, tasks started, activity happening. But effort is not progress. A team can be extremely busy and produce nothing finishable. Always ask: “what is now done that wasn’t done last week?” If the honest answer is “we worked hard but nothing crossed the finish line,” that is a signal, not a rounding error. Count outcomes, not motion.

Updating estimates as facts change

Tracking real completion gives you something valuable: evidence about how good your original estimates were. Use it.

If the first three tasks each took fifty percent longer than estimated, the rest of your estimates are probably optimistic too — and the honest move is to update the whole forecast now, not to hope the team “makes it up later.” Making it up later almost never happens; the same optimism that produced the first estimate is still baked into the rest.

Updating an estimate is not admitting failure. It is the opposite — it is the difference between a manager who reports “we’re tracking about two weeks behind, here’s the revised finish” in week three, and one who reports the same two weeks late, in week ten, as a shock. The facts were identical. Only the honesty and the timing differed.

In practice — the warehouse re-shelving project

A warehouse plans to re-organise its storage in four weeks — one week per zone. Zone one takes nine days instead of five, because old inventory records are wrong and everything must be re-counted. A manager tracking honestly sees the pattern immediately: the records problem affects all four zones, so the real project is closer to seven weeks. She flags it in week two, negotiates either more time or extra help, and the project lands calmly. A manager who “stays on plan” reports on-track for three weeks, then blows the deadline. Same facts, seen at very different times.

Short, regular check-ins beat one big status report

If you only look at progress at milestones or at the deadline, you find problems far too late to fix them cheaply. The remedy is frequency: short, regular check-ins that surface blockers while they are still small.

A blocker is anything stopping work from moving forward — a decision no one has made, a missing approval, a dependency on another team, a tool that isn’t working, a question waiting on an answer. Blockers are the enemy of progress precisely because they are often quick for a manager to clear (“I’ll get that approval today”) but can silently cost a worker days of stalled time if no one hears about them.

This is the entire logic behind the brief daily or twice-weekly check-in used by many teams — often just ten to fifteen minutes, standing up, with three questions per person:

The three check-in questions
----------------------------
1. What did you finish since we last met?   (real completion)
2. What are you working on next?            (direction)
3. What is blocking or slowing you down?    (the important one)

Question three is the point. The check-in is not a performance review or a progress interrogation — it is a blocker-detection system. Its value is that a stuck person gets unstuck in a day instead of suffering in silence until the deadline. Keep it short: the moment it becomes a long status meeting, people dread it, hide problems, and it stops working. Solve individual problems after the check-in, with only the people involved.

The evidence — the cost of surfacing problems late

Study after study of project overruns finds the same shape: problems that are cheap to fix early become expensive, then catastrophic, the longer they stay hidden. The exact multipliers vary by field, but the qualitative finding is robust — the cost of a defect or a wrong assumption tends to rise sharply the later it is caught. Frequent, low-ceremony check-ins are cheap insurance against exactly this: they shorten the time between a problem appearing and a person hearing about it.

Tracking outcomes is not surveilling activity

Here is the line that separates good tracking from micromanaging, and it matters enormously for trust: track the work, not the worker.

Tracking asks about the work: what is finished, what is blocked, where the project stands. Surveillance asks about the person: are you at your desk, how many hours, why the mouse stopped moving, what were you doing at 2 p.m. The first builds a shared, honest picture everyone can act on. The second communicates one thing — I don’t trust you — and it reliably makes tracking worse, because the fastest way to make people hide problems is to punish them for having any.

This isn’t soft sentiment; it is mechanics. Honest tracking depends entirely on people telling you the truth about where things really stand, including bad news. People only do that when it is safe to. If admitting “I’m stuck” or “my estimate was wrong” gets a person watched more closely or blamed, they will learn to say “ninety percent done” and go quiet — and you lose the very information tracking exists to get. The manager who surveils ends up with a tidy dashboard and no idea what is actually happening.

Case study — Toyota’s andon cord

On Toyota’s production lines, any worker who spots a problem can pull a cord (the andon) that signals for help and, if unresolved, stops the line. The remarkable part is the culture around it, refined over decades from the 1950s onward: pulling the cord is treated as good — surfacing a problem early is exactly what you’re supposed to do, not something you’re punished for. The lesson for any manager tracking progress: you get early warning of problems only if raising them is safe and rewarded. Build a line where “I’m blocked” is met with help, not blame, and problems reach you while they’re still small. Build the opposite, and they reach you as disasters.

Make status visible

The last piece ties it together: make the state of the work visible to everyone involved. A plan hidden in one person’s head, or buried in a report only the manager reads, cannot catch problems — because only one pair of eyes is looking.

Visible status can be low-tech or high-tech; what matters is that anyone can glance at it and see the truth. A whiteboard with sticky notes moving across three columns — To Do, Doing, Done — is often enough, and its power is exactly that it is public and physical: everyone sees what’s stuck, work that has sat in “Doing” too long stands out, and no one can quietly pretend things are fine.

   To Do            Doing              Done
 ---------        ---------          --------
 [ task ]         [ task ] ← stuck   [ task ]
 [ task ]         3 days here        [ task ]
 [ task ]                            [ task ]

Visibility does three jobs at once. It spreads problem-spotting from one manager to the whole team. It removes the awkwardness of “reporting” — the board just shows the state, so no one has to confess. And it builds trust, because when the picture is shared and honest, people stop suspecting there’s a hidden version. A visible board is the difference between finding a problem while you can still act, and hearing about it when it’s too late.

How it connects

Tracking is where the plan meets the world, so it feeds the next two pages directly. The blockers and drifts you surface are early warnings for Risk Management — a slipping task is often a risk you can now name and mitigate. And when tracking reveals you cannot fit the scope into the time, that is the trigger for the honest trade-offs in Scope Creep and the Iron Triangle. Good tracking doesn’t just observe the project; it hands you the information every later decision depends on.

Try this

For one week, run a five-minute end-of-day check on a project you’re responsible for. Write down only what actually crossed the finish line that day — pieces that are fully done, not “nearly” — and one line naming anything that is blocked or stuck. At the end of the week, compare where the plan said you’d be with where you actually are. Notice how it feels to look at the honest gap, and notice how much earlier you’d have seen it if you’d been tracking outcomes all along.

Reflect

1. Think of a time something was “almost done” for far longer than expected. What was hiding in that last stretch, and how could you have measured it as finished pieces instead?
2. On your current work, are you tracking outcomes (what’s finished and blocked) or activity (who’s busy, hours logged)? What would change if you switched?
3. When was the last time a problem reached you too late to fix cheaply? Would a short, regular check-in have surfaced it sooner?
4. Do the people you work with feel safe telling you “I’m stuck” or “my estimate was wrong”? What in your reaction makes that safe or unsafe?
5. Can everyone involved in your project see its true status right now, or does it live in one person’s head? What would making it visible cost, and what might it save?

Show reflections

1. The useful insight is that “almost done” is usually the front half of the work masquerading as the whole. Good answers identify the hidden tail — integration, sign-off, edge cases — and re-describe the task as a list of done/not-done pieces so the illusion can’t form.
2. Many people discover they track activity by default because it’s easy to see. The shift is to ask “what is now done that wasn’t last week?” — a harder but far more honest question that measures the project instead of the effort.
3. The point is to connect a real, late-caught problem to the mechanism that would have caught it earlier. If a fifteen-minute check-in would have surfaced it in day one instead of week ten, that’s the case for making check-ins routine.
4. This is the trust question underneath all tracking. Honest answers examine your own reaction to bad news: if “I’m stuck” gets someone watched or blamed, you’re training people to hide, and your tracking goes blind. Safety is what keeps the information flowing.
5. If status lives in one head, only one person can catch problems and everyone else is guessing. The cost of a visible board is usually tiny (a whiteboard, ten minutes); the saving is early warning spread across the whole team.