Recently someone said to me “stakeholders only care about milestones,” and something clicked for me.
Engineers work at a level of granularity that is too small for stakeholders to care about. People aren’t going to read git commit history, and don’t want to be notified about every PR that gets merged.
But stakeholders do care about getting status updates. Very rarely will you be told that you can go dark, work in isolation, and just let everyone know when the project is finished.
So how do you give status updates that stakeholders want, without being too granular? Milestones. You map out the small set of big steps that will happen along the way to being finished. This might not be a particularly interesting revelation. Milestones or epics, or whatever you want to call them, are hardly a new idea.
I’ve always had a mild distain for milestones. Often they’re an arbitrary grab bag of tasks with no logical grouping or purpose. I was recently a victim of a project that was broken into two phases. Phase 1 took 80% of the budget and was made up of all the easiest, lowest-risk changes. Then an attempt was made to rush out phase 2 at breakneck speed, which contained the gnarliest problems and potentially catastrophic risks, due soley to the imminent loss of budget. This is the kind of thing I’ve come to expect in regard to milestones.
But what clicked for me recently is that milestones aren’t really about breaking down projects — they are a tool specifically designed for stakeholder communication. If I think of milestones not as arbitrary divisions of a project, and instead as talking points for status updates, that shift in framing gives me something I can use. It gives me criteria for evaluating what makes a good milestone vs a bad milestone, and another lens on how to craft good project status updates. Now that I can see a clear purpose for them, maybe milestones aren’t that bad after all.