First work
The Documentation Only You Can Fix
You are the only person in the organisation who has recently followed the instructions, which makes fixing them the one contribution you are uniquely able to make.
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 fair pilot begins with a baseline rather than a guess; managers can see the service details and compare the first weeks before and after changing documentation or support.
A useful independent source for this stage of work is Adecco.
Six things that were documented wrongly, and how long each stayed wrong
The setup instructions had two dead steps
written down1Wrong for about two years; you were the first person to follow them in that time
The handbook contradicted the induction on expenses
written down3Wrong since the policy changed, which was a year earlier
The deploy guide in the repository was superseded
written down6Nobody had marked the old one; both were still linked
The on-call page listed somebody who had left
written down4Eight months out of date
The architecture diagram showed a service that no longer exists
written down9Noticed, and never fixed, because by then you no longer cared
The glossary did not define the three terms you most needed
worked out2Not wrong, just absent
six things you had to know · nobody told you any of them · the median arrived in week 4 · all six you went and got
Six documents, five of them wrong rather than missing. Four were fixed by you in your first month, one was noticed too late to bother with, and all six had been wrong for between eight months and two years. One person's own twelve weeks.
In your first fortnight you will follow setup instructions that do not work, read a handbook that contradicts something you were told, and find two documents that disagree.
You are, at that moment, the only person in the organisation who can see any of it. Everybody else did this years ago, from memory, with a colleague next to them.
Why it stays wrong
Not neglect. Nobody reads the setup instructions after their first week — and nobody rewrites a document they do not read.
The instructions were correct when they were written. Then a step changed, and the only people who would have noticed were new, and new people assume the instructions are right and that they are doing it wrong.
In the panel above, two years.
Why this is the right first contribution
Four reasons, and together they make it the most reliable opening move available to anybody joining anywhere.
It requires no permission. It requires no context you do not have. It is visible — a document with your correction in it is a thing somebody notices. And it is uniquely yours: of everything you could do in week two, this is the only task for which being new is a qualification.
How to do it without annoying anybody
Fix it. Do not report it.
A message saying "the setup instructions are wrong" creates a task for somebody. The same observation with the correction already made creates nothing and is received entirely differently.
I have updated the setup page — two of the steps referred to the old vault and I got stuck on them yesterday. Shout if I have got any of it wrong.
That is the whole announcement. The last clause matters: you are new, you may have misunderstood why a step was there, and inviting the correction costs nothing.
What to fix and what to leave
| Fix it | Leave it |
|---|---|
| A step that does not work | A document you think is badly organised |
| A dead link | A tone you would have written differently |
| A name of somebody who left | Anything expressing a decision you do not understand |
| A contradiction between two documents | Anything you would be rewriting rather than correcting |
The right-hand column is the important one. Correcting a factual error is obviously welcome. Reorganising somebody's document in your second week is not a correction, it is a judgement, and it will be read as one.
The contradiction case
Where two documents disagree you cannot simply fix it, because you do not know which is right.
Ask, narrowly, and offer to do the work:
The handbook and the induction say different things about expenses — is the handbook the current one? Happy to update whichever is wrong if you tell me which.
That is a four-second decision for the reader and it ends with the problem solved rather than noted.
Writing down what was not there
The sixth row of the panel is a different case: nothing was wrong, something was simply absent.
Those are the entries that come out of your own questions. Every answer you get in your first month that was not written down anywhere is a candidate, and the note on asking the same thing twice covers the habit.
Four lines in the obvious place, with the date on them. By the end of your first quarter you will have added six or eight such entries, which is more documentation than most teams produce in a year, and all of it is the by-product of being new.
The window
About eight weeks, and then you stop seeing it.
The architecture diagram in the panel was noticed in week nine and never fixed, and the reason given is the honest one: by then it no longer mattered to the person who had noticed. They had learned the real shape and the diagram had become somebody else's problem.
That is what the end of being new looks like, and it is why this particular contribution has to be made early or not at all.
Doing it without a process
Some organisations have a formal route for documentation changes and most do not.
Where there is one, use it; it will be slower and it keeps you out of an argument about ownership.
Where there is not, the question is whether to edit directly or suggest. The answer depends on one thing: whether the document has an obvious owner. A page that one person plainly maintains gets a message; a page that belongs to everybody and nobody gets edited.
Either way, say what you did afterwards. An unannounced edit to a shared document occasionally alarms people, and one line in the channel removes that entirely.
I have fixed two dead steps on the setup page — shout if there was a reason they were there.