The 90-Day Review: Prove Your Onboarding and Leave a Better Guide Behind

At day 90, score your onboarding against evidence in five areas (domain, systems, people, delivery, and tooling), take the artifacts that prove each score into the review with your manager, run a short retrospective on what slowed you down, and turn your notes into the onboarding guide for the next joiner. The guide is the strongest proof you are onboarded: you can only explain a team, a system, and a domain clearly once you understand them.

Most 90 day reviews are a conversation about feelings. “How are you settling in?” “Good, still learning a lot.” “Great, any concerns?” Twenty minutes, no artifacts, no decisions, and the manager’s impression of you is whatever they half remember from standups.

This is part 11 of The First 90 Days, the final part of a series on succeeding in a new company or team as a technical analyst. Part 1 set out the four phases and the artifacts each one produces. Parts 2 to 5 went deep on the levers: documentation, AI, questions, and feedback. Parts 6 to 10 applied them to each role. This part closes the loop: how to prove the onboarding worked, and how to leave the team better at onboarding than you found it.

Why does a 90 day review need evidence?

Because impressions are biased toward visibility, and analyst work is often invisible.

The developer who shipped a feature has a pull request. The tester who found a critical defect has a ticket. The analyst who prevented three defects by asking the right question in refinement has nothing, unless they kept a record. A review based on impressions systematically undervalues the work analysts do best: the question that saved a sprint, the contradiction caught before build, the stakeholder conflict resolved before it became an escalation.

If you followed the plan from part 1, you already have the evidence. You have been producing it since day one: the glossary, the system map, the questions log, the trust register, the observation log, the first deliverable, and the scope you owned. The review is where you put it on the table.

How do you score your own onboarding?

Use a rubric with five areas and four levels, defined in observable terms. Score yourself honestly, then name the evidence for every score.

Area	0: Not yet	1: Following	2: Contributing	3: Owning
Domain	Still learning the vocabulary	Can follow domain discussions, needs terms explained occasionally	Can explain the main flows and rules without notes	Others ask you to explain domain rules; you catch domain errors in others’ work
Systems	Knows system names only	Can describe what each system does	Has traced a transaction end to end; can find where something broke	Can predict the impact of a change across systems
People	Knows the immediate team	Has met every stakeholder on the map	Knows who decides what and how each prefers to be asked	Stakeholders come to you directly; you resolve disagreements between them
Delivery	Observing	Has contributed to someone else’s scope	Has shipped a deliverable someone else uses	Has owned a scope from refinement to acceptance
Tooling	Has access	Can navigate Jira, the wiki, and the repository	Can query data, read logs, and run tests independently	Has automated or improved a team workflow

A healthy 90 day profile for an experienced analyst in a new company is mostly 2s with one or two 3s and possibly one 1. In a complex domain like cross-border payments, domain is often the area that lags, and that is fine as long as you say so and have a plan.

Write the evidence next to each score:

Domain: 2
  Evidence: glossary (148 terms, each sourced); explained the pacs.002
  rejection flow to the new product owner without notes in week 10;
  caught BE04 vs AC01 confusion in the returns spec review.
  Gap: charges (DEBT/CRED/SHAR) and cover payments, not yet confident.

Systems: 2
  Evidence: system map reviewed by the hub tech lead; traced 3 test
  payments end to end; found the screening timeout in the defect PAY-2231.
  Gap: cannot yet predict impact of changes to the SWIFT gateway.

People: 2
  Evidence: stakeholder map with 14 people; 1:1 with every one;
  ops repair team now sends me address rejections directly.

Delivery: 3
  Evidence: owned channel structured address capture end to end;
  requirements, AC, test evidence reviewed, released in sprint 6.

Tooling: 2
  Evidence: read-only replica access; wrote the address profile query
  now used in the weekly readiness pack; can read gateway logs.
  Gap: no automation yet.

The rule that keeps this honest: a score you cannot point at evidence for is a hope. Lower it. Managers notice inflated self-assessments immediately, and they remember. They also notice a self-assessment that names its own gaps precisely, and they trust everything else in it more.

The technical analyst skill matrix is the longer-term version of this rubric. Use it after the review to set your next quarter’s targets.

What should you bring to the review with your manager?

Three things, on one page, sent the day before so the meeting is a discussion rather than a presentation.

1. The day 90 success statement you agreed in week one. Quote it exactly. In part 1 you asked your manager what success at day 90 would look like, stated as something observable, and sent the answer back in writing. Now you hold yourself to it. On the cross-border programme from part 1, the statement was: every outbound pacs.008 from our channels carries a structured or hybrid address, and operations has a repair process for the ones that cannot. At day 90, the honest answer was “two of three channels, repair process live, third channel scheduled for next quarter.”

