The Analyst's First 90 Days: An Onboarding Plan for a New Company or Team

A good analyst onboarding runs in four phases over 90 days: orient in week one, map the domain, the people, and the systems in weeks two to four, contribute a first small deliverable between day 30 and day 60, and own a scope end to end between day 60 and day 90. Each phase ends with artifacts you wrote yourself, because onboarding is measured by what you can produce and prove, not by how many meetings you attended.

Most onboarding plans are written by the company and optimized for compliance: mandatory training, laptop setup, access requests, a list of people to meet. All necessary, none of it sufficient. Nobody hands you the thing you actually need, which is a plan for becoming useful on a system you have never seen, in a domain whose vocabulary is half familiar, with colleagues who are too busy to explain it twice.

This is part 1 of The First 90 Days, a series on succeeding in a new company or a new team as a technical analyst. This part is the plan. The next four parts each go deep on one lever: reading the documentation without believing all of it, building a personal knowledge pack with AI, asking the right questions, and giving feedback as the new person. Parts 6 to 10 apply those levers to your role, and part 11 closes with the review and the guide you leave behind.

What does a good first 90 days look like for an analyst?

It looks like a sequence of artifacts, each one a little more owned than the last. Here is the whole plan on one page before we go phase by phase.

Phase	When	Goal	What you produce
1. Orient	Week 1	Know where things are and who decides	Access checklist, manager agreement on day 90 success, first draft of the stakeholder map
2. Map	Weeks 2 to 4	Understand the domain, the people, and the system well enough to ask good questions	Glossary, stakeholder map, system map, questions log, documentation trust register, observation log
3. Contribute	Days 30 to 60	Ship one small thing someone else uses	First deliverable, 30 day readout of observations, one improvement proposal
4. Own	Days 60 to 90	Run a scope end to end	One feature or change from refinement to acceptance, 90 day review with evidence

The artifacts are the point. A glossary you wrote proves you understood the vocabulary. A system map you drew proves you know where a payment goes. A questions log proves you asked, and shows which answers are still missing. When your manager asks how onboarding is going, you show them the artifacts instead of saying “fine, still learning.”

Why does the analyst role need its own onboarding plan?

Because an analyst’s value sits in the gaps between other people’s knowledge, and on day one you do not know where the gaps are.

A developer joining a team can be productive on a well-scoped ticket in the first week. The codebase is the source of truth and the ticket says where to look. A tester can run the existing regression suite on day two. An analyst has no equivalent. Your raw material is the business rules, the system behavior, the stakeholder positions, and the undocumented decisions, and those are scattered across documents of mixed reliability, people with partial views, and code nobody has read end to end in years.

That is also why analysts who onboard well become valuable fast. By day 60 you may be the only person on the team who has recently read every page of the documentation, talked to every stakeholder group, and traced a transaction through every system. Long-tenured colleagues have deep knowledge of their corner. You have a fresh, complete, shallow map, and that combination is rare.

A real onboarding: joining a cross-border payments team mid-migration

On one programme I joined, a cross-border payments team at a large bank was eight months into its ISO 20022 work. The SWIFT CBPR+ coexistence period for payment instructions had ended in November 2025, so the outbound pacs.008 flow was live. The next hard date was November 2026, after which CBPR+ no longer accepts fully unstructured postal addresses: debtor and creditor addresses must be structured or hybrid, with at least town name and country in dedicated elements.

My brief on day one was one sentence: “help us get ready for the address change.” Here is how that turned into four phases.

Week 1, orient. I asked my manager what “ready” would mean at day 90, stated as something observable. The answer, after some back and forth: every outbound pacs.008 from our channels carries a structured or hybrid address, and operations has a repair process for the ones that cannot. That sentence became the baseline for everything else. I also asked who depended most on this work: payments operations (who repair rejected payments), the channel teams (who capture the address), the payment hub team (who build the pacs.008), compliance (who care about sanctions screening on address data), and the correspondent banking relationship managers (who hear about it when a correspondent rejects).

