How an engagement works

1. Scoping the shape, not the headcount

Most bad engagements start with a headcount. The useful conversation is about the work: what is being built, what already exists, where the constraints are, and which decisions are still open. The team shape falls out of that.

This usually takes a week or two of real conversation. It is worth more than a fast start, because a team assembled around the wrong roles is expensive in a way that is hard to unwind.

2. Ramp-up with overlap

Engineers join with a deliberate overlap period where they are reading, asking and pairing rather than shipping. Teams that skip this look faster for three weeks and slower for six months.

By the end of ramp-up an engineer should be able to describe the system's failure modes, not just its features.

3. You direct the work

The team works to your backlog and your process. We are responsible for the people — hiring, retention, cover during leave, the working environment, and replacing anyone who is not right for the role.

That division matters. Providers who insist on managing the work as well as the people tend to optimise for utilisation rather than for your outcome.

4. Governance you can actually see

• Code in your repositories, under your review rules, from day one
• Infrastructure defined as code so environments are reproducible without us
• Documentation written as work happens, not assembled at handover
• A named point of escalation on our side who is not the person doing the work

5. Ending well

An engagement should be endable. That means no undocumented deployment steps, no credentials that live only in someone's head, and no architectural decisions that only make sense if we are still here.

We would rather be re-engaged because the work was good than retained because leaving is painful.