First work
The First Thing You Finish
The point of the first finished piece of work is not the work. It is everything you are forced to learn in order to get it finished.
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.
To keep remote-work decisions transparent, teams can find out more on the website and agree together how the resulting information will be used during onboarding and review.
For additional context beyond this collection, see the material published by Robert Half.
What the first finished piece of work supplied, beyond itself
How the review process actually runs
worked out3Learned by going through it, which no explanation would have taught
Who looks at this kind of change
worked out3Two names you did not have before
That the test suite takes forty minutes
worked out3Nobody mentions this until you are waiting for it
What the team considers finished
you asked4Asked after the first review came back with three comments
That deployment happens on Tuesdays and Thursdays
told3Volunteered by the reviewer, who assumed you knew
Where the staging environment is
you asked3Asked in the middle of the work, and answered in a minute
six things you had to know · one of them somebody told you · the median arrived in week 3 · the other five you went and got
Six things, all of them learned from one small piece of work in week three. None of them would have been learned from any amount of reading, and nobody would have thought to tell you. One person's own first month.
Finish something small in the first three weeks. It does not much matter what.
The point is not the output. It is that getting anything through an organisation's process end to end teaches you more about the place than a month of reading, and there is no other way to learn it.
What finishing teaches
Everything between having done something and having it in use.
Where the code or the document goes. Who reviews it and what they look for. How long the tests take. What the team considers finished. When things are released. What happens if it goes wrong.
None of that is written down anywhere, and nobody will think to explain it, because for everybody else it is not information — it is how Tuesday works.
Why small
Because the purpose is to traverse the whole path, and a large piece of work does not finish.
A two-day task that goes all the way through is worth more in week three than a three-week task that is still open at the end of the month. The first teaches you the path; the second teaches you that you are slow, which is both unpleasant and untrue.
| Good first work | Poor first work |
|---|---|
| A small fix with a clear end | A redesign of anything |
| Something somebody is waiting for | Something nobody asked for |
| Something with an existing example to copy | Something with no precedent |
| Something reversible | Anything that cannot be undone |
Finding one
Ask, in the form that makes it easy to answer.
Is there anything small and real I could pick up this week? I would rather learn the process on something that matters than on a toy.
Most managers have a list of small things nobody has got to. If yours does not, three sources are always available: the setup instructions that did not work when you followed them, the documentation that was wrong, and whatever the team complains about in passing that takes under a day.
The thing not to do
Do not make the first thing a proposal.
A new person's first contribution being a document about how something should be restructured is received as a problem even when it is correct, because it arrives from somebody who has not yet done anything and does not know what they cannot see.
Do the small thing first. The proposal, if it still seems right in month three, will be read entirely differently by then.
Going slowly on purpose
Your first piece of work will take four or five times as long as the same work in month six. This is correct and expected and almost nobody tells new people so.
Most of the time is not the work. It is finding where things go, waiting for access, running the tests twice because you did not know they take forty minutes, and discovering what the review expects.
Say so when you report it, lightly, once:
Took most of two days, which is mostly me learning where everything is. I would expect the next one to be an afternoon.
That is useful information for your manager and it forestalls a misunderstanding neither of you would otherwise have noticed forming.
What it gets you
Three things by the end of week three, which is early.
Something you can point at, which matters more than it should in a first month, for reasons covered in the note on signals.
Two or three names you did not have, acquired because a review puts you in contact with whoever looks at this kind of thing.
And the end of the particular unease of having produced nothing, which is the thing most new remote joiners are actually carrying around in week three and almost never say out loud.
Telling somebody it is done
A finished thing nobody knows about is, for most practical purposes, not finished.
One line, in the channel, when it goes out.
The setup instructions are updated — two of the steps pointed at the old vault. Should work end to end now; shout if not.
That is not self-promotion and it does not read as any. It is how work becomes visible in an organisation where nobody can see you, and it is the same sentence everybody else posts about their own work.
New people frequently skip this, on the grounds that the thing was small and announcing it would be making too much of it. The result is a first month in which three or four things were done and nobody outside knows about any of them.