Welcome

Becoming a fractional CTO clarified something I'd been circling for years. I had been giving advice informally, in one-on-one conversations, in Slack threads, over coffee with founders who weren't sure what they needed yet, but I hadn't been intentional about it. I hadn't written any of it down.

I've spent 20 years building software. iOS in the early days of the App Store, full-stack before "full-stack" was a common job title, DevOps before most small teams thought they needed it. I've shipped over 25 apps, mentored over 45 engineers, run CI/CD pipelines, led sprints, created epics, made architecture decisions I'm proud of and ones I'd reverse immediately given the chance. And through all of that, I've been a junior engineer, a lead, a hiring manager, a systems architect, and eventually a fractional CTO guiding early-stage startups through building and scaling their engineering function from the ground up.

That last role is what changed things. When you're responsible for how a team hires, how it's structured, how it grows, and how it ships, you stop seeing individual decisions in isolation. You start seeing patterns. The same mistakes, made by different teams at different companies. The same candidates underselling themselves in interviews. The same leads struggling with the transition from IC to manager. The same founders underestimating what it actually takes to build something durable. And after enough repetitions, you start to realize that these aren't isolated problems. They're the same handful of problems, recurring everywhere, and most of the people experiencing them think they're the only ones.

I got tired of having those conversations one person at a time. So I started writing them down.

Who this is for

Two audiences, and I'll be honest about both.

If you're an engineer, whether you're just starting out or you're a staff engineer trying to figure out what comes next, I want this to be useful in a specific, practical way. Not motivational. Not abstract. I mean useful in the sense that you read something here and it changes how you prepare for an interview, or how you handle a hard conversation with your manager, or how you approach a technical decision you've been stuck on. I write about how I answer interview questions and why, what I look for when I'm the one asking them, and what I've learned about architecture, systems, and all the messy parts of growing as an engineer that nobody writes documentation for.

If you're a founder or business leader trying to build or scale an engineering team, the value here is different but it's real. I write about what good engineering leadership actually looks like from the inside, how to evaluate technical candidates when you aren't technical yourself, when to hire versus when to contract, and how to build a team that ships without burning out. I'll be upfront about the subtext: these are hard problems and I help companies solve them. But everything I write here stands on its own regardless of whether we ever work together.

What to expect

I'm going to be specific, sometimes critical, and occasionally contrarian when I think the conventional wisdom is wrong. There is no shortage of content online that tells engineers what they want to hear. Tutorials that skip the hard parts. LinkedIn posts that make career pivots sound effortless. Interview prep that teaches you to perform rather than to actually think. That's not what this is.

I'll share things that didn't work as often as things that did. Interviews I bombed, architecture decisions I'd reverse, leadership mistakes I made when I was learning to manage people after years of managing code. The failures are usually where the real material is, truth be told, because success tends to obscure the decisions that led to it while failure puts them right in front of you.

I don't have a posting schedule. I write when I have something worth saying.