One day at a time: milestones, momentum, and the line between leading and micromanaging

There’s a quote from The Mythical Man-Month that I come back to more often than I’d like to admit:

“Question: How does a large software project get to be one year late? Answer: One day at a time!”

And the bit that matters (the bit that stings) is what comes next: incremental slippages, across many fronts, accumulate into a proper disaster unless you keep a close eye on small milestones at every level of management.

I’m in the middle of one of those projects right now. The deadline isn’t “tight” because the work is small. It’s the opposite. It’s big, multi-stream, lots of dependencies, lots of moving parts.

And the deadline doesn’t move.

That kind of pressure changes the game. It forces you to care less about how nice your plan looks in a deck, and more about whether you can keep the project from bleeding a day here, two days there, until suddenly you’re staring at a three-week slip and nobody can quite explain where it went.

So this post is about milestones. Not “project plan milestones” in the abstract, but the practical question: how granular should milestones be on a large project, and how do you drive them without sliding into micromanagement?

Because honestly, if you get that balance wrong, you either lose control of the schedule… or you lose the team.

Tight deadline, big project: why milestone granularity starts to matter more

On a normal project, you can sometimes get away with loose milestones.

• A two-week sprint goal that’s a bit vague.
• A workstream plan that assumes best-case coordination.
• “We’ll sort it out in refinement.”

But when the deadline is fixed, the cost of vagueness goes up fast. You don’t get to discover in Week 6 that your Week 3 assumptions were wrong. You don’t get to “make it up later” because later is already booked.

This is where milestone granularity becomes a control mechanism. Not control in a domineering sense. Control in the cybernetics sense: feedback loops.

If the project only “checks in” every two weeks, then you only learn you’re off track every two weeks. And by then, you’re not correcting drift - you’re trying to recover from it. Those are different activities. One is steering, the other is emergency surgery.

So the question becomes:

What’s the smallest milestone we can use that gives us early warning, without turning the whole thing into theatre?

The spectrum: from “milestones too sparse” to “micromanagement”

I tend to think about milestone granularity as a spectrum:

Too sparse (false confidence)

This is where projects quietly die.

Symptoms:

• Sprint goals are broad enough that almost anything counts as progress.
• Status updates are mostly narrative (“we’re making good progress”).
• Blockers are discovered late because nobody had to commit to a near-term, testable outcome.
• Integration work piles up at the end (because it was always “later”).

Sparse milestones feel calm. That’s the trap. Calm isn’t the same as in control.

Too granular (micromanagement / thrash)

This is where projects get noisy and slow.

Symptoms:

• People are constantly being interrupted for updates.
• Engineers start optimising for looking busy instead of delivering outcomes.
• The plan gets updated more than the product does.
• Team members stop raising real risks because it’s easier to say “on track”.

Over-granularity can create the appearance of precision, but it’s brittle. You end up managing tasks, not outcomes. And the team feels it.

The sweet spot (tight feedback, human autonomy)

This is what you’re after:

• Milestones are small enough to expose slippage early.
• But big enough that engineers still own the “how”.
• Progress is measurable.
• And the plan is a tool for action, not a performance.

The trick is that the “sweet spot” moves depending on project context.

And right now, with a big project and an immovable deadline, it moves towards tighter loops.

What I do when a sprint feels too long

When I start to feel that familiar discomfort - “this sprint is too long”, “these milestones are too sparse”, “we’re going to wake up in ten days and realise we’re behind” - I tighten the loop.

Not by adding bureaucracy. By adding clarity.

And yeah, the tool I reach for is often the daily stand-up. But not as a ritual. As an instrument.

The stand-up question that changes everything

I’ll often steer the stand-up (or a parallel “delivery pulse”, depending on team structure) towards three questions:

1. What’s today’s milestone?
   Not “what are you working on”, but what finishes today. Something that moves from “in progress” to “done”.

2. Did you complete yesterday’s?
   If no, why? And be specific. “Got pulled into something else” isn’t a reason; it’s a symptom.

3. What do you need from me to get back on track?
   This is the important part, because it forces leadership behaviour rather than status collection.

I’m not asking so I can police people. I’m asking so I can remove friction:

• clarify requirements
• make a decision the team is blocked on
• escalate to a client stakeholder
• negotiate scope trade-offs with the PM/DM
• pull in an extra engineer (carefully, Mythical Man Month explains elegantly how this can go very wrong)
• unblock access, environments, credentials
• stop a parallel thread from derailing the mainline