2. The evidence. The scored rubric above, with links to the artifacts. Not the artifacts themselves; the links. Your manager can click if they want the detail.

3. The two weakest areas and a plan. Name them before your manager does. “Charges and cover payments are my weakest domain area. Plan: I will own the charges mapping review in Q1 and pair with the correspondent banking analyst on the pacs.009 COV flow.” This turns the review from an assessment into a planning conversation, and you are the one setting the plan.

90 DAY REVIEW: [Name], [Role], [Team]

AGREED IN WEEK 1
  "[Quote the day 90 success statement exactly]"

STATUS
  [Met / partly met / not met], in one sentence with the evidence.

SELF-ASSESSMENT (0 to 3, evidence linked)
  Domain    [n]  [link]
  Systems   [n]  [link]
  People    [n]  [link]
  Delivery  [n]  [link]
  Tooling   [n]  [link]

DAY 30 OBSERVATIONS: WHAT HAPPENED
  1. [Observation] > [adopted / parked / rejected, and why]
  2. ...

WEAKEST TWO AREAS AND PLAN FOR NEXT QUARTER
  1. [Area]: [specific action, owner, date]
  2. [Area]: [specific action, owner, date]

WHAT I NEED FROM YOU
  [One or two specific asks: access, an introduction, a scope]

The “what I need from you” line is the one most analysts leave out. Ask for something specific. A manager who has just seen evidence that you delivered is at their most willing to give you a bigger scope, an introduction to a senior stakeholder, or the access you have been waiting for.

How do you run an onboarding retrospective?

Briefly, honestly, and ideally with the team, because what slowed you down will slow down the next person too.

Day 90 is the last moment your memory of being new is still accurate. In another month, the access request that took three weeks will feel like a minor annoyance, the page that misled you will feel like something everyone knows is wrong, and the person you were afraid to ask will be a colleague you message without thinking. Capture it now.

Four questions, fifteen minutes:

ONBOARDING RETROSPECTIVE

1. What slowed me down most?
   (Name it specifically: the access request, the stale page, the
   missing environment, the meeting I was not invited to.)

2. What sped me up most?
   (The person, the document, the tool, the first deliverable.)

3. What was missing that I had to build myself?
   (Glossary, system map, list of who to ask, test data.)

4. What would I give the next joiner on day one?
   (The five things, in order.)

On the cross-border programme, my answers were roughly: slowed down by a two week wait for read only database access and by a pacs.002 rejection handling page that the code contradicted; sped up by one postmortem that explained more about the system than the whole specification folder, and by an operations lead who let me sit with the repair queue for a morning; missing a glossary, a system map, and any list of who owned which page; and on day one, the next joiner should get the access list with approvers named, the five postmortems worth reading, the glossary, the trust register, and an hour with the repair queue.

Present the retrospective as a short item in a team retro or a standup. Keep the tone factual. It is not a complaint about onboarding; it is the input to the next deliverable. Part 5 covers how to frame feedback so it lands, which applies just as much here.

How do you turn your notes into an onboarding guide for the next joiner?

Write it from the artifacts you already have. You are not starting from a blank page; you are editing three months of notes into the order a new person needs.

GitLab is the well known public example of written onboarding at scale. The company publishes its handbook openly, and its onboarding issue template, a checklist that every new team member works through, is public too. You do not need a company handbook to borrow the idea: onboarding written down, versioned, owned, and improved by every person who goes through it.

A team-level guide, kept in the wiki or the repository, with this skeleton:

# Onboarding: [Team name]

Owner: [name] · Last reviewed: [date] · Next review: [date + 6 months]
Previous joiner: [name], please update this page at your day 90.

## Day 1: access
| System | Why you need it | How to request | Approver | Typical wait |
|---|---|---|---|---|
| Jira project PAY | backlog, defects | IT portal > Jira | team lead | 1 day |
| Confluence space PAY | documentation | IT portal | team lead | 1 day |
| Repository payments-hub (read) | trace behavior in code | Git access form | tech lead | 3 days |
| Reporting replica (read) | data profiling | DB access form + training | data owner | 2 weeks, request first |
| Log platform | trace messages | IT portal | ops lead | 3 days |

## What success looks like at day 90
[Two or three observable outcomes, agreed with the manager.]

## The domain in one page
[The five message types and flows you must know, with links.]

## Glossary
[Link to the glossary, every term with a source.]

## The system map
[Link to the traced map, reviewed by an engineer, with the date.]

## The 20 pages worth reading, in order
| Page | Why | Trust level | Last verified |
|---|---|---|---|

