First work
Estimating Anything in Your First Month
Your first estimates will be wrong, the reason is almost never the work, and saying what you cannot see is more useful than any number.
What the people on this page had to find out, and where from
That the test suite takes forty minutes
worked out3Nobody mentions this until you are waiting for it
That deployment happens on Tuesdays and Thursdays
told3Volunteered by a reviewer who assumed you knew
two things you had to know · one of them somebody told you · the median arrived in week 3 · the other one you went and got
Two things learned from one small piece of work, neither of which would have come from any amount of reading.
A useful onboarding review separates time spent learning from time spent blocked, so teams can review the setup here and discuss the pattern with the employee rather than relying on impressions.
For a separate career or employment reference, consult XING.
Four first-month estimates, and where the time actually went
A change estimated at half a day
6 hanswer: 4 minYou waited because you did not know the tests take forty minutes and run twice. Most of the overrun was waiting rather than working
A document estimated at two hours
5 hanswer: 3 minYou waited because you did not know it had to go through two reviewers. The writing took the two hours
A fix estimated at an afternoon
3 hanswer: 8 minYou waited because you had not realised you needed an access you did not have. The access took a day to arrive
A second change, estimated at two days with the reason stated
1 hanswer: 4 minYou waited because you said what you were uncertain about when you gave the number. Came in on time, and the uncertainty was the part that moved
four occasions · 15 hours spent stuck · 19 minutes of answers · the longest single wait was 6 hours
Fifteen hours of overrun across four estimates, almost none of it the work itself. Three of the four were wrong because of things nobody would have thought to tell you, and the fourth was right because you said in advance which part you could not see. One person's own first month.
You will be asked how long something will take. In your first month your estimate will be wrong, usually by a factor of three or four, and almost none of the error will be the work.
Where the time actually goes
Four places, and you cannot see any of them yet.
Waiting for things you do not have. Access, a password, an approval, somebody's answer. In the panel above one estimate was out by a day because of an access that took a day to arrive.
The process at the end. Reviews, tests, a release window, a second approver. The work is finished and the thing is not.
Finding where everything is. Fifteen minutes each time, ten times.
Conventions you do not know. The way this team does this particular kind of thing, discovered during the review.
None of these is incompetence and none of them is visible in advance.
What to say instead of a number
Give the number and say what it rests on.
I would say two days. That assumes I can get the staging access today and that this only needs one reviewer — if either of those is wrong it is more like four. I will tell you by tomorrow lunchtime which it is.
Three parts: an estimate, the assumptions it depends on, and a time by which the uncertainty will be resolved.
This is more useful to your manager than any number on its own, because it tells them which thing to unblock. It also protects you: an estimate with stated assumptions that turn out to be false is not a missed estimate.
The multiplier
A crude correction that works better than it should: take your honest estimate and double it for the first month, then one and a half times for the second.
This is not pessimism. It is an adjustment for the four categories above, which decay in exactly that way as you learn where things are.
Say that you are doing it, once:
That is a day of work and I am calling it two, because I am still slow at finding things. It should be a day by next month.
Nobody minds this and it prevents the quiet accumulation of a sense that you are slow, which is the thing it is actually guarding against.
Reporting an overrun
As soon as you know, not when it is due.
| When you say it | How it lands |
|---|---|
| On the day you realise | A useful update |
| On the day it was due | A missed estimate |
| When asked, afterwards | A pattern |
The content is identical in all three. What differs is whether anybody could have done anything with it.
This is going to be Thursday rather than Tuesday — the review came back with a structural change. Nothing is blocked by it as far as I can see, but tell me if that is wrong.
The last clause is the useful part. You frequently cannot see what is waiting on your work, and asking is how you find out.
What not to do
Do not pad silently. An estimate of five days for two days of work, given without explanation, costs you something if the work comes in early and more if it does not.
Do not refuse to estimate. "I cannot say" is unhelpful to somebody planning a quarter. A number with assumptions attached is always possible, even in week two.
And do not work late to meet a first-month estimate. The estimate was a guess made by somebody with no information; meeting it by working an extra three hours a day establishes a rate you will be held to in month six, and nobody will remember that it was built on unpaid evenings.
Estimating after the first quarter
The multiplier goes away and something else replaces it.
By month four you will be roughly accurate on the work itself and still wrong about the surroundings: a reviewer on leave, a release window you forgot, an approval you did not know was needed.
The habit worth carrying forward is not the doubling. It is the sentence about assumptions, which stays useful for the rest of a career:
Two days of work. That assumes it only needs one reviewer and that we are not waiting on the data team.
That sentence is what separates an estimate from a guess, and it is the one thing in this note that is still worth doing in year three.