It becomes a daily micro-correction mechanism. One day at a time, basically.

And yes, this can look like micromanagement if you do it badly. The difference is intent and tone - and whether your questions lead to support or surveillance.

Leading vs micromanaging: the line I try not to cross

Here’s the simplest way I can put it.

Leading is being accountable for outcomes and clearing the path.
Micromanaging is controlling the path when the team could own it.

A few practical heuristics I use:

1) I’ll get granular on interfaces, not implementation

If the risky bit is an integration boundary (API contract, webhook behaviour, data mapping, error handling), I’ll push for very explicit milestones there.

Because ambiguous interfaces are where time disappears.

But I usually don’t care whether someone uses pattern A or B internally, as long as:

• it meets the acceptance criteria,
• it’s testable,
• it won’t explode in production,
• and it’s maintainable.

2) I’ll ask for proofs, not promises

In a tight deadline project, “should be done by Thursday” is not a plan.

So I’ll push for demonstrable checkpoints:

• a working stub hitting a sandbox
• a feature behind a flag in staging
• a contract test passing
• a happy-path order flowing end-to-end (even if ugly)

Progress that compiles and runs beats progress that’s described well.

3) I tighten loops when uncertainty is high — then loosen them again

This is important. The goal isn’t permanent high-intensity oversight.

Early in a complex workstream, uncertainty is high:

• unknown edge cases
• unclear requirements
• incomplete environments
• third-party dependencies

That’s when daily milestones are worth it.

Once the workstream stabilises and execution becomes predictable, I’ll loosen the granularity again. Otherwise you create fatigue. People stop hearing the questions. Too often I see this in reverse, the daily feedback loop is implemented when the fire is raging already, instead of when you smell smoke in the first instance.

4) I focus on slippage patterns, not individual “bad days”

Everybody has an off day. Builds break. Kids get sick. Meetings happen.

But if a workstream misses the “today milestone” three times in a week, that’s not random. That’s a signal:

• scope is bigger than thought,
• we have a staffing issue,
• dependency is unresolved,
• requirement is ambiguous,
• or we’ve got too much WIP.

That’s when I step in harder - not to criticise, but to change the shape of the work.

The Delivery Manager / Project Manager partnership (my favourite “cheat code”)

I’ve always worked closely with Delivery Managers and Project Managers, and I don’t think that’s optional on serious delivery.

For an architect or a lead, your DM/PM should be your primary compatriot on the project.

Because between you, you cover the full control surface:

• DM/PM: comms, expectations, sequencing, dependencies, RAID, stakeholder alignment, cadence, decision capture
• Architect/Lead: technical direction, feasibility checks, risk spikes, integration strategy, non-functional requirements, quality bar, de-risking

Together you can do the thing that actually stops slippage: convert uncertainty into decisions.

And decisions are what keep the team moving.

Without that partnership, one of two things usually happens:

• the technical plan drifts away from the delivery plan, or
• delivery becomes a status-reporting exercise while the technical risk compounds underneath.

Neither ends well.

A practical approach: “milestones that bite”

If you want a simple way to pressure-test whether milestones are granular enough, try this:

A milestone should be something that, if missed, forces a conversation the same day.

Not a conversation in the next sprint review. Not “we’ll see”. Same day.

Examples of milestones that bite:

• “Webhook received and persisted; replay works; idempotency key in place.”
• “Tax engine returns correct totals for three defined scenarios (UK, US, CA) in staging.”
• “Order created in Shopify, appears in ERP within 2 minutes, with line/tender mapping correct.”
• “Checkout extension displays correctly for logged-in and guest flows; passes basic accessibility checks.”

These aren’t huge. They’re not tiny either. But they’re concrete. Testable. And they expose slippage early.

Bad milestones (the slippery kind):

• “Make progress on integration”
• “Work on checkout”
• “Continue build”
• “Refactor module”

Those are activities, not outcomes. They don’t bite.

So, how do you stop slippage?

You stop it the same way Brooks described it: one day at a time.

But “one day at a time” doesn’t mean panic. It means building a system where:

• each day has a measurable outcome,
• missed outcomes are discussed immediately,
• blockers are removed quickly,
• and leadership is felt as help, not pressure.

Because on big projects with immovable deadlines, slippage isn’t one dramatic failure. It’s a slow leak.

And leaks don’t respond to inspirational speeches. They respond to attention, routines, and small, relentless corrections.

That’s the job.