What I do in the first 90 days of an engagement

The fastest way to lose a client is to spend three weeks writing a strategy deck. The fastest way to keep one is to ship something they can feel by Friday. Here is how I structure the opening of a new engagement so momentum arrives early and stays.

Weeks 1–2: earn context, not opinions

I read the code, the incidents, and the calendar — in that order. The incidents tell me where the pain actually is; the calendar tells me how the team really works. I hold my architectural opinions loosely on purpose. Most systems that look wrong from the outside are a rational response to a constraint I cannot see yet.

The one thing I insist on early is access: repo, staging, logs, and a way to deploy. If I cannot get to production safely, I cannot help you safely.

Weeks 3–6: ship one real thing

Before I propose anything big, I close one meaningful, visible piece of work end to end. A latency fix with a graph that moved. A flaky deploy made boring. Something the team has wanted and not had time for.

This does two things:

• It proves I can operate inside your system, not just talk about systems in general.
• It gives us a shared, concrete reference for every conversation that follows.

Trust is not granted by a title. It is repaid, in small increments, by work that lands.

Weeks 7–12: make myself replaceable

The goal of good consulting is to leave the team stronger than a full-time hire would have. So the back half is about transfer, not heroics:

1. Write the runbook for the thing I just fixed.
2. Pair, so at least two people can maintain it without me.
3. Leave a short, honest map of what I would do next — and what I would not.

If I have done my job, the team does not need me by the end. That is the point, and it is also why they call me for the next one.