You are joining a business whose industry you have never worked in. How do you get up to speed in ninety days?

Trace one thing all the way through

The highest-yield activity in the first fortnight is to follow a single real unit of work from the moment it enters the business to the moment it is finished and paid for. In insurance that is one policy, from quote to claim to settlement. In logistics it is one consignment, from booking to proof of delivery to invoice. In banking it is one payment or one trade. Pick a specific instance with an identifier you can look up, and walk it through every system, every screen, every spreadsheet and every human handoff it touches.

Do this because it forces you into the parts of the business no diagram shows: the step where an operator retypes a reference number, the queue where things wait for someone in another country to wake up, the reconciliation that runs overnight and the report someone checks by eye every morning. It also gives you the spine on which everything you learn afterwards hangs. Vocabulary learned from a glossary sits in a list; vocabulary learned by watching a document change state as it moves attaches to something.

Read the operational artefacts, not the explanatory ones

Onboarding decks, product marketing and architecture diagrams describe the business as it wishes to be understood. They are worth an afternoon. The artefacts that actually teach the domain are the ones the business uses to run itself, and they are usually available for the asking.

The best single document is the training material used for new operations or support staff, because it teaches the domain the way practitioners think about it, in the order things happen, with the exceptions included. After that: the standard commercial contract and its service levels, which tell you what the business has promised and therefore what the software must guarantee; the pricing model or rate card, which encodes more business rules than any specification will; the exception and escalation runbooks; the support ticket taxonomy, which is a ranked list of what goes wrong in reality; the reconciliation and month-end reports, which reveal what the business does not trust; and past audit or regulatory findings, which point straight at the areas where the rules bite hardest.

On the technical side, the data dictionary and the twenty largest tables tell you what the business genuinely tracks, as opposed to what it says it tracks. A column that exists in every table, or a status field with fourteen values and three that are never used, is a piece of domain history someone can explain to you.

Talk to the people the org chart puts at the bottom

The instinct is to book time with the product owner, the lead architect and the domain expert everyone names. Do that, but do not stop there, because those people tend to describe the intended process. The people who know how the domain actually behaves are the ones absorbing its friction: the operations analyst who maintains a spreadsheet the official system cannot replace, the support agent who can recite the six reasons a customer calls, the finance person who chases the differences at month end, and the twenty-year veteran who knows why a rule that looks arbitrary exists.

The most productive question in all of these conversations is not "how does this work". It is "what happens when it goes wrong", followed by "how often". Exception paths are not edge cases in a business domain; they are frequently the majority of the work, and they are where the rules that matter live. A candidate whose ninety-day plan is entirely happy-path reading is describing how to acquire vocabulary, not understanding.

Two other questions earn their keep. "What is the most annoying part of your week?" surfaces the gap between the system and the domain. And "who decides?" maps the real authority structure, which in regulated industries is often not the one on the org chart.

The distinction that stops you doing damage

There is a specific failure available to a technically strong newcomer, and it is worth naming because it is the one that costs money. You learn how this company does the thing, you learn it well, and you cannot tell which parts are the industry and which parts are an accident. Some of what you are shown is a hard external constraint: a settlement window, a required document, a regulatory report, a market convention nobody can opt out of. Some of it is a workaround built in 2009 around a limitation that no longer exists, preserved because it became the process. They look identical from the inside, and both are defended with equal conviction.

Getting this wrong runs in both directions. Mistake a convention for an accident and you propose a redesign that is illegal or unsettleable, and you lose credibility that takes months to rebuild. Mistake an accident for a convention and you faithfully reimplement someone's 2009 workaround into the new platform, where it will outlive everybody. The way to tell them apart is to ask for the source: which rule, which contract, which regulator, which counterparty requires this. A constraint that is real has a document behind it and someone who can name it. A habit produces "that's just how we've always done it", and that answer is information, not an obstacle.

Fluency is not understanding

Vocabulary is acquired in weeks and is genuinely necessary — you cannot participate without it, and it is the gate stakeholders use to decide whether to explain things properly. But it is also easy to mistake for competence, in yourself as much as in others. The distinguishing tests are these.

Can you predict? Given a situation you have not been told about, can you say what the business will do, and are you right? This is the strongest test because it is falsifiable. Say your prediction out loud before someone tells you the answer, and keep score.

Can you say why the rule exists, not merely what it is? Someone fluent can tell you a claim must be reserved within a certain period. Someone who understands can tell you what the reserve is for, who relies on the number, and what goes wrong upstream if it is set too low.

Can you state what is not allowed, and what happens if it occurs anyway? Domains are defined by their prohibitions and by their remedies. Fluency covers the permitted path.

Can you rank? Fluency lists five things a customer might want. Understanding says which two matter, which one is negotiable and which one nobody has ever actually asked for.

Can you spot a wrong requirement? The moment you can read a ticket and say "this can't be right, because that would mean we'd be doing X", you have crossed over. Until then you are transcribing.

The practical way to force the transition is to write the domain down and expose it. Publish a glossary and a one-page description of the end-to-end flow as you understand it, put your name on it, and ask the experts to correct it. You will be wrong, publicly, which is uncomfortable and extremely efficient: it converts your unknown unknowns into corrections in an afternoon, and it gives the business something useful in exchange for the time it spent teaching you. Watch the shape of the corrections. Early on, people rewrite whole sections, which means your mental model is wrong at the structural level. When the corrections become "that's right, but this only applies above a certain threshold", you have the domain and are now refining it. That shift, not the passage of ninety days, is the milestone.