12 November 20258 min read
The first three months decide most of what an engagement will be. Not because the work in that period is especially important, but because every habit that will govern the next two years gets set in it: how fast questions are answered, whether disagreement is safe, what done means, and whether anybody trusts anybody.
What follows is what a healthy engagement looks like at each stage, and the specific signals that mean something is wrong. It assumes the ordinary case: one or two people joining an existing team and system, working most of the same day as you, which is the shape of a near-shore engagement between Beirut and Western Europe.
Week one: access, a shipped change, a named person
The first week is administrative and should be treated that way. The goal is not output. It is that every obstacle which will otherwise appear in week three is discovered and cleared now, while nobody is depending on the work.
By Friday of week one, three things should be true. Every account exists and has been used at least once. One small change, chosen in advance, has gone through the entire pipeline to production, however trivial. And there is a named person on your side whose job it is to answer questions, who knows they have that job.
Worry if the first week is spent reading the codebase with no ticket attached, if any account is still missing on Friday, or if the honest answer to "who is their first point of contact" is a channel name rather than a person. Each of these is cheap to fix in week one and expensive in week six.
The rest of month one: calibration
Weeks two to four are about calibration rather than throughput, and it is worth saying that out loud to everyone, including whoever is watching the budget. What is being calibrated is the gap between what you ask for and what you get, and closing that gap is the actual work of the first month.
Expect a high volume of questions and treat that as the good outcome, not as a cost. Expect two or three items to come back not quite right, and treat each one as a diagnostic: was the ticket missing its reasoning, was an assumption never stated, or was the definition of done silent on something you consider obvious. Fix the cause rather than the item.
By the end of month one, you should be able to see the shape of things: small changes shipping regularly, review conversations that are about substance rather than formatting, and estimates that are sometimes wrong in both directions. Estimates that are only ever wrong in one direction are already telling you something.
Worry if questions have stopped, if nothing has reached production, or if every delivered item needed significant rework and nobody has identified a pattern in why.
Month two: independence
The second month is where a working engagement becomes visibly cheaper to run. The tickets get less detailed, because less needs saying. Questions become fewer and better: not "what should this do" but "this will break the reporting job, do we care". The person starts pushing back, which is the single most reliable positive signal available.
Two things should also start happening on their side. They should be finding problems you did not point them at, and they should be able to pick up an item without a conversation preceding it. If both are happening, the engagement is working and your management overhead should now be dropping rather than steady.
Worry if you are still writing tickets in the same detail as week two, if you are still reviewing every change personally because you do not trust the outcome otherwise, or if the work has quietly narrowed to a small safe corner of the system while the harder items keep being reassigned internally.
Month three: it should be boring
The target state at ninety days is that the engagement has become uninteresting. Work moves, review happens the same day, the weekly planning conversation takes twenty minutes, and nobody on your side is thinking about the arrangement between Mondays.
Concretely: they can take a medium-sized piece of work from a one paragraph description and come back with the right questions before they start. They know which parts of the system are dangerous. Somebody on your team has, at least once, asked them for an opinion rather than for an update. And you could describe what they are working on this week without opening the tracker.
Worry, seriously, if at ninety days you are still spending more management time per week than you were in month one. That is not a slow start, it is a structural mismatch, and it does not resolve itself with more time.
What to review at ninety days
Keep it to things you can actually answer. How long a blocking question takes to be answered, in both directions, and whether that number is going up. How much rework the last month contained, and whether the causes were requirements or execution. Whether the definition of done has needed changing, and what that revealed. Whether the same people are doing the work who were assessed during pre-vetting.
Ask the same questions of yourself, in front of them. Have your review queues been clearing within the day. Have priorities changed mid-week more than once. Was there an item where they asked something and waited more than a day. This is not a courtesy; it is the part of the review that produces the largest improvement, because client-side latency is the most common cause of a disappointing quarter and the easiest thing on the list to fix.
Scaling past the first person
If the ninety days went well, the instinct is to add three more people the following month. Resist the shape of that, not the intent. The first person absorbed an enormous amount of undocumented context by asking you directly, and that route does not scale: three new people asking the same questions of the same manager is how a working engagement becomes an overwhelmed one.
The pattern that works is to grow through the person who already knows. They onboard the next one, they hold the context, and your point of contact stays singular while the team behind it grows. That also gives you an honest test of how well the first ninety days went, because someone who cannot onboard a colleague did not understand the system as well as their delivery suggested.
Add people one at a time, with a few weeks between, and watch the same signals you watched in month one. If question-to-answer latency climbs each time you add someone, you have found your real capacity limit, and it is a limit on your side of the arrangement rather than theirs.