Weeks 2 to 4, map. I read the Confluence space, the mapping specification from MT103 field 50K and 59 to the ISO 20022 PstlAdr structure, and the CBPR+ usage guidelines on SWIFT MyStandards. I logged every term I did not know with a definition I could defend. I drew the system map by following one test payment from the corporate channel through the payment hub, sanctions screening, and the SWIFT gateway. And I started a documentation trust register, because the mapping page and the code disagreed about where the town name came from when the customer record had none.

Days 30 to 60, contribute. My first deliverable was a data profile: how many outbound payments in the last quarter, by channel, would fail the November 2026 rule if it applied today. It was a SQL query, a table, and two paragraphs. Nobody had produced that number before, and it immediately reshaped the plan, because one channel accounted for most of the unstructured addresses and the problem there was capture, not mapping.

Days 60 to 90, own. I owned the requirements and acceptance for the channel capture change: the structured address fields, the validation rules, the repair queue behavior for legacy beneficiaries, and the test cases for pacs.008 with hybrid addresses. At day 90 I had something specific to show in the review: a decision log, the data profile trend, and acceptance evidence.

None of that required genius. It required producing artifacts in the right order.

Week 1: how do you orient without wasting the first week?

Week one is about access, agreement, and people. Most analysts spend it reading randomly. Spend it instead on three things.

Access, chased like a project. Analysts need more access than most roles and usually get it last. List what you need on day one and chase it daily: Jira, Confluence, the code repository (read only is fine), the test environments, a read only database or reporting replica, the log platform, the monitoring dashboards, and the team channels. Access requests in a bank can take two weeks. Every day you wait is a day you cannot verify anything.

The day 90 agreement with your manager. Ask four questions and send the answers back in writing:

1. What does success look like at day 90, stated as something
   I could show you?
2. Who are the five people whose work depends most on mine?
3. What is the team currently blocked on that an analyst could unblock?
4. What should I not touch yet: a system, a stakeholder, a topic?

The fourth question saves careers. Every team has a stakeholder relationship that is being carefully managed, or a design decision that was painful and nobody wants reopened in week one by someone who does not know the history.

The first draft of the stakeholder map. From the manager’s answer to question 2, list the people, their role, what they need from you, and what you need from them. It will be wrong. That is fine; it is a draft you will correct in weeks two to four.

If you are new to the analyst role entirely, not just new to the company, the same four questions apply, but expect the learning curve on tooling to be steeper. Part 9, onboarding as a developer analyst, covers the repository, log, and SQL access you should push for regardless of your title.

Weeks 2 to 4: what should you map, and in what order?

Six artifacts, built in parallel, each one feeding the others. This is the heaviest phase and the one most analysts cut short because they feel pressure to deliver. Do not cut it. A shallow map makes every later week slower.

Artifact	What it holds	Deep dive
Glossary	Every term, acronym, and code you met, with a definition you can defend and its source	Part 3, AI knowledge pack
Stakeholder map	Who decides, who knows, who is affected, and how each prefers to be asked	Part 4, asking the right questions
System map	The systems a transaction touches, in order, with the messages between them	Part 10, systems analyst
Questions log	Every question asked, to whom, the answer, and the evidence for it	Part 4
Documentation trust register	Which pages you trust, which are stale, and what evidence contradicts them	Part 2, reading documentation
Observation log	Anything that looked strange, slow, or risky to fresh eyes	Part 5, giving feedback

Keep all six in one place you control: a personal Confluence page tree, an Obsidian vault, or a folder in the repository. Not in your head. The second brain approach works well here, because onboarding is exactly the moment when you take in more than you can remember.

The glossary is a test, not a list

In payments, the vocabulary is the domain. If you cannot say precisely what separates a pacs.008 from a pacs.009, or a pacs.004 return from a camt.056 recall request, you cannot write a requirement involving them. Write each definition in your own words and note where you confirmed it. When a colleague uses a term in a way that contradicts your definition, that is not embarrassing; it is information. Either your definition is wrong or the team uses the term loosely, and both are worth knowing.

