Operational design
For leaders and founders: when things aren’t working and it’s hard to see why, or when you know where you’re going but not where to start.
Two situations
It isn’t working, and I can’t see why
Something is clearly wrong, and there are a dozen explanations for it. You can see the problem, but not the full picture around it, so every fix lands on a symptom and the thing underneath keeps producing more.
I have plans, but I don’t know where to start
You know where you want the company or the team to go. What’s missing is the order: what has to exist first, who owns what, and how the work will actually get done. Sometimes it’s simply knowing you’re a little out of your depth and need help realigning and planning the near future.
How I work
- 01Diagnose. I start with root cause. The first week is spent looking at the whole thing from a high level, to understand how it actually works and where the friction could be.
- 02Map. That usually points in a direction. I drill down wherever it leads: into a process, a system, a handoff, or a conversation nobody is having.
- 03Prioritize. What has to change first, what can wait, and who needs to own each part of it.
- 04Act. I’m a builder, so this can mean doing the work alongside your team, or handing over a plan clean enough that it runs without me.
The problem people bring me is rarely the one causing it. Most problems surface at the top of a company; the causes usually live underneath.
What you walk away with
- A current-state map. How the work actually moves through the company today, as opposed to how it’s meant to.
- Root-cause findings. Where the friction really is, and what’s causing it, rather than the symptom you came in with.
- An ownership map. Who owns each piece, including the handoffs that currently belong to nobody.
- A prioritized change sequence. What to change first, and in what order.
- A near-term plan. For the immediate and near future, written so it works without me standing next to it.
Who it’s for
- A startup CTO. Often a strong technologist whose view of the company ends where the tech does, when a company needs the whole spectrum to run.
- A head of product. Shipping a product customers can buy is one thing; making sure the company can actually support what it sells is another, and it’s easy to miss.
- A founder. You have a product or a service and the connections to make it happen, but not yet the company structure that makes everything run smoothly.
It suits companies between a five-person startup and a fifty-person company growing faster than its processes. If you’re earlier than that and trying to learn how this works, start with the writing.
What it looks like in practice
Client onboarding, rebuilt
At an MSP, onboarding ran on tribal knowledge. I helped build the Projects team that made it a repeatable system, and onboarding timelines came down by more than 25%.
Read the case studyThe thinking behind that project is in The first thing I fixed in client onboarding. More, including the payments work, is on the work page.
The thinking behind it
I’ve been every person in the room: user, builder, engineer, and executive. The Foundation Layer is what that taught me, and it’s how I work out which layer of a company is actually failing before anyone designs a fix. Read the Foundation Layer, or what each seat taught me.
Start a conversation
Tell me what’s going on, even if it’s messy. I’ll tell you whether it’s something I can help with.
Hiring for this kind of role instead? Here’s my experience.