How we work
Read first, then measure, then change
Every engagement follows the same five stages. The order is the point.
- 01
Read what exists
The first week is reading: repositories, pipeline definitions, dashboards, incident history, and the runbook nobody has updated. No recommendations yet. Most bad consulting advice comes from proposing a target state before understanding why the current one looks the way it does — the odd decisions usually had a reason.
- 02
Measure
Build duration by stage across a real sample of runs. Alert volume against alerts acted on. Spend attributed by service. Deployment frequency and the time from merge to production. Numbers change conversations that opinions cannot.
- 03
Agree the order
A written change list ranked by benefit against effort, separated into what can ship this week and what needs an architecture decision. You decide the order. Anything we advise against doing is listed too, with the reason.
- 04
Build alongside your team
Implementation happens in pairs with your engineers wherever possible. This is slower in week one and considerably faster by month three, because the knowledge stays in the building. A pipeline only your consultant understands is a liability you paid for.
- 05
Hand over
Written decisions including the rejected alternatives, runbooks for anything with an operational burden, and a working session rather than a slide deck. Then we leave. Retainers are available where they make sense, but the default assumption is that you should not need one.
Terms
How engagements are priced
Fixed scope
Most engagements are a defined scope over a defined number of weeks, priced up front. You know the number before we start.
Part-time by default
Two to three days a week works better than full-time for this kind of work. Your team needs room to absorb changes between them.
No percentage of savings
On cost work in particular, that model rewards deferring structural fixes. The incentive should not sit against your interest.