The system map is a trace, not a diagram

Do not start by copying the architecture diagram. Start by following one real transaction in a test environment and writing down every system it touches. The diagram tells you what the architect intended. The trace tells you what happens. The difference between them is usually where the team’s problems live. The Northline Pay world on the Labs is a good place to rehearse this: practice onboarding on a system you have never seen, with a real API contract, events, and a database.

Days 30 to 60: what should your first deliverable be?

Small, real, verifiable within two weeks, and used by someone other than you. Those four conditions matter more than the topic.

Good first deliverables in a payments team:

• A reason code mapping table. Which ISO 20022 reason codes the system receives on pacs.002 and pacs.004 (AC01, AC04, AM04, AG01, BE04, RR04, MS03), what the customer sees for each, and which ones operations repairs manually. Often nobody has the full table.
• A data dictionary for one message. Every pacs.008 element your system populates, where the value comes from, and which ones are hard coded. See the data dictionary guide.
• A data profile. How many transactions would be affected by an upcoming rule change, by channel or by product, from a SQL query you can defend.
• A reproduced defect. Take an open defect nobody has had time for, reproduce it in a test environment, and write up the exact conditions. Developers remember who did that.
• A refreshed page. The most visited, most outdated page in the team’s space, rewritten with evidence and the owner’s sign off.

Bad first deliverables: a new process framework, a complete rewrite of the requirements template, or anything that requires the team to change how it works before you have earned the standing to ask.

At around day 30, present your observation log as a short readout. Fresh eyes expire: by day 60 the things that looked strange will look normal to you too. Part 5 covers how to frame those observations so they are heard as help rather than criticism.

If you want a structured reference for the technical side of this phase (reading code, querying data, and talking to engineers as equals), The Technical Skills Guide for BAs is built for exactly that gap.

Days 60 to 90: what does owning a scope mean?

It means one piece of work where you are the person who knows the answer, end to end. You took it into refinement, you wrote the requirements and acceptance criteria, you answered the developers’ questions, you checked the test evidence, and you stood behind it at the release decision.

Pick a scope that is meaningful but bounded. In the cross-border example above, it was the channel capture change for structured addresses, not the whole November 2026 readiness programme. A good test: could you explain the scope, its open risks, and its current status to a senior stakeholder in two minutes without notes? If yes, you own it.

Ownership also changes how you ask questions. In weeks two to four, you asked to learn. From day 60, you ask to decide: “I am proposing we reject at capture rather than repair downstream, here is the data, does anyone see a reason not to?” That shift is the clearest signal to the team that you are onboarded.

Is onboarding into a new team in the same company different?

Yes, and the difference catches experienced people out.

	New company	New team, same company
Network	Start from zero	Keep it, use it from day one
Tooling and access	Everything new	Mostly familiar, faster access
Domain	Possibly new	Often the same or adjacent
Team context	New	New, but you assume it is not
Risk	Slow start	Overconfident start

The internal mover’s trap is skipping the mapping phase. You know the company, you know the domain, you know half the people, so you go straight to contributing. Then in week three you propose something the team tried and abandoned last year, or you use a term the way your old team used it and cause a misunderstanding that lands in a specification.

Run the same four phases. Compress week one to two days. Keep weeks two to four, because the team’s context is the thing you are actually missing. A payments analyst moving from the SEPA team to the cross-border team knows ISO 20022 well, but the cross-border team’s usage guidelines are CBPR+, not the EPC rulebooks, their partners are correspondents rather than a clearing house, and their pain points (truncation on legacy MT channels at some correspondents, the address deadline, charges) are different from the 10 second execution window that dominates SEPA Instant.

How do you adapt the plan to your role?

The four phases are the same for every analyst. What changes is where you look first and what your first deliverable is. Pick your angle:

