Board to keyboard
Early on you need a strategist, an architect, and someone who'll actually build it — and since you can't afford three people, it had better be one who's done all three.
I've raised money and managed a board, made partnership bets, and made the call no founder wants to make: replacing a CEO and running the company myself until I found the right one. I've also spent today in a codebase. Most senior technical people have let go of one of those ends — the strategist who hasn't shipped in years, or the principal engineer who never learned what the work costs the business.
The two ends aren't separate skills, and they're stronger together. The strategy is worth listening to because I can actually build it; the build is right because I've run a business and know which corners cost you later. You get one person who can move between your board conversation and your data pipeline in the same week — and be a real partner in both, not an advisor passing through.
Keep it lean
Lean isn't spending as little as possible — it's knowing exactly where a dollar turns into ten, and where it just evaporates.
I don't over-engineer, and I don't let teams starve either. Good DevOps and a few solid practices go in on day one — they're cheap, well understood, and they pay immediately. Scale architecture waits until there's something worth scaling. I'll lean on a strategic vendor or an off-the-shelf component to prove a capability and get real market feedback before building the deep version, and I know when that tradeoff stops making sense. Technical debt is a tool, not a sin; the skill is knowing when to take it on and when to pay it down.
What I won't do is watch a company be cheap in the places that matter most. If the right tooling lets one developer do the work of five, you buy the tooling — arguing over a $10 subscription while paying an $8,000 salary isn't thrift, it's self-sabotage. Limited resources are the normal condition of every company worth working for. Making them pay dividends is the whole game.
Context is king
I don't hand people tasks — I hand them the goal, the constraints, and a clear picture of winning, then let them find a better path than I'd have dictated.
People given the real goal instead of a task list are more motivated and usually more right — it's their path, so they own it, and they see angles I'd have missed. I adjust the dial to the person and the moment: sometimes context is enough, sometimes it's context plus a suggested approach, sometimes the situation genuinely calls for "do exactly this." But it starts with context, always.
The same instinct is why I'm good with AI. What makes a person do their best work and what makes a model do its best work turn out to be identical: hand it the goal, the constraints, and a clear definition of done, and you get something you can use; hand it a vague order and you get vague work. The people who never learned to lead this way struggle with their teams and struggle to get value from AI, for exactly the same reason. It was always about context.
The team is the multiplier
A team that trusts each other and pulls the same direction will outwork a more talented team that doesn't — every time, and have more fun doing it.
When people have agency and aren't spending energy covering themselves or looking for someone to blame, the work gets faster and the ideas get better. And the payoff isn't only speed — get the culture right and you get retention, real innovation, and people who genuinely care, none of which a compensation package can buy.
That kind of team doesn't happen by accident, and building it is the job whether I'm forming something new or turning around something stuck. Forming from scratch is the easier case. Transformation is harder, and I'll be honest about the hardest version: when the dysfunction starts at the top, culture change is slow and sometimes impossible. Knowing the difference — and telling you which one you've got — is part of what you're paying for.
Compress the learning curve
What you're actually buying isn't my time — it's compression: the months of trial and error you skip because someone already ran them.
I once watched a capable engineer spend two months stuck on a problem that an hour of the right experience unstuck completely. That hour wasn't valuable because it was mine — it was valuable because it had seen the problem before and knew which three options were already dead.
That's the whole idea. The expensive part of building was never the building; it's the rework, the rewrite you didn't need, the architecture you spend eighteen months unwinding. A fraction of someone who's already made those mistakes, pointed at the handful of decisions that actually compound, beats a full-time hire spread evenly across all of them. You're not paying for my hours. You're paying to skip the ones your team would otherwise burn learning what I already know.