Blog

I started out editing somebody else's blog in high school and ended up doing enterprise architecture and fractional CTO work. The technologies changed the whole way through, and they turned out to be the part that mattered least. Here's what actually carried.

NIST, ISO 27001, and SOC 2 all say the same thing about incident response: when someone knows how to fix it, get out of the way. The process documentation can happen after the fire is out. Here's what happens when organizations forget that, and why AI-driven security tooling is making it worse.

The instinct when you're new on a team and hit conflict is to win the argument. Every time I've tried that, it made things worse. The fix is almost never about being right. It's about building the process that should have existed before you got there.

A PM, an Engineer, and a Designer walk into a planning meeting and someone says, "We need this feature on iOS, Android, and the web." But that isn't the start to a joke...

Junior engineers can write code. What they can't do is tell you things like why a build failed, write a useful commit message, or handle the case where everything goes wrong. That gap doesn't close on its own.

I spent an hour saying 'I don't know' on a digital whiteboard. Here's what went wrong and how I'd approach it now.

The best answer to this question isn't a technology. It's a follow-up question. Here's why that matters and how to use it.

Most candidates treat this as a warm-up. Hiring managers treat it as signal. Here's how to use it.

The question isn't whether to fix tech debt. It's whether fixing it right now will create more value than anything else you could do with those engineer-hours.

Most teams skip architecture reviews because they feel slow. The cost of that decision compounds in ways that don't show up until it's too late to fix cheaply.

20 years of building software, leading teams, and sitting across the table from candidates. Here's what I'm doing with all of it.