Working with engineers
A PM and an engineering team make the same decision again and again: what to build next with the time there is. This lesson shows you how to ask for estimates as ranges, forecast from the team's real throughput, cut scope instead of quality when time runs short, keep technical debt visible, and run sprints, demos and retros that earn their time.
By the end you can
- Ask for estimates as ranges with a confidence level, and know what narrows them
- Forecast a delivery window from the team's past throughput
- Cut scope by slicing thinner, and present trade-off options with their consequences
- Keep a technical debt register and agree how much capacity goes to it
- Pick between Scrum, Kanban and Shape Up habits, and run demos and retros that change things
The everyday picture
You are renovating a kitchen. You ask the builder how long it will take. She says "two to four weeks, depending on what's behind the old tiles." A good client does not demand "three weeks exactly." She asks what would narrow the range, and the builder offers to open one wall on the first day to look.
Halfway through, money is tight. A good client drops the second oven. She does not drop the waterproofing under the sink, because skipping it saves three days now and costs a ruined floor next year. Every Friday the two of them walk through the site and look at the real work, and once a month they ask what slowed the job down. Estimates, scope, hidden costs, demos and retros: that is most of working with engineers.
Estimates are ranges, and you can narrow them
Software estimates are uncertain for good reasons. Integrations behave differently from their documentation, old data hides surprises, business rules turn out to be unclear, and the team learns things while building that nobody could know before. Steve McConnell's company Construx describes this with the cone of uncertainty: at the initial-concept stage, an estimate can be off by a factor of four in either direction, so a "four-week" idea might take one week or sixteen. Their key point is that "the Cone narrows only as you make decisions that eliminate variability." So narrowing it takes decisions, made on purpose.
That makes narrowing estimates partly your job. Answer open questions early, freeze the rules for the first slice, and pay for a spike on the scariest unknown. Then ask three questions every time: what is the range, how confident are you, and what would narrow it?
Teams size work in different units. Story points are a relative size on the team's own scale. They help that team forecast, but they mean nothing across teams, and using them to judge performance teaches people to inflate them. Some teams skip sizing and count stories, which works well when stories are split to roughly similar size. For roadmaps, T-shirt sizes (S, M, L) are often enough. Three habits damage estimates whatever the unit: anchoring ("can you do it in two weeks?"), converting points to hours, and treating a range's low end as a promise.
Quick check
The head of finance asks when claim approval in the back office will be ready. Ken says "3 to 6 weeks, about 80% confident; it narrows after next Tuesday's spike on the ERP connection." What do you tell finance?
The third passes on the range, the reason for the uncertainty and the date it will narrow, so finance can plan. "Three weeks" turns the low end into a promise. Committing to six hides real information and can still be wrong. "We can't estimate" is untrue: a range is an estimate.