13 years of DevOps consulting: eight lessons

#Sell outcomes, not hours.

This is the lesson with the biggest delta in my career. For my first seven years I sold time — €X per hour, multiply by hours, send invoice. It capped my income at the number of conscious hours in a week and forced me to optimise for visible activity instead of actual results.

The switch was simple in retrospect: "€X to migrate this cluster off CentOS" instead of "€X/h, estimated 60 hours." Same work. Same risk for me. Three times the perceived value to the client because they were buying a deliverable, not someone's calendar.

The shift took six months to be comfortable with. Three things made it easier:

• I started writing fixed-scope statements of work with a clear "you get / you don't get" list. Nothing vague.
• I added a change-order clause: anything outside the scope is a new line item, quoted before work starts. Removes the resentment that kills projects.
• I priced for the outcome's value to them, not my hours. A 4-day cluster migration that prevents one hour of outage on Black Friday is worth more than 4 days of my time. Charge for the prevention, not the work.

"You're not buying hours. You're buying the fact that I've done this thirty times and know which three things will break."

#The first two weeks decide everything.

Every engagement that went badly was visibly going badly by day 10. I just refused to call it.

What "going badly" looks like: the brief keeps mutating; the technical contact is two layers below the decision-maker; another consultant is being onboarded in parallel "just to compare"; the Slack channel for the project has fewer than three of their people in it. Any one of these is a signal. Two is a verdict.

The expensive thing is not exiting at week two. It's six months in, when you've shipped half a runbook nobody reads and you have to explain to your spouse why this month is leaner than the last.

My current rule: week 2 sit-down with the decision-maker, not the technical contact, not the project manager. Either the project is real to them and we go, or it isn't and I exit gracefully with a written "here's what's blocking you from moving forward" deliverable. The client always pays for that. They almost never feel bad about it.

#Charge for thinking, not just doing.

The most lucrative work I've ever done was a one-page architecture review that took 90 minutes of writing and saved a startup roughly €40,000 in deferred AWS commitments. The invoice was €4,000. They were thrilled.

The opposite — the lowest-value work — has always been "implementation under direct supervision." Show up, do the keystrokes, leave. The market for that is infinite and brutal.

When I quote a project now, the line item is "architecture, decisions, and ownership". The keystrokes are downstream. If the client wants to do the keystrokes themselves with my plan, the price is the same. You're paying for the plan, not the typist.

#Write the runbook before the deploy.

Every engagement now ships with a runbook before it ships code. The runbook is the deliverable. The infrastructure is the implementation detail.

Why this works:

• The runbook is what survives the engagement. Code rots; markdown is forever.
• Writing the runbook first forces the design to be operable. If you can't explain how something fails in writing, you don't understand it.
• The runbook is the artefact the client shows their CTO when justifying the spend. Make it good.

My current runbooks have five sections: what this thing does, how to deploy it, how it fails (top 5), how to fix each failure, and what to do when you're paged at 3 AM and the doc lies to you. That last section is the most important.

#Saying no is the highest-leverage move.

The single best investment I made in my career was developing the muscle to say no to bad work.

Bad work, in approximately the order I learned to filter it out:

1. Clients who haggle on the first call. They will haggle on every invoice forever.
2. Projects where the technical lead is also the founder, also the CFO, also chronically unavailable.
3. "We need someone to fight with our current vendor." You're being hired as a hammer, not a builder.
4. Anything where the scope is "make our cloud bill smaller" with no further context. Means there's a political fight you're being invited into.
5. Replacements for the last consultant who was just here. Sometimes legitimate. Mostly: the client is the problem.

The hard part is that no always feels expensive in the moment. I have left, conservatively, six figures of bad work on the table. The thing those six figures bought me is the bandwidth to do the work I'm here doing now — including writing this post.

#The goal of every engagement is to hire your replacement.

This is counterintuitive only the first time you hear it. The good consultants — the ones who get referred and re-hired — make their clients self-sufficient. The mediocre ones make their clients dependent.

The dependency model has short-term cash but a brutal ceiling. Every retainer you sign on it is one slow exit conversation in a year, often initiated by the client's CFO. You will burn that bridge.

The replacement-hire model means you teach the senior engineer who's actually going to live with this system after you leave. You pair-program. You write docs together. You sit on the post-launch retro. They don't need you in six months — and they recommend you to two new clients next year because they're now the hero internally.

I have made more money on referrals than I ever made on retainers. Trust is the asset, not access.

#The pre-mortem call is worth ten times its time.

Borrowed from Gary Klein's research and used everywhere from the US Army to NASA: before any non-trivial deployment, run a 30-minute meeting where the question is "This deploy has failed catastrophically. We're 24 hours past the planned rollout. What happened?"

It's a hypothetical post-mortem. Everyone speaks. You write down every failure mode. You then go fix the top three before the actual deploy.

Three reasons this is the most undervalued meeting in consulting:

• It makes junior engineers contribute. They know what's fragile; they're just rarely asked.
• It surfaces political risks (the "we forgot to tell legal" or "the marketing launch is the same day" kind) that pure-technical reviews miss.
• It is a billable hour that prevents 40 unbillable ones.

I never skip it now, even when the client says they're fine without it. Especially then.

#Renew on outcomes, not anniversaries.

Most consulting relationships I've seen end badly do so because they were on autopilot. A retainer hits its 12-month mark, the client doesn't really need monthly hours but doesn't want the friction of cancelling, and one day the new CTO comes in and the line item gets cut overnight.

Instead: structure the relationship around concrete next outcomes. We just shipped the AI inference fallback chain. The next outcome is "instrument the cost-per-user across the LLM provider stack." When that's done, we agree on the next thing or we wrap up cleanly.

This means I can quote fairly, the client can budget fairly, and the relationship has natural off-ramps that don't feel like rejection. Some of my best clients went away for a year and came back. That doesn't happen if you exit by being fired during a Q4 cost review.