Owning projects
Estimate ranges and padding
Quote a range and a confidence, then multiply the raw sum out loud for unfamiliarity. Hidden padding is how trust dies.
A single number implies false precision. Ranges force you to name what drives the upper bound.
Prefer:
- "3–5 eng-days for the API, 70% confidence; the webhook edge cases are the wild card."
- "Calendar: end of next week if the payments team reviews within two days; add a week if not."
Concept
You already have a raw breakdown. This page is how you turn that sum into something a stakeholder can trade against.
Walking through the padding factor
When the work is unfamiliar, apply a padding factor consciously rather than secretly padding every line.
| Familiarity | Multiply raw task sum by |
|---|---|
| Done this exact pattern last quarter | 1.2–1.3 (review + glue) |
| Known domain, new subsystem | 1.5–2 |
| New domain or new dependency | 2–3, plus a spike first |
Say the factor out loud: "My raw sum is 8 days; I have never touched FraudSvc, so I am quoting 16–20 with a two-day spike up front." Stakeholders can argue with the factor; they cannot argue with a hidden one.
Example
Raw breakdown for "add export CSV for admin reports": schema 0.5d, query 1d, streaming upload 1d, permissions 0.5d, tests 1d, review/QA 1d → 5 days raw. You have not used the company's object-storage helper before → ×1.6 → 8 days, quote 1.5–2 weeks calendar with one other project in flight.
Fold that into the folders example. Raw sum 10 eng-days. Personal factor 1.4 on the unfamiliar ACL line (2 × 1.4 = 2.8), others × 1.3 → calibrated ≈ 13 eng-days. With meetings and a design-review dependency, calendar for one full-time engineer is roughly 3 weeks.
Calendar is not eight focus hours
A realistic planning model many ICs use:
Focus hours per day ≈ 4–5 (rest is meetings, review, Slack)
Focus days per week ≈ 4 (one day lost to ritual + interrupts)
Effective eng-week ≈ 16–20 focus hours ≈ 2–2.5 "ideal" eng-days of estimateSo a "5 eng-day" task is often two calendar weeks if you are also on-call, reviewing, and in discovery meetings. When you quote calendar dates, bake this in or you will look unreliable while working hard.
On-call week: cut planned project load by ~50% unless the rotation is historically silent. Say so in the plan.
Common mistakes
- Padding secretly instead of stating uncertainty.
- Estimating only coding time.
- Planning as if you have eight focus hours a day every day.
- Estimating in story points that never convert to calendar time anyone believes.
Check yourself
Raw sum is 8 days. You have never touched FraudSvc. What do you quote?
Something like 16–20 days plus a two-day spike, with the factor said out loud.
A "5 eng-day" task sits next to on-call and a pile of reviews. How many calendar weeks?
Often about two. Focus time is 4–5 hours a day, not eight.
Key takeaways
- Quote ranges and confidence. Name what drives the upper bound.
- Multiply consciously for unfamiliarity. Say the factor out loud.
- Calendar dates must include meetings, review, and on-call — not just coding.
- Hidden padding destroys trust; visible padding starts a negotiation.
Further learning
Next, spend the calendar on the right work first: de-risking and milestones.
Related
Estimation and planning
Breaking work into small tasks, estimating with ranges, de-risking early, and communicating slips before they become surprises.
Work breakdown and spikes
Split work until each leaf is about one or two focused days. Time-box unknowns as spikes before you pretend to know their cost.
Evidence-based scheduling
Track estimate versus actual on small tasks, then multiply new work by your personal factor instead of summing hopeful guesses.