Starting a blog, 6+ years into being a CTO
Why I'm finally writing down what I've learned about building engineering teams, shipping real products, and the parts of technology leadership nobody teaches you.
I've spent most of the last decade building engineering teams and shipping products. I scaled one company from 4 engineers to 31 across 3-4 teams, reached profitability, and hit 10M monthly active users. I've been an interim CTO, a co-founder, a solution architect, and a few other labels that mostly mean "the person who answers when nobody else knows what to do."
I haven't written about any of it.
That's what this blog is for. Not generic "10 tips for managing engineers" posts that get turned out by every consultant with a LinkedIn account. The actual stuff. The mistakes I've watched founders make twice, the reasons technical debt is usually a symptom of a people problem, what AI-first development actually changes in how teams operate vs. what it changes on a pitch deck. The opinions I've formed from shipping, not the ones I've inherited from reading.
Some posts will be technical. Some will be about people, because that's where most engineering problems live. Most will include real numbers from real projects, because abstractions without them are cheap. I'll try to write the things I'd have wanted to read five years ago when I was figuring out whether my first engineering hire should be a CTO (they shouldn't be, but that's a different post).
If you're a founder wondering why your development velocity is slowing, a technical leader navigating your first team expansion, or an operator trying to figure out where AI actually helps and where it's just hype, this is for you. Reach out if there's something specific you want me to write about.