AR9: Leading engineers: mentoring, communication and estimation
Planning, progress and saying no
🎯You'll be able to
Plan work in small milestones, report progress honestly, manage risks to the plan, and say no or "not now" in a way people accept.
🏠The everyday picture
Planning a wedding, families set milestones (venue booked, invitations sent, caterer confirmed) and check them each week. When the caterer cancels, they tell everyone at once and choose between the options, rather than hoping it will sort itself out.
📘What it really is
- Milestones that each deliver something visible: "the service runs with no traffic", not "50% done".
- Report progress against milestones, with a simple status (on track, at risk, off track) and the reason.
- Bad news early: a risk reported in week two can be managed; the same risk found in week ten can't.
- Change the plan openly: scope, time or people; say which, and why.
-
Saying no (or "not now"): explain the trade-off ("if we take this, the rollout moves two weeks"), offer an alternative, and let the person who owns priorities decide.
-
Measure delivery over time with simple figures, such as how often the team deploys and how often a deploy is rolled back.
📝A worked example
Input: halfway through Project 2's rollout, the business asks for a new "order delayed" message in time for a sale next week.
Steps:
- Trade-off: adding a template now means migrating and testing it mid-rollout.
- Options: (a) add it to the old sender only, now, and migrate later; (b) pause the rollout for three days and add it to both; (c) decline until the rollout finishes in two weeks.
- Recommend (b), with the reason: the sale is the busiest time, and messages must match on both paths.
- Report: status "at risk" for the rollout date, moved by three days, with the reason.
Expected output: a clear choice for the business owner, and a status report that stays honest.
🌍Where it's used
- Weekly status reports to stakeholders.
- Delivery metrics such as deployment frequency and change failure rate (from the DORA research programme).
- Risk logs reviewed in planning meetings.
📝Case scenario
A team reported "90% done" on a migration for six weeks in a row. The last 10% (data checks and rollback testing) was most of the work, and nobody had said so. Milestones such as "data reconciled" and "rollback tested", each done or not done, would have shown the real position in week one.
🖱️Try it
Take a plan of your own and rewrite its steps as milestones that are each clearly done or not done. Success: nobody could report "90%" for any of them.
⚠️Common mistakes
- Percent-done reporting. Sign: "90%" for weeks. Fix: milestones done or not done.
- Hiding bad news. Sign: a surprise slip at the end. Fix: report risks the week you see them.
- A flat "no". Sign: an annoyed stakeholder. Fix: the trade-off, options and a recommendation.
🛠️For your project
Project 2's plan already has steps with checks; the capstone's estimate turns them into milestones with ranges.
✅Quick check
Why are milestones better than "percent done"?
Show the answer
Each is clearly done or not, so progress can't drift at "90%".
How should a tech lead say no to a request?
Show the answer
Explain the trade-off, offer options and a recommendation, and let the priority owner decide.