THE ENGAGEMENT
Assess, scope, deliver, hand over.
Deliberately unexciting. The value is in doing it in this order, and most of the projects we are called in to rescue skipped the first stage.
The four stages
- 01
Assess
A short, paid piece of work that establishes what is actually happening, before anybody commits to a plan.
- 02
Scope
The smallest change that solves the real problem, written down with what it costs and what it does not include.
- 03
Deliver
Built in increments you can see, alongside your engineers rather than in a room they have no access to.
- 04
Hand over
Documentation, a walkthrough, and a team that can run it without us. We would rather be re-hired than depended on.
Assess
A short, paid piece of work — usually two to four weeks — that establishes what is actually happening before anybody commits to a plan. Cost attribution, traces, dependency mapping, a read of the code that changes most. It ends in a written document, and you own it whether or not you hire us for what it recommends.
WHAT YOU COME AWAY WITH
- What is actually causing the problem, with evidence
- A ranked list of fixes, effort against impact
- An honest view on which ones are not worth doing
Scope
The smallest change that solves the real problem, written down with what it costs, how long it takes and what it explicitly does not include. Scope is where projects are won or lost, so it gets more attention here than the build usually does.
WHAT YOU COME AWAY WITH
- A first phase with a price and an end date
- What is deliberately out of scope
- What we would need from your team, and when
Deliver
Built in increments you can see and use, in your repository, reviewed by your engineers. Each slice stands on its own and each one can be reversed, which is what keeps a bad week from turning into a bad quarter.
WHAT YOU COME AWAY WITH
- Working increments every week or two
- Changes your own engineers have reviewed
- A rollback for each step that has actually been tested
Hand over
Documentation that matches what was built, a walkthrough with the people who will carry the pager, and your team making a change unaided before we leave. Handover is in the scope rather than a courtesy at the end.
WHAT YOU COME AWAY WITH
- Runbooks and architecture notes that are current
- Your team shipping a change without us
- A clear answer on what, if anything, comes next
WHY IT IS SHAPED THIS WAY
Measurement is what turns opinion into a plan.
The same set of complaints, measured and ranked, becomes a sequence somebody can start on Monday. That is nearly the whole method.
ENGAGEMENT CANVAS
What it looks like on a real problem.
An illustrative engagement, worked through to the point where there is something to do on Monday.
ILLUSTRATIVE SCENARIO
Getting a nine-year-old monolith onto managed infrastructure
An illustrative engagement, not a client case study. Real ones diverge by the second week.
- 1
Find out what the system actually does
COVEREDIncluding the three cron jobs nobody has owned since the person who wrote them left.
- 2
Measure where cost and latency really go
COVEREDIt is rarely the part everyone complains about. Usually it is one query and one oversized instance.
- 3
Decide what moves, what gets rewritten, what dies
YOU ARE HEREMost of it moves as-is. Rewriting during a migration is how migrations fail.
- 4
Move the least risky service first
Proves the pipeline, the monitoring and the rollback while the stakes are still low.
- EITHERLift and shift first, optimise after
- EITHERRe-platform the service while it moves
- 5
Migrate the rest in slices
Each slice reversible on its own, so a bad week never becomes a bad quarter.
- 6
Hand over the runbook and the on-call
The engagement ends when your team can do the next one without us.
You do not have to figure it all out today.
Start with where you are. Explore what is possible. Choose one step you can take next.