The one idea
For the first few weeks, your job is not to add value. Your job is to understand the system well enough that your changes will survive.
That feels passive and it is not. Observing properly is hard work, and the people who do it well become useful faster — because their first suggestion lands instead of being politely absorbed and ignored.
Spend the first weeks learning how things work before trying to change how they work.
Build a map of people, tools, processes and vocabulary first. Then take ownership of something small. Then improve one thing you have personally done several times.
You are acquiring the undocumented constraints. Every odd process encodes a past failure, and changes proposed without knowing those constraints reintroduce the failure they were designed to prevent.
The core mistake
Almost everyone arrives determined to prove they were worth hiring.
It is completely understandable. You feel like an expense that has not yet earned itself, so you look for something to demonstrate competence on. The fastest available demonstration is finding a flaw and naming it.
The problem is that you are seeing the system without its history. That strange approval step exists because of an incident in 2023. That spreadsheet is ugly because the tool that would fix it is not approved by security. When you name a flaw in week one, the people who lived through the history hear: this person thinks we are stupid and has not asked why.
The reframe is small and it changes everything. You were not hired to have opinions in week one. You were hired for a year, or five. Spend three weeks buying the right to be listened to.
The four weeks
| Week | Your job | What you produce |
|---|---|---|
| 1 | Observe | A written map: people, tools, processes, vocabulary |
| 2 | Learn the workflows | Ability to do one recurring task by following the steps |
| 3 | Own something small | One task that is genuinely yours, done reliably |
| 4 | Improve one thing | One small, specific improvement to work you have done |
Week 1 — observe
Five things to collect, in writing:
People. Who does what, who you depend on, who depends on you. Names and faces. Write down what each person is working on when you meet them.
Tools. Every system you will touch, and what it is actually used for. Getting access takes longer than you expect — start every access request in week one, even for things you will not need until week three.
Processes. How work arrives, gets approved, gets delivered. Where it queues.
Vocabulary. Every acronym and internal name you hear. Keep a running list. Most teams have twenty or thirty terms that are used constantly and explained nowhere.
Expectations. What good looks like for your role, in specifics. This one you have to ask for directly.
End of your first week, ask your manager for fifteen minutes and ask these four questions:
"What does good look like in this role after three months?"
"What's the most common way someone new here gets it wrong?"
"How do you prefer to be updated — messages as things change, or a summary once a week?"
"Is there anything you're expecting me to pick up that I might not know about yet?"
The second question is the valuable one. Managers almost always have a specific answer, they are rarely asked, and the answer tells you exactly what to avoid.
Week 2 — learn the workflows
Stop collecting names and start following work end to end. Pick the recurring task your team does most and trace it from the moment the request arrives to the moment someone signs it off.
Ask to watch someone do it, then do it yourself with them watching. If an SOP exists, follow it exactly, including the steps that look pointless. Note which steps look pointless — that list is useful in week four, but only after you have done it enough times to know why they are there.
Week 3 — own small things
Ownership means something specific: it does not come back to anyone else. If the weekly report is yours, nobody should have to remember to remind you, and if something is wrong with it, you notice before the recipient does.
Small and reliable beats large and shaky. A new person who owns one recurring task perfectly for a month is trusted with something bigger. One who takes on something ambitious and needs rescuing is not, for a while.
Week 4 — improve one thing
Now you have earned it. Pick one thing you have personally done at least three times, and make it slightly better. Not the department's structure. Not the tool choice. A checklist for a fiddly task. A template for a message you send weekly. Ten minutes cut from something you do every day.
Propose it as a question, not a verdict.
The weak version, which is what most new people send:
"I noticed the weekly report process is really inefficient. We should automate it."
The version that gets a yes:
"I've run the weekly report four times now. Steps 3–5 are copy-paste between the same two sheets and take about twenty minutes. I think a formula would do it in one — I've built a version on a copy to test it, and it matches last week's output exactly. Worth me switching it over, or is there a reason it's manual?"
Four things are doing the work there: you have done it yourself, the problem is specific, you tested against known-good output, and the last clause genuinely invites the history you might not know.
Running your first month
1 of 6Start a single running document on day one. One place. Sections for people, tools, vocabulary, questions, and things that look odd. Do not rely on memory during a period when you are meeting forty new things a day.
Try this
Day three. Your manager says in passing:
"Oh, can you take over the vendor tracker from Ananya? She'll show you."
Ananya walks you through it in eleven minutes, mentions three things she does "but they're not really written down anywhere", and goes on leave for two weeks.
What do you do before she leaves?
Your challenge
Level 3 · IndependentWrite your own thirty-day plan before your next first day — or, if you are already in a job, write the version you wish you had.
It must contain: five people you need to know and why, every system you need access to, the recurring task you intend to own by week three, and the four questions you will ask your manager in week one.
You have succeeded when someone else could read it and tell you what you would be able to do by day thirty. Vague plans produce vague months.
What people usually get wrong
- Arriving to prove you know everything. The correct opening move is curiosity. The proving happens in month three, with evidence.
- Not writing things down. You will be told a name, a process and an acronym in the same sentence and remember none of them by Thursday.
- Asking nothing because you fear looking stupid. Silence in week one reads as competence. In week six it reads as a problem. The cost of the question only goes up.
- Asking everything immediately. Interrupting a busy person eleven times a day is its own failure. Batch, and mark what is genuinely blocking.
- Taking on something big to impress. Being rescued costs more trust than starting small earns.
- Waiting to be given work. If you finish, say so and ask what would be most useful. Idle silence is noticed.
- Criticising the last person who had your job. Even when they left a mess. Someone hired them, and someone let it happen.
How someone experienced does it
People who are good at starting jobs treat the first month as research with a deliverable, not as a waiting period. They can tell you by week four who actually decides things, which process everyone quietly works around, and where the real risk in their team's work sits.
They also manage the one thing beginners never think about: the story their manager tells about them. At thirty days, your manager will be asked "how's the new person working out?" She needs a concrete sentence. "She's taken the vendor tracker off my plate completely and it hasn't come back once" is a good one. "Seems keen" is what she says when you have not given her anything better.
The most underrated move is asking, at week four, "what would make your life easier that nobody has time to do?" It is a short list, it is usually unglamorous, and doing one item on it buys you more standing than three months of assigned work.
When not to use this
This plan assumes a functioning team with actual work to give you. Two situations break it.
If you have been given nothing to do by week two despite asking twice, that is not your onboarding failing — it is a management problem, and the move is to raise it directly and in writing rather than to keep quietly waiting.
And if you have been hired specifically to fix something — brought in as a senior person with an explicit mandate — the observation period compresses to days, not weeks. But even then, ask what has already been tried before proposing anything. That question has never once made someone look weaker.
What to do when the onboarding is genuinely bad
Plenty of organisations have no onboarding at all. You are given a laptop, a seat and a vague brief, and everyone is too busy to explain.
This is common and it is survivable. Three moves help.
Find the person who has been there two years, not ten. They remember being confused and still know everything. They are usually more use than your manager for the everyday questions.
Read the artefacts. Old reports, past decks, the shared drive, closed tickets, the last six months of the team's main channel. An hour in the archive teaches you the vocabulary and the history nobody has time to narrate.
Write the onboarding document you were not given. Keep it as you learn. At day thirty it becomes the thing you hand the next person, and it is the single most reliably appreciated contribution a new joiner can make.
Prove it
Produce the running document from step one — people, tools, vocabulary, questions, odd things — and keep it for four weeks.
At day thirty, look at the "odd things" list. Circle the items that explained themselves, and pick one of the rest. That is your first improvement proposal, and you now have four weeks of evidence behind it.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned starting a new job well in the first month. Assume I am intelligent but relatively new to this — treat me as beginner level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood starting a new job well in the first month. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at starting a new job and becoming useful quickly — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.