How I Work
Find the Friction.
Five steps from observable symptoms to embedded operational improvements. The same method, adapted to every business.
The operator principle
I work inside the business, not at it from the outside. The difference is not where the desk is. It is whether the person doing the work is close enough to see the real constraints and accountable enough to stay until they are addressed.
Most operational work fails not because the diagnosis was wrong but because the implementation is left to people who were not in the room when the approach was designed, who have fifteen other priorities, and who have no particular authority to require the change. The value of embedded operating work is presence, context and accountability—until the change is real.
The method, step by step
Observe what really happens.
Most operating problems look different from inside the daily work than they do from a leadership meeting or a process document. I spend time with the people actually doing the work: watching, listening, asking why. The gap between what the process says and what people actually do is usually where the friction lives.
Identify constraints, repeated failure points and founder dependencies.
Not every problem is worth fixing. The friction that matters is the kind that recurs, that creates downstream consequences, that routes work back through the founder unnecessarily, or that prevents the business from operating at the capability it already has. I look for structural causes rather than proximate ones.
Prioritise the smallest set of changes that creates meaningful leverage.
The most important constraint on operating improvement is organisational load. Making too many changes simultaneously prevents any of them from sticking. I prioritise by leverage: which changes unblock the most downstream work? Which can be implemented with the resources and attention available? Which must go first because nothing else works without them?
Redesign the workflow, responsibilities and supporting technology.
People, process and technology are one system. Redesigning a workflow without clarifying ownership produces compliance problems. Introducing a tool without changing the process produces a tool nobody uses. I design across all three: who does what, how information moves, what the system records, who owns it, and what happens when it breaks.
Implement with the team, measure adoption and leave clear ownership behind.
The implementation phase is where most operational work fails. A system that is designed but not embedded is a nice diagram on a shelf. I work with the team through the transition: communicating the change clearly, supporting adoption, measuring what actually changes in behaviour (not just what the tool records), and naming who owns it after I am gone.
People, process and technology are one system.
Treating them as three separate workstreams is how operational improvements fail.
People
A new process without clear ownership produces compliance problems. A new tool without training produces a tool nobody uses. People are not the implementation risk—they are the implementation.
Process
Process design must reflect what the work actually requires, not what a process map says it should require. The best process is the lightest one that reliably works. Complexity that does not serve the work becomes work itself.
Technology
A tool cannot repair an unclear decision. Technology should serve the operating system, not become another system to manage. I choose buy, configure, integrate, automate or build based on what the problem actually needs.
Working in the business
without taking it hostage.
Embedded operating work carries a risk: the business becomes dependent on the person doing it, and the underlying capability does not develop in the team. This is the exact failure mode I am designed to avoid.
The handover is part of the design from the start. Every system is built with a named internal owner. Every process change includes the explanation of why it works, not just what to do. Every tool is configured for someone in the team to maintain, not for someone outside it.
The test of the engagement is not whether the work was done well. It is whether the business operates better after I leave.
Confidentiality and data handling
Access to the real work means access to sensitive information: commercial strategy, HR situations, client relationships, financial data, and system details that matter. I treat everything I encounter with the confidentiality that the business expects of a senior employee—because that is effectively what the engagement creates.
Where it is appropriate and requested, I am happy to formalise this through a mutual non-disclosure agreement before work begins. I do not share client information across engagements or include identifiable client detail in public content without explicit permission.
I use only the tools and systems required for the engagement scope, and I do not store business data beyond the need of the engagement.
What I believe about the work
- The work is about the business, not about the process of doing consulting.
- Clear ownership beats more meetings and more process.
- The best process is the lightest one that reliably works.
- Technology should serve the operation, not become another operation to manage.
- Change introduced with the team sticks better than change imposed on them.
- Automation should remove repetitive work without removing judgement, care or accountability.
- The operator should leave capability behind, not dependence.
Start with the mess.
We will find the friction together.
Tell me what is happening. We can work out whether it is something I can help with and what the right starting point is.