Career & Jobs
What Should Your First 90 Days Look Like on an AI-Heavy Team?
By Jim Vernon, Editor, AI Intelligence International · Published 26 August 2026 · Reviewed against our editorial standards · About the author
Teams that lean heavily on AI tooling onboard people badly, for a specific reason: the tooling makes new joiners look productive in week one, which hides the fact that they have not yet learned what the team actually knows.
This is a 90-day plan built around that trap — how to convert early apparent output into real context, and which questions to ask before the window for asking them closes.
Key takeaways
- Early output on an AI-heavy team is not evidence of understanding, and treating it as such stalls you at month four.
- Spend the first month learning what the team verifies rather than what it generates.
- Find the undocumented constraints; they are the only thing the tooling cannot tell you.
- By day 90 aim to own one workflow end to end, including its failure handling.
Why is onboarding harder when the team runs on AI tooling?
You can produce a plausible deliverable on day three without knowing why the team does anything the way it does. That feels good and it removes the pressure that would normally push you to ask basic questions.
Three months later the gap surfaces, usually as a decision you got wrong for a reason everyone else considered obvious. By then you have used up the social permission new joiners get for asking naive questions.
The fix is to deliberately front-load context acquisition during the period when apparent productivity is easiest.
What should the first thirty days actually cover?
Learn the verification layer before the generation layer. Every functioning AI-heavy team has a set of checks — review conventions, a test suite, a reconciliation, an approval — and those checks encode what the team has learned the hard way.
Ask to be put on review duty early, even if you are slower at it. Reading other people's work with the team's checks in hand teaches you the standards faster than producing your own work does.
Write down every rule you encounter that is not in the documentation. That list is your real onboarding artefact.
Which questions get harder to ask after month one?
Why does this exist, who is the customer, what did we try before, and what are we not allowed to do. All four are cheap in week two and expensive in week ten.
Ask them of at least three people. The variance in answers tells you where the team lacks a shared model, and those gaps are usually where the recurring problems live.
Record the answers verbatim somewhere you will reread. Paraphrasing them into your own words too early loses the specificity that makes them useful later.
How do you avoid inheriting the team's bad habits?
New joiners are the only people who can still see which practices are unjustified. Keep a private list of things that seem wrong, and do not raise any of them for sixty days.
At day sixty, review the list. Most items will have explanations you have since learned. The two or three that do not are worth raising, and by then you have the standing to raise them.
Raising them in week two costs you credibility and usually surfaces a reason you had not seen. Raising them at day sixty with evidence is how new hires make their first real contribution.
What does days 31 to 60 look like?
Shift from reviewing to producing, but on work that has a clear owner other than you. The goal is to get your output checked by someone who knows what good looks like, as often as possible.
Track the corrections you receive by category. If the same category recurs three times, that is a gap in your model of the domain, not carelessness.
Start shadowing the on-call, escalation or exception path. How a team handles things going wrong tells you more about it than how it handles the normal case.
What should you own by day 90?
One workflow end to end, including what happens when it fails. Ownership of a happy path is not ownership; the failure handling is where the knowledge is.
Aim for something small and real rather than a share of something large. A weekly process you fully control is a better ninety-day outcome than a supporting role on a flagship project.
Write the runbook for it. That both proves the ownership and makes you the person who is asked about the next one.
Worked example: a 90-day plan that worked
A data analyst joined a nine-person operations team where most reporting was generated and then checked by hand. In week one he was asked to produce a churn breakdown and had a draft the same afternoon.
Instead of shipping it, he asked to sit with the person who normally checked it. That session surfaced four conventions not written anywhere, including a customer segment that had to be excluded for contractual reasons. His draft had included it.
Weeks two to five he reviewed rather than produced, and accumulated an eleven-item list of undocumented rules. Weeks six to nine he produced under review; the correction log showed a repeated misunderstanding of how refunds were dated, which he fixed by reading the finance close process.
At day sixty he raised three of his eleven items. Two had good reasons. The third — a manual exclusion applied inconsistently — became a documented rule. By day ninety he owned the weekly churn pack including its exception path, and the runbook he wrote was used to onboard the next hire in half the time.
Frequently asked questions
Should I use the team's AI tooling from day one?
Yes, but treat everything it produces as a draft you must be able to defend. The risk is not using it; the risk is shipping output whose assumptions you have not checked against the team's conventions.
What if the team has no verification layer at all?
That is important information about the team. Build a small one for your own work — a checklist of what you confirm before shipping — and expect quality issues to be a recurring theme in that role.
Is ninety days a realistic timeline for owning something?
For a small workflow, yes, on most teams. If you are still without clear ownership at month four, that usually reflects unclear scoping rather than your pace, and it is worth raising directly with your manager.
How do I know if I am actually behind?
Track whether the corrections you receive are getting more specific over time. Moving from structural corrections to detail-level ones is progress. Receiving the same structural correction in month three is the signal to slow down and rebuild context.