For most of my career, I spent ten months a year on the road.
Different industries. Different stages. Different problems. The companies were never the same. The work always was. Walk in, see what was actually happening underneath what the leadership said was happening, build what was missing, transfer it to the people who would run it after I left, exit. Some companies returned victorious. Some didn't. The ones that did had something in common, and so did the ones that didn't.
That long arc — twenty-plus years of it — is what I bring into a room now. Not a methodology I learned in a course. Not a framework I read in a book. Pattern recognition earned the way it has to be earned: by walking into companies that were already broken, watching what worked and what didn't, and being honest with myself about which of those outcomes I owned.
What I learned across all of it is simple enough to say in one sentence. Revenue problems are structural, not personal. The reps aren't broken. The founder isn't broken. The engine is broken — and the engine can be architected. Most of what looks like a sales problem at $1.5M is actually a structural problem the founder hasn't yet seen, because they're inside it.
That's the work. Architecting what's missing, transferring it to the people who'll operate it, then leaving.
I am a people person first, an architect second. The architecture exists to unlock the team that's already there.
This is the part of my work that doesn't fit cleanly on a services page, so I'll put it here.
Years ago, I led the relocation of a nonprofit's call center under conditions that could fairly be called impossible — 2.5 months, no budget, a team that previous leadership had decided were the problem. The team wasn't the problem. They had been treated as the problem long enough that some of them had started to believe it. The work wasn't operational. It was about restructuring the environment so that the people I'd inherited could become the people they were already capable of being. By the end, the call center was running better than it ever had, the team was engaged in ways no one had seen before, and the operational metrics were almost beside the point.
That's one of my favorite success stories from my career, and it had nothing to do with revenue.
I tell it because everything I do for B2B SaaS founders comes from the same place. The teams you've hired are usually more capable than the engine around them is letting them prove. Most of what's called "underperformance" is people operating inside structures that weren't built to support them. Fix the structure, and the people you already have become the people you needed all along. Hire only when development genuinely won't get you there.
This is also why I take only two clients at a time. Understanding a hero — really understanding who they are, and who they are not — requires depth that volume can't support. Two-clients-max isn't capacity management. It's the conviction that I am only victorious when the Hero is victorious, and that kind of victory requires presence I can't fake at scale.
Two engagements I think about often.
There are two engagements in my career that I think about often, because they show what's possible when the conditions are right.
The first was a Capital Markets technology company that hired me to grow from $1.5M ARR. The CEO trusted my work, kept the lines of communication open, and let me build. Within twelve months, we were at nearly $3M. The CEO never had to step in. The team executed. The engine worked.
The second was a B2B SaaS trading technology company in 2008 — a hard year to grow anything. We hit $2.8M ARR despite the market environment. Same pattern: a CEO who hired well, gave authority, and let the operator do the work.
I don't share these as case studies. I share them because they tell the truth about what I do and don't control. The work I bring is real. So is the elixir I bring it with. But the engagements that produced these results had something in common that I cannot supply on my own: a CEO who was willing to let someone else operate at depth.
The engagements that haven't reached those numbers had the same pattern in reverse. The CEO pulled authority back when results weren't instant. Or kept changing direction. Or could not let go of being the one doing the work. The architecture was the same; the conditions weren't. The hero couldn't return victoriously because the hero couldn't accept being seen, or guided, or temporarily supported.
What I need you to know about the work.
So if you're considering whether to engage, here's what I need you to know about the work.
Two things are required from you. The first is hiring correctly — and you should know I'm only one of those hires. The people who'll run the engine after I leave matter as much as my arrival does. The second is the authority to do the job, and the willingness to keep that authority given. Engagements that hit the metrics share these conditions. Engagements that don't, lack them.
There's a third thing I'll name plainly because the work won't move forward without it. All success overcomes knowledge barriers and emotional limitations. The structural fixes I bring will press on emotional thresholds that have nothing to do with strategy or operations. Letting go of being in every deal. Trusting a team to produce work you didn't direct. Updating a thesis you've been defending for years. None of these are intellectual problems. The architecture is the easy part. The harder work is whether you're willing to be seen by someone whose job includes seeing you accurately.
If those three conditions are present — hiring well, giving authority, willingness to be seen — the work produces what it's supposed to produce. If they're not, this isn't going to work for either of us, and that's worth knowing up front.
I limit myself to two clients at a time. I bring twenty-plus years of pattern recognition into companies that fit a profile: founder-led B2B SaaS, $1M–$15M ARR. I architect what's missing. I transfer it to the team. I exit.