The first ninety days

The pattern that wastes two years

A new data hire arrives, reads the code, is appalled, and proposes a rewrite in week two. Everything they said was technically correct. Nobody agrees, the proposal dies, and they spend the next two years as the person who criticised things they did not understand.

The mechanism is simple and worth internalising: almost every piece of ugliness in a working system was put there deliberately by somebody solving a problem you have not met yet. The hard-coded exception for one customer, the pipeline that runs twice, the column called amount_2: each has a story, and the story is usually a person or a regulation rather than laziness.

You are not being asked to accept it for ever. You are being asked to find out first.

The read-only month

Spend your first four weeks reproducing the numbers the team already reports.

Pick the three figures leadership sees monthly. Work out, from source, how each is produced. Then reproduce them yourself and compare.

One of two things happens, and both are good. Your number matches, and you now understand the business’s definitions, which is most of what a new analyst is missing. Or your number differs, and you have found either your own misunderstanding or a real bug. Bring the difference as a question, never as an accusation: ”I get 14,120 and the report says 14,200: what am I missing?” That sentence has started more good careers than any rewrite proposal.

The map to build in your head

By the end of month one you want to be able to answer:

• Where does the data come from, and which system is authoritative when two disagree?
• Which table do people actually trust, and which one is deprecated but still queried?
• What are the five questions leadership asks every month?
• Who do I ask about what? Names, not teams.
• Which dashboard do people actually open, and which ones does nobody look at?
• What broke most recently, and why?

That last question is the fastest route to understanding a system. Ask someone to tell you about the last incident.

Small useful things, delivered early

Between weeks two and four, ship something small. Not a platform. Candidates:

• The query somebody runs by hand every Monday morning.
• A filter that has been wrong on a dashboard for months and everyone works around.
• Documentation of the thing nobody documented.

The purpose is not the value of the work. It is that you become somebody who finishes things, in the first month, when opinions are being formed.

The document that makes you valuable in week three

Write down what confuses you, as it confuses you. The acronyms, the table that is not what its name suggests, the two systems with similar names, the report that means something different from what it says.

Do it now, because in three months you will no longer be able to see any of it. That fluency is the whole problem: everybody who could write this document has forgotten what was hard.

Onboarding notes written by the most recent hire are usually the most-read document on a data team, and writing them is one of the cheapest ways to be visibly useful before you are technically productive. Keep it in the team’s wiki, or a markdown file in the repository if there is no wiki. Notion and Confluence are the paid tools; a text file in git works and is searchable.

Asking questions well

The fear is looking stupid. The actual failure is guessing quietly for three days and producing something wrong.

Two rules. Thirty minutes stuck, then ask, and say what you already tried, so the answer is quick to give. And ask in a public channel rather than a direct message, so the answer is searchable by the next person and so your colleague answers once rather than four times. A new person asking good questions in the open reads as engaged, not as struggling.

When the read-only month is impossible

Sometimes you are hired because things are on fire and there is no month to spend reading. That is a legitimate situation, and the response is to say plainly what you are skipping: ”I am going to fix the nightly failure first, which means I will not have reproduced the revenue figures before I touch this pipeline. I will come back to that in month two.”

Naming what you are trading is what distinguishes a deliberate shortcut from an accident. It also means that when something breaks, the conversation is about a known risk rather than about you.