Asking
The Question That Is Really a Decision
Many of the questions a new person asks are decisions in disguise, and converting them back into decisions is the fastest way to stop needing supervision.
What the people on this page had to find out, and where from
How to get a staging database password
you asked2The answer was one sentence and had no owner
Why the retry limit is three and not five
you asked9The reason existed and was in one person's head
two things you had to know · nobody told you any of them · the median arrived in week 9 · all two you went and got
Two answers that existed only in somebody's head. The second sat in the question list for a month before it was asked.
For remote onboarding, remote employee work tracking adds a practical reference for time, activity, projects, and reports when the team reviews early progress.
The wider workplace question can also be checked against resources from SimplyHired.
Six things that were settled by deciding rather than by asking
Which naming convention to use
worked out3Decided, stated, and nobody objected
Which of two deploy guides to follow
worked out6Decided by checking which matched the scripts, and said so
Whether to write the migration in one step or two
worked out5Decided; the manager had no view and was glad not to be asked
Whether a change needed a review
you asked2A genuine question with a policy behind it
Whether you could spend a day on the setup documentation
you asked2A genuine question, because it was about your time
What the tolerance on the import should be
told7Not yours to decide, and somebody said so, which was the right outcome
six things you had to know · one of them somebody told you · the median arrived in week 5 · the other five you went and got
Six items, three of which you decided and announced, two of which were real questions, and one of which you would have been wrong to decide. Nobody objected to any of the three. One person's own twelve weeks.
A large share of what new people ask is not a question. It is a decision they are reluctant to make.
"Should I use camel case or snake case here?" "Should I do this in one step or two?" "Should I put this in the handbook or the repository?"
Nobody is waiting to give you the answer. There usually is not one.
Why it matters
Each of these, asked, costs somebody a few minutes and costs you something larger: a small accumulating impression that you require direction.
Nobody forms that impression from any single question. It forms from a pattern over six or eight weeks, and by the time it has formed it is very hard to reverse, because it has become how people deal with you.
The conversion
Decide. Say what you decided. Offer to change it.
I have used snake case for the new columns to match the rest of the table, rather than camel case like the newer code. Say if you would rather I did it the other way.
One sentence of decision, one of reasoning, one of invitation. It requires no reply if the reader agrees, which is most of the time, and it gets corrected in four words if they do not.
Compare "should I use camel case or snake case?", which requires a reply, a small amount of thought, and leaves the reader slightly responsible for a thing you could have settled.
Which are real questions
Three kinds, and they are identifiable.
Anything with a policy behind it. Whether a change needs a review. Whether you may deploy on a Friday. Whether a document can be shared outside. There is an answer, somebody knows it, and guessing is expensive.
Anything about your own time. Whether to spend a day on something. That is a priority question and priorities are your manager's.
Anything irreversible. If being wrong cannot be undone cheaply, it is not a decision to make alone in your first month, however obvious it looks.
Everything else is yours.
| What you want to ask | What it actually is |
|---|---|
| Which convention should I use? | A decision; pick one and say so |
| Should I do this in one step or two? | A decision |
| Can I deploy this today? | A question, if there is a policy |
| Should I spend tomorrow on the docs? | A question about priority |
| Is it all right if I rename this table? | A question, if it is irreversible |
The fear
That deciding wrongly in your first month is worse than asking.
It is not, and the asymmetry is clear once stated. A wrong convention costs somebody a five-word correction. A pattern of not deciding costs you the assumption of competence, which is the thing your next six months runs on.
The only case where this does not hold is the irreversible one, which is why it is on the list above.
The item you should not decide
In the panel above, one of six was something the person would have been wrong to settle alone: the tolerance on the import, which had consequences they could not see.
Somebody told them so, and that was the correct outcome. If you announce a decision that is not yours to make, you will be told, once, cheaply — which is a far better way to find the boundary than never testing it.
What this looks like by month three
You will stop noticing you are doing it.
The announcement shrinks to a line in a pull request or a sentence in a status note, the invitation to object disappears because it is understood, and somewhere around the end of the first quarter you will be making the same decisions without mentioning them at all. That is what the end of onboarding actually looks like.
The three-week version
Early on, state the decision and the reasoning. Later, just the decision.
In week two: "I have used snake case to match the rest of the table, rather than camel case like the newer code. Say if you would rather I did it the other way."
In month three: "Used snake case for consistency with the table."
In month six: nothing. It is in the change, anybody can see it, and announcing it would be strange.
The reason to start with the long version is not deference; it is that in week two you genuinely do not know whether this is a convention with a reason behind it. By month three you do, and the sentence shortens because it has stopped carrying a question.
That shortening is a reasonable way to tell how onboarding is going, and it happens without anybody deciding it should.