First work
The First Time You Break Something
Everybody breaks something in their first month. What is actually assessed is how long it took you to say so.
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.
When a new employee is learning an unfamiliar workflow, managers can visit the official software page to understand where time is going before assuming that a slow start is an effort problem.
New employees and managers can compare this approach with guidance available from Hays.
Four occasions of having broken something, and how long each sat before it was said
The build broke after your first commit
1 hanswer: 20 minYou waited because you wanted to fix it yourself first. A reasonable instinct, and it cost an hour of everybody's red build
You deleted the wrong branch
0.25 hanswer: 2 minYou waited because you said so within fifteen minutes. Restored in two minutes by somebody who had done it before
A migration ran on the wrong environment
0.5 hanswer: 9 minYou waited because you said so immediately. Nine minutes, and the staging data was rebuilt that afternoon
A document you edited turned out to be the shared template
0.5 hanswer: 3 minYou waited because you said so as soon as you realised. Reverted from history in three minutes
four occasions · 2.25 hours spent stuck · 34 minutes of answers · the longest single wait was 1 hour
Two and a quarter hours across four mistakes, and one hour of it belongs to the first, where the instinct was to fix it quietly. The three that were reported inside half an hour were resolved in fourteen minutes between them. One person's own first quarter.
You will break something in your first month. Almost everybody does, it is expected, and nobody will think less of you for it.
What is noticed, and what people remember, is how long it took you to say.
The instinct
Fix it quietly first.
This is a reasonable instinct, it comes from a decent motive, and across a first month it is the single most expensive habit available. While you are fixing it quietly, the build is red for everybody, or the staging data is wrong, or somebody else is debugging a problem you caused.
The cost of saying is about fifteen seconds. The cost of not saying is everybody else's time, spent on something only you can explain.
The message
Short, factual, no apology, and with what you are doing about it.
I think I have broken the build — my commit from ten minutes ago. Looking at it now. Will shout if I cannot fix it in the next fifteen minutes.
Four elements: what, which change, that you are on it, and when you will escalate. Nobody needs anything else, and the last one is the part that matters: it tells people whether to wait or to act.
Why this goes well
Because it is the opposite of what people brace for.
An organisation's experience of new people breaking things is usually one of discovering it afterwards. A new person who says so immediately, with specifics, is doing the thing senior people do, and it is noticed disproportionately.
In the panel above, three of the four were reported within half an hour and were resolved in fourteen minutes between them. The one that was not cost an hour on its own, and the difference was not the mistake — it was the reporting.
What not to do
Do not apologise at length. One "sorry" at most, and preferably none in the first message, where it uses up the space that the facts need.
Do not explain why it happened before it is fixed. The explanation is for afterwards, if anybody wants it, and in the middle of a red build it reads as defending yourself rather than helping.
Do not disappear. The worst version of this is a new person who breaks something, says nothing, and goes quiet for two hours while they try to fix it. From outside, that is indistinguishable from not having noticed.
Afterwards
One short note, if the thing was more than trivial, and it is worth writing even if nobody asks.
For the record: the migration ran against staging because the environment variable defaults to staging and I assumed it defaulted to local. I have added a line to the runbook.
That does two things. It closes the matter, so that nobody is left wondering whether it will happen again. And the last sentence converts a mistake into a small improvement, which is the only way any of this genuinely stops recurring.
The thing nobody tells you
The environment you broke was breakable.
If a new person in week three can take down staging by running a command that is in the documentation, that is a fact about the setup rather than about the person. Nobody will say this to you, and in most places somebody senior will be quietly aware of it.
You are not well placed to make that argument in week three. You are well placed to write the extra line in the runbook, and that is the version of it that actually helps.
What this buys
The first mistake handled well is worth more than the first three pieces of work.
It is the fastest available way to establish that you can be trusted with things, because trust in an organisation is mostly about whether people find out from you or from somebody else.
What to do if you are not sure it was you
Say so anyway, with the uncertainty in it.
The build has been red since about ten. I think it might be my commit, though I am not certain — looking now.
A new person who waits to be sure before reporting usually waits twenty minutes, which is twenty minutes in which nobody else knows either.
The cost of being wrong about this is nothing at all. Nobody has ever thought less of somebody for saying they might have broken something and turning out not to have. The cost of being right and silent is everybody else's morning.
The same applies to things you did not break. A new person who reports that something looks wrong is doing exactly what anybody would want, and the reflex not to — because you are new, and probably misunderstanding — is worth overriding.