About Rob

I first wrote code in 1994. The pull of making something out of nothing never went away. I started working professionally in the early 2000s, and over two decades the work expanded across the full stack: frontend, backend, server infrastructure, DevOps, integrations, hiring, and team leadership. I pick the right tool for the job rather than stick to one stack.

Along the way, I spent 5 years as a technical interviewer, conducting 700+ structured interviews across companies and skill levels. That gave me a cross-section of developer quality that most hiring managers never see. I know what good looks like, and I know the patterns that predict problems.

I've also taught web development at university level, ran training courses, and spoken at conferences. These aren't things I lead with, but they shaped how I explain technical concepts to people who aren't developers. That skill turns out to be most of what fractional CTO work actually is.

Fast judgment under pressure. When something goes wrong, I find the workaround that buys time while the proper fix is built.

Scope translation. Founders often know everything their product needs but struggle to sequence it. I turn "everything is priority 1" into a buildable plan with clear trade-offs. What's v1? What's later? What can we drop entirely?

Cross-domain thinking. Most dev teams have blind spots shaped by their habitual tools. I bridge those gaps because my experience spans the full stack and beyond.

Hiring and vetting. 700+ interviews taught me to filter for stewards, not just coders. People who own outcomes, not just tickets. As AI changes what "developer skill" even means, this filter matters more than ever.

Trust. My best client relationships go beyond technical calls. A good fractional CTO becomes someone the founder trusts with their product's direction, not just its architecture. That's the dimension that pure CTO labels miss.

I'm a craftsman by temperament. Small teams, simple tools, ship what works. I align with the 37signals philosophy: more code doesn't mean better products, more process doesn't mean better teams. The minimum structure that creates clarity is usually enough.

I still build my own products alongside client work. Not just to stay sharp, but because the best guidance comes from people who are still shipping, still making decisions, still feeling the consequences. If your advisor's only product is advice, ask what they're pressure-testing their ideas against.

I've written more about this on the beliefs page.

I garden, do hand-tool woodworking, take photographs, and write. I have two young kids and I try to be around for them as much as my schedule allows.