About
I diagnose. I don't implement.
Most people who get called into a broken business are there to build something. That's the problem — the last three things you built are why you're calling.
What I actually do
I work in revenue operations — systems integration and subscription management, mostly for SaaS and professional services firms. The job looks like tooling from the outside. It isn't. It's variety management: deciding what complexity a business should absorb, what it should refuse, and whether the answer is new tooling or a redrawn boundary.
That distinction is the whole reason this site exists. A firm that can't quote consistently doesn't have a CPQ problem. A firm whose reports nobody trusts doesn't have a dashboard problem. Those are symptoms of a structure that produces them reliably, and replacing the tool leaves the structure intact — which is why the new tool breaks in the same place the old one did.
Why a second opinion, and not a project
The highest-leverage move in operations is usually to move a team boundary, and that's almost never available to the person brought in to fix the process. I do a lot of my work as an external designer — hired to fix the system, not to redraw the org.
So the honest deliverable is a written diagnosis: here's what's actually breaking, here's the constraint you can't remove, here's what it costs you a year, and here's the best system available inside it. Naming a constraint you can't remove isn't failure. Pretending you can automate around it is.
Where the framework comes from
Four systems laws do most of the work: Ashby's Law of Requisite Variety, Conway's Law, Brooks's Law, and the Reverse Conway Maneuver — with Beer's Viable System Model behind them. I've written the whole thing up as a standing reference rather than re-explaining it per engagement.
Getting in touch
Nothing is bookable yet. I'm writing the first diagnoses now — if you want the sample when it's finished, the waitlist is on the homepage. Otherwise:jon@thejonmartin.com.