• Business analyst. Start with people and processes. Your first deliverable is usually a decision you unblock. Part 6: onboarding as a business analyst.
• Functional analyst. Start with the rules the system actually enforces, which are rarely the ones written down. Part 7: onboarding as a functional analyst.
• QA analyst. Start with environments, test data, and the suite you inherit. Part 8: onboarding as a QA analyst.
• Developer analyst. Start with the repository, the logs, and SQL access. Part 9: onboarding as a developer analyst.
• Systems analyst. Start by following one payment across the landscape. Part 10: onboarding as a systems analyst.

Most technical analysts wear more than one of these hats. Read your primary role first, then skim the one you wear second. The technical analyst skill matrix is a useful way to decide which one that is.

Where does AI fit in onboarding?

AI is the fastest way to turn a pile of unfamiliar documents into a glossary, a set of questions, and a first map, as long as you use your organization’s approved tool and never paste customer data, account numbers, or production identifiers into it. It is good at reading 60 Confluence pages and listing the terms, the contradictions, and the questions. It is bad at knowing which of those pages is true.

The pattern that works: ground the model on the documents you were given, ask it for questions rather than answers, and verify every claim against the system or a person. Part 3 builds this into a personal knowledge pack. If AI is new to you, start with AI for analysts: start here, and read the guardrails before you paste anything.

The printable checklist

Print this, or copy it into your notes, and tick it as you go.

Week	Done when	Check
1	All access requested and chased daily	[ ]
1	Day 90 success agreed with manager and sent back in writing	[ ]
1	First stakeholder map draft with at least five names	[ ]
2	Glossary started, every entry with a source	[ ]
2	Questions log started, every question with an owner	[ ]
2	One transaction traced end to end in a test environment	[ ]
3	System map drawn from the trace, reviewed by one engineer	[ ]
3	Documentation trust register covering the top 20 pages	[ ]
3	One to one conversation with every stakeholder on the map	[ ]
4	Observation log with at least ten entries	[ ]
4	First deliverable agreed with manager	[ ]
5 to 6	First deliverable shipped and used by someone else	[ ]
5	30 day readout presented	[ ]
7 to 8	One scope owned: requirements, acceptance criteria, questions answered	[ ]
9	Acceptance evidence for the owned scope reviewed	[ ]
12	90 day review held, with evidence	[ ]
12	Onboarding guide for the next joiner drafted	[ ]

The last line is not optional. Part 11 explains why the best proof that you are onboarded is the guide you write for whoever comes next.

What are the most common onboarding mistakes analysts make?

Waiting to feel ready before producing anything. You will not feel ready at day 30. Produce the glossary and the map anyway. Writing them is how you learn.

Believing the documentation. It was accurate when someone wrote it. Part 2 shows how to rate it.

Asking the same person everything. The friendliest senior developer becomes your entire onboarding, and by week three they are avoiding you. Spread questions across the stakeholder map and batch them.

Fixing before understanding. The strange process you want to fix on day ten usually exists because of an incident nobody told you about. Log it, ask about it, and propose a change after day 30.

Not writing anything down for the next person. Every team complains about onboarding. Almost nobody fixes it, because by the time they could, they have forgotten what it felt like.

The takeaway

The analyst’s first 90 days are four phases with artifacts at the end of each: orient and agree what day 90 success looks like, map the domain, the people, and the system in writing, contribute one small deliverable someone else uses, then own a scope end to end. The artifacts are both how you learn and how you prove you learned. Start the glossary, the questions log, and the observation log on day one, follow one real transaction before you trust any diagram, and keep the next joiner in mind from the start.

Next, read part 2, reading a new team’s documentation, then jump to your role angle in parts 6 to 10. The full path is on The First 90 Days.

For the technical skills that make the mapping phase faster (reading code, querying data, and working with APIs), The Technical Skills Guide for BAs is the companion reference. If this is your first analyst job rather than a new team, Land Your First Job carries a week-by-week plan through day 90. For the whole library in one purchase, the Complete Tech BA Bundle covers analysis, code, testing, and support, and the free downloads are a good place to start. If you want a second pair of eyes on your own 30 60 90 day plan, book a 1:1 coaching call.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Onboarding, Career Development, ISO 20022, Payments