## Postmortems to read first
[The five that explain the most about real behavior.]

## People: who to ask what
| Person / role | Ask them about | Prefers |
|---|---|---|

## Good first deliverables
[Three or four small, real, useful tasks a new analyst can ship.]

## Known traps
[Stale pages, misleading names, environments that differ from production.]

Three habits make the guide survive:

• Give it an owner and a review date. An unowned onboarding page becomes the next stale page in someone’s trust register.
• Link it from the next joiner’s first ticket. If it is not in their path on day one, they will not find it until week three.
• Ask the next joiner to update it at their day 90. The guide improves with every person, which is the whole point of the GitLab pattern.

If you keep your notes in an AI-queried vault or a context pack, drafting the guide is fast: ask your approved assistant to restructure your notes into the skeleton above, then edit and verify every line. If the guide lives in Confluence, Confluence for Business Analysts covers the page templates and review habits that keep it current.

What do the 30, 60, and 90 day readouts look like?

Three short checkpoints, each with a different purpose. They build on each other, and the day 90 review is easier because the first two happened.

Readout	Purpose	Content	Length
Day 30	Share fresh eyes before they expire	Observation log highlights, top contradictions from the trust register, the first deliverable plan	15 minutes, team audience
Day 60	Show contribution and ask for ownership	First deliverable and who uses it, the scope you propose to own, open risks	15 minutes, manager
Day 90	Prove onboarding and set the next quarter	Scored self-assessment, evidence, retrospective, weakest areas and plan, the onboarding guide	30 minutes, manager

The day 30 readout is covered in depth in part 5. The day 60 readout is the moment to ask for the scope you want to own, backed by the deliverable you just shipped. The day 90 review closes the cycle described in this article.

What does “onboarded” mean for each analyst role?

The rubric applies to every analyst, but the bar for delivery and tooling differs by role. In one line each:

• Business analyst. You have unblocked a real decision, you know who decides what, and stakeholders come to you directly. Part 6.
• Functional analyst. You can state the rules the system actually enforces, with evidence from code or data, and you have specified a change against them. Part 7.
• QA analyst. You can run, extend, and explain the regression suite, create valid test data on your own, and you have added tests that caught something. Part 8.
• Developer analyst. You can trace a transaction in code, logs, and data without help, and you have shipped a query or script the team reuses. Part 9.
• Systems analyst. You can draw the landscape from memory, predict which systems a change touches, and your map has been reviewed and adopted by the team. Part 10.

If you are in a complex domain, accept that full fluency takes longer than 90 days. ISO 20022 alone covers initiation, clearing, status, returns, recalls, investigations, and statements, and every market infrastructure and correspondent adds its own rules. The 90 day bar is not knowing everything; it is being trusted to own a bounded scope and knowing exactly where your gaps are.

What if the 90 day review does not go well?

Then the evidence still helps, because it turns a vague disappointment into specific gaps you can close.

If your manager’s view differs from your self-assessment, ask which area and what evidence they would need to see. “What would a 2 in systems look like to you, specifically?” converts a judgment into a target. Agree on one or two concrete outcomes for the next 30 days and book the follow up before you leave the room.

The most common cause of a weak 90 day review for analysts is not lack of ability. It is that the day 90 success statement was never agreed in week one, so you and your manager were measuring different things for three months. If that happened, agree it now, in writing, for the next 90 days. And if you want an outside view on the plan, a 1:1 coaching call is a working session on your own situation.

The takeaway

The 90 day review is where onboarding becomes visible. Score yourself from 0 to 3 in domain, systems, people, delivery, and tooling, with an artifact behind every score. Bring the week one success statement, the evidence, your two weakest areas with a plan, and one specific ask. Run a fifteen minute retrospective while you still remember being new, and turn three months of notes into an owned, dated onboarding guide that the next joiner updates at their own day 90. If you can explain the team, the system, and the domain clearly to someone new, you are onboarded.

That closes The First 90 Days. Start again from part 1 when you next change team, and if you want to keep building the skills you mapped, the roadmap and the career paths show where they lead. To practise the whole cycle on a system you have never seen, the Labs set every mission inside one fictional payments platform, with a contract, events, logs, and data to onboard into.

For the full library behind this series, the Complete Tech BA Bundle covers analysis, code, testing, and support in one purchase. If the gap your retrospective found is repetitive manual work, The BA Automation Guide shows how to automate it with n8n, Power Automate, and AI. For the onboarding guide itself, Confluence for Business Analysts covers the templates and review habits that keep it alive. The free downloads are a good starting point, and if you want help setting the next quarter’s 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, Performance Review, Documentation