Building a Consulting Framework: What I Learned From Getting It Wrong

I spent the weekend writing down everything I wish I’d known before starting consulting work. Not the technical stuff, that’s the easy part. The other stuff: how to scope work properly, when to say no, how to hand things over without creating dependency.

Twenty years of platform engineering, and I’m only just now documenting a proper framework. Better late than never, I suppose.

Why Bother With Frameworks

I founded my first company in 2003, straight out of university during the web development boom. Flash websites, early web tech, all that. One thing I learned quickly: every time you reinvent the wheel for a new client, you’re burning time and money.

Templates and frameworks aren’t about being rigid or uncreative. They’re about not wasting time on things you’ve already figured out. Client onboarding checklist? Wrote it once, used it fifty times, refined it each time. Project kickoff questions? Same thing. Pricing structure? Took me three painful negotiations to figure out what worked, then I just reused it.

The creative work, the problem solving, the interesting engineering, that’s where you want to spend your energy. Not recreating proposal documents or remembering what questions to ask in discovery. Write it down once, use it forever, improve it as you go.

Twenty years later, I’m finally applying that same lesson to platform engineering consulting.

The Uncomfortable Bits

Here’s what I’ve learned, mostly through mistakes:

I used to think being helpful meant saying yes to everything. “Whilst you’re here, could you also look at…” became the most expensive phrase in my vocabulary. Scope creep isn’t something that happens to you, it’s something you allow by not having clear boundaries.

I’ve built brilliant technical solutions that nobody wanted. Well, engineering wanted them. But finance saw expensive over-engineering, and leadership wondered why we were six weeks behind schedule. Turns out “success” means different things to different people, and if you don’t align on that upfront, you’re in for a rough time.

The worst feeling is leaving a client and realising you’ve made them dependent on you. They can’t change anything without calling you back. You’ve solved their problems but you haven’t built their capability. That’s not consulting, that’s just creating recurring revenue for yourself whilst handicapping their team.

And “just trust me” stops working the moment something goes wrong or takes longer than expected. People need to understand the why, not just accept the what.

What the Framework Actually Is

After enough of these painful lessons, I started writing things down. What worked, what didn’t, what I’d do differently next time. Eventually it turned into a proper framework document.

Back in 2003 when I was building websites, I learned that having templates for common patterns saved enormous amounts of time. Same principle here. Why recreate discovery processes, pricing models, or handover checklists for each engagement when you can document what works and refine it?

It’s not revolutionary. It’s just systematic thinking about four areas where I’ve repeatedly seen things go wrong:

Platform engineering work needs clear phases. Assessment, design, implementation, optimisation. Obvious when you write it down, but easy to blur together when you’re in the middle of it. Each phase needs different conversations with different people about different outcomes.

Security and Zero Trust can’t be an afterthought. I learned this serving as Data Protection Officer whilst trying to get actual engineering work done. Security needs its own workstream, its own stakeholder management, its own acceptance criteria. Otherwise it becomes “we’ll harden it later” which means never.

Cost optimisation is easier when you frame it properly from the start. In my last role I found £120K+ in annual savings, but it took months of digging through usage patterns and convincing people that yes, we really are paying for that unused NAT gateway. The framework includes discovery processes that find this stuff early.

CI/CD and developer experience is where platform engineering either succeeds or fails. You can build the most elegant infrastructure in the world, but if developers hate using it, you’ve failed. The framework forces me to think about their experience from day one.

Nothing groundbreaking. Just structure around common failure modes.

How I Actually Work

The framework defines three ways to engage, which sounds formal but really it’s just being honest about what works:

Embedded work over a few months is what I prefer. You’re part of the team, you understand the context, you can transfer knowledge naturally because you’re working alongside people. Migrations, modernisation programmes, that sort of thing. It’s harder to build dependency when people are watching you work and learning as you go.

Monthly advisory is for teams who need perspective but not hands-on-keyboard help. Architecture reviews, strategic decisions, “should we really bet on this technology” conversations. Lower commitment, but you need to be comfortable with less control over outcomes.

Fixed scope projects are fine when the boundaries are genuinely clear. Specific migrations, compliance implementations, that kind of thing. The framework helps me decide if something actually has clear boundaries or if I’m kidding myself.

Two-Week Cycles

The framework uses two-week sprints because I’ve never seen waterfall succeed in infrastructure work. You need to show progress regularly, get feedback, adjust course. Not because it’s fashionable, because it’s the only way I’ve found that actually works.

Discovery takes weeks, not months. Planning is collaborative. Execution is iterative. Handover includes documentation and training because transitions matter. None of this is novel, but it’s easy to skip when you’re busy.

What Actually Matters

I care about measuring things that matter to the business:

How often can you deploy without drama?
How long does it take to get code from commit to production?
When something breaks, how quickly can you recover?
What’s your infrastructure actually costing, and is that trending up or down?
Can your team handle this without calling me in six months?

Not story points. Not velocity metrics that mean nothing outside the team. Not how many meetings we had or how many Jira tickets got closed.

The last one is important. If I’ve done my job properly, you shouldn’t need me anymore. That’s the measure of success, not whether I’ve made myself indispensable.

Tools Change, Problems Don’t

I use Claude Code and similar tools. Not because it’s trendy, because they make me faster at the boring bits. Log analysis, documentation, boilerplate infrastructure code. This frees up time for the interesting problems that actually need human judgement.

Some people get weird about this. Either they think AI is going to replace all engineering (it won’t), or they think using AI tools is somehow cheating (it isn’t). Platform engineering has always been about using the best available tools. Twenty years ago that was Perl scripts and SSH keys. Now it includes LLMs. The problems haven’t changed that much, just the tools.

The framework acknowledges this reality. I’m not going to pretend I write every line of Terraform by hand when I can generate working configurations and then review and customise them. That’s not the valuable part anyway. The valuable part is knowing what to build, why, and how it fits together.

Who This Works For (And Who It Doesn’t)

The framework has helped me think about fit. Some engagements work well, others are painful for everyone involved.

Works well with tech companies or tech-enabled businesses, typically 20-500 people, who already have engineering teams and are trying to do cloud-native properly. They’ve usually got budget for this (£50K+ range) because they’ve already tried the cheap options and learned why they’re cheap.

More importantly, it’s about mindset. Teams who want to learn, not just outsource problems. Leadership who understand that good infrastructure is an investment. People who value working solutions over perfect architectures.

Doesn’t work well when there’s an expectation of magic. Or when cost-cutting is the only priority regardless of quality. Or when teams are so siloed that nobody can agree on what success looks like. Or when decision-making takes weeks and you’re expected to just wait around.

The framework helps me recognise these patterns earlier and either address them upfront or politely decline the work. Saying no is a skill I’m still learning.

It’s Not Finished

This is version 1.0, which means it’s the first time I’ve written it all down properly. It’ll change based on what I learn from actual engagements. Quarterly reviews, retrospectives, the usual continuous improvement stuff.

The technology parts will definitely evolve. Kubernetes patterns change, AWS launches new services, best practices shift. But the core problems around scope management, stakeholder alignment, and knowledge transfer? Those stay pretty constant.

Why Put This Online

Honestly, I’m not sure if publishing your consulting framework is smart or stupid. Three reasons I’m doing it anyway:

First, transparency. If someone’s considering working with me, they should know how I work. No surprises.

Second, it helps both of us figure out fit faster. If this approach resonates, great. If someone reads this and thinks “that’s way too structured” or “that’s not nearly rigorous enough”, also great. Better to know now.

Third, I’ve learned everything I know from other people sharing their experiences. Blog posts, conference talks, open source projects, random conversations. Seems only fair to contribute back.

If you’re doing similar work and want to share what you’ve learned, I’m interested. What works for you? What have I missed? What seems like unnecessary overhead?

What Happens Next

I’m working with a few clients now on platform engineering work. Each engagement teaches me something about what works and what needs adjusting in the framework.

If you’re dealing with infrastructure costs that don’t make sense, deployments that take forever, or platform engineering capability gaps, we might have interesting problems to work on together. But equally, if you just want to talk about these challenges, that’s fine too. Some of the most useful conversations I’ve had were with people I never ended up working with.

The complete framework document is available if you want more detail on the actual structure. But honestly, the interesting bit isn’t the framework itself, it’s the problems it’s trying to solve.

What are you currently wrestling with in platform engineering? Not the technology specifics, but the organisational challenges, the alignment problems, the things that make infrastructure work harder than it should be?

You can find the complete framework document at https://docs.google.com/document/d/1x1uC2Yt5W1hsfCvPWrJevCHtAfRLs1pim9NuzhOjVjs/edit?usp=sharing , or just reach out directly if you want to talk through specific challenges.