{"course":{"slug":"ai-careers","title":"Working in AI","url":"https://addaly.com/learn/ai-careers","level":"beginner","track":"work"},"lesson":{"slug":"the-first-ninety-days","title":"The first ninety days","url":"https://addaly.com/learn/ai-careers/the-first-ninety-days","position":77,"of":85,"minutes":8,"answer":"Reproduce other people's numbers before you propose changing anything, because the mess usually encodes a reason you do not know yet.","keyIdea":"Reproduce other people's numbers before you propose changing anything, because the mess usually encodes a reason you do not know yet."},"body":{"format":"markdown","text":"## The pattern that wastes two years\n\nA 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.\n\nThe 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.\n\nYou are not being asked to accept it for ever. You are being asked to find out first.\n\n## The read-only month\n\nSpend your first four weeks reproducing the numbers the team already reports.\n\nPick the three figures leadership sees monthly. Work out, from source, how each is produced. Then reproduce them yourself and compare.\n\nOne 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.\n\n## The map to build in your head\n\nBy the end of month one you want to be able to answer:\n\n- Where does the data come from, and which system is authoritative when two disagree?\n- Which table do people actually trust, and which one is deprecated but still queried?\n- What are the five questions leadership asks every month?\n- Who do I ask about what? Names, not teams.\n- Which dashboard do people actually open, and which ones does nobody look at?\n- What broke most recently, and why?\n\nThat last question is the fastest route to understanding a system. Ask someone to tell you about the last incident.\n\n## Small useful things, delivered early\n\nBetween weeks two and four, ship something small. Not a platform. Candidates:\n\n- The query somebody runs by hand every Monday morning.\n- A filter that has been wrong on a dashboard for months and everyone works around.\n- Documentation of the thing nobody documented.\n\nThe 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.\n\n> Figure: The first ninety days. Timeline: Week 1, Ask somebody to tell you about the last incident. Start the map: which system is authoritative, which table people trust, the five monthly questions.; Weeks 1–4, Reproduce the three figures leadership sees monthly, from source. A mismatch is brought as a question, never an accusation.; Weeks 2–4, Ship one small thing: the Monday query, the filter that has been wrong for months, the document nobody wrote.; Week 3, Write down what confuses you, while you can still see it. The most-read document on the team is usually the newest hire's.; Day 90, Now propose a change, knowing what the mess encodes and who put it there.. Reproduce before you propose. The ugliness in a working system usually encodes a person or a regulation you have not met yet, and the rewrite proposed in week two is what turns a new hire into the person who criticised things they did not understand.\n\n## The document that makes you valuable in week three\n\nWrite 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.\n\nDo 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.\n\nOnboarding 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.\n\n## Asking questions well\n\nThe fear is looking stupid. The actual failure is guessing quietly for three days and producing something wrong.\n\nTwo 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.\n\n## When the read-only month is impossible\n\nSometimes 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.\"*\n\nNaming 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."},"check":{"question":"Two weeks into a new data job, you find the main pipeline contains a hard-coded exception that treats one large customer's orders differently, with no comment explaining why. What should you do?","options":[{"text":"Remove it, since undocumented special cases are exactly the kind of technical debt a new hire should clear.","correct":false,"tempting":"Acts on the correct general principle while the specific reason is still unknown, which is how new hires break invoicing for the company's biggest account."},{"text":"Leave it alone entirely; existing code is the team's decision and not a new person's business.","correct":false,"tempting":"Overcorrects into passivity, and the point of the read-only month is investigation, not silence."},{"text":"Find out who wrote it and why, ask them directly, and write the answer into a comment or the documentation: the reason is almost always a real constraint, and recording it is the useful contribution.","correct":true},{"text":"Write a proposal documenting the debt you have found and present it to the team as an improvement plan.","correct":false,"tempting":"Produces a critique before understanding, which is the specific move that costs new hires their credibility in the first month."}]},"prev":{"slug":"when-freelancing-is-wrong","title":"The conditions under which you should take the job","url":"https://addaly.com/learn/ai-careers/when-freelancing-is-wrong"},"next":{"slug":"reading-code-you-did-not-write","title":"Landing in a codebase nobody documented","url":"https://addaly.com/learn/ai-careers/reading-code-you-did-not-write"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The first ninety days', in Working in AI. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/ai-careers/the-first-ninety-days (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The first ninety days","courseTitle":"Working in AI","module":{"index":9,"slug":"staying","title":"Staying: the first ninety days and the ten years after"},"answer":null,"keyIdea":"Reproduce other people’s numbers before you propose changing anything, because the mess usually encodes a reason you do not know yet.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure 9.1","figure":{"type":"timeline","title":"The first ninety days","events":[{"when":"Week 1","what":"Ask somebody to tell you about the last incident. Start the map: which system is authoritative, which table people trust, the five monthly questions."},{"when":"Weeks 1–4","what":"Reproduce the three figures leadership sees monthly, from source. A mismatch is brought as a question, never an accusation."},{"when":"Weeks 2–4","what":"Ship one small thing: the Monday query, the filter that has been wrong for months, the document nobody wrote."},{"when":"Week 3","what":"Write down what confuses you, while you can still see it. The most-read document on the team is usually the newest hire’s."},{"when":"Day 90","what":"Now propose a change, knowing what the mess encodes and who put it there."}],"caption":"Reproduce before you propose. The ugliness in a working system usually encodes a person or a regulation you have not met yet, and the rewrite proposed in week two is what turns a new hire into the person who criticised things they did not understand."},"alt":"Figure: The first ninety days. Timeline: Week 1, Ask somebody to tell you about the last incident. Start the map: which system is authoritative, which table people trust, the five monthly questions.; Weeks 1–4, Reproduce the three figures leadership sees monthly, from source. A mismatch is brought as a question, never an accusation.; Weeks 2–4, Ship one small thing: the Monday query, the filter that has been wrong for months, the document nobody wrote.; Week 3, Write down what confuses you, while you can still see it. The most-read document on the team is usually the newest hire’s.; Day 90, Now propose a change, knowing what the mess encodes and who put it there.. Reproduce before you propose. The ugliness in a working system usually encodes a person or a regulation you have not met yet, and the rewrite proposed in week two is what turns a new hire into the person who criticised things they did not understand."}},"blocks":[{"t":"h2","id":"the-pattern-that-wastes-two-years","runs":[{"text":"The pattern that wastes two years"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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 "},{"text":"amount_2","code":true},{"text":": each has a story, and the story is usually a person or a regulation rather than laziness."}]},{"t":"p","runs":[{"text":"You are not being asked to accept it for ever. You are being asked to find out first."}]},{"t":"h2","id":"the-read-only-month","runs":[{"text":"The read-only month"}]},{"t":"p","runs":[{"text":"Spend your first four weeks reproducing the numbers the team already reports."}]},{"t":"p","runs":[{"text":"Pick the three figures leadership sees monthly. Work out, from source, how each is produced. Then reproduce them yourself and compare."}]},{"t":"p","runs":[{"text":"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: "},{"text":"”I get 14,120 and the report says 14,200: what am I missing?”","i":true},{"text":" That sentence has started more good careers than any rewrite proposal."}]},{"t":"h2","id":"the-map-to-build-in-your-head","runs":[{"text":"The map to build in your head"}]},{"t":"p","runs":[{"text":"By the end of month one you want to be able to answer:"}]},{"t":"ul","items":[[{"text":"Where does the data come from, and which system is authoritative when two disagree?"}],[{"text":"Which table do people actually trust, and which one is deprecated but still queried?"}],[{"text":"What are the five questions leadership asks every month?"}],[{"text":"Who do I ask about what? Names, not teams."}],[{"text":"Which dashboard do people actually open, and which ones does nobody look at?"}],[{"text":"What broke most recently, and why?"}]]},{"t":"p","runs":[{"text":"That last question is the fastest route to understanding a system. Ask someone to tell you about the last incident."}]},{"t":"h2","id":"small-useful-things-delivered-early","runs":[{"text":"Small useful things, delivered early"}]},{"t":"p","runs":[{"text":"Between weeks two and four, ship something small. Not a platform. Candidates:"}]},{"t":"ul","items":[[{"text":"The query somebody runs by hand every Monday morning."}],[{"text":"A filter that has been wrong on a dashboard for months and everyone works around."}],[{"text":"Documentation of the thing nobody documented."}]]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-document-that-makes-you-valuable-in-week-three","runs":[{"text":"The document that makes you valuable in week three"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"asking-questions-well","runs":[{"text":"Asking questions well"}]},{"t":"p","runs":[{"text":"The fear is looking stupid. The actual failure is guessing quietly for three days and producing something wrong."}]},{"t":"p","runs":[{"text":"Two rules. "},{"text":"Thirty minutes stuck, then ask","b":true},{"text":", and say what you already tried, so the answer is quick to give. And "},{"text":"ask in a public channel","b":true},{"text":" 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."}]},{"t":"h2","id":"when-the-read-only-month-is-impossible","runs":[{"text":"When the read-only month is impossible"}]},{"t":"p","runs":[{"text":"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: "},{"text":"”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.”","i":true}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"Two weeks into a new data job, you find the main pipeline contains a hard-coded exception that treats one large customer’s orders differently, with no comment explaining why. What should you do?"}],"options":[{"text":[{"text":"Remove it, since undocumented special cases are exactly the kind of technical debt a new hire should clear."}],"correct":false,"tempting":[{"text":"Acts on the correct general principle while the specific reason is still unknown, which is how new hires break invoicing for the company’s biggest account."}]},{"text":[{"text":"Leave it alone entirely; existing code is the team’s decision and not a new person’s business."}],"correct":false,"tempting":[{"text":"Overcorrects into passivity, and the point of the read-only month is investigation, not silence."}]},{"text":[{"text":"Find out who wrote it and why, ask them directly, and write the answer into a comment or the documentation: the reason is almost always a real constraint, and recording it is the useful contribution."}],"correct":true,"tempting":null},{"text":[{"text":"Write a proposal documenting the debt you have found and present it to the team as an improvement plan."}],"correct":false,"tempting":[{"text":"Produces a critique before understanding, which is the specific move that costs new hires their credibility in the first month."}]}],"order":[3,2,0,1],"why":null},"prev":{"slug":"when-freelancing-is-wrong","title":"The conditions under which you should take the job","minutes":8},"next":{"slug":"reading-code-you-did-not-write","title":"Landing in a codebase nobody documented","minutes":9}}}