There's a version of seniority that looks like this: you stop building things, and you start managing people who build things. You sit in strategy sessions. You review decks. You approve budgets. Your output becomes other people's output.
I understand why that happens. It's efficient. It scales. And for a lot of leaders, it's what they wanted when they started.
It's never been what I wanted.
The real reason I kept shipping
When I was at Hewlett-Packard, I spent my days running analytics programmes across global marketing campaigns. Millions of data points. Dashboards that influenced eight-figure decisions. Real enterprise work at real scale.
And on nights and weekends, I was building small things. A recipe blog. A travel tool. A price calculator for Etsy sellers. Things that had nothing to do with my day job and everything to do with staying honest about how the internet actually works.
The two things fed each other in ways I didn't fully understand until much later.
When you're building for yourself, there's no committee to blame. No roadmap to hide behind. No "let's deprioritise that." The product either works or it doesn't, and you're the one who has to fix it.
That feedback loop — the directness of it, the honesty of it — made me a sharper thinker in every enterprise room I walked into. I stopped accepting "we'll test that in Q3" as an answer when I knew from personal experience that you could run a basic experiment in a weekend.
What 14 products taught me
I've shipped 14 products independently over the past decade. Some made money. Most didn't, not meaningfully. All of them taught me something the corporate world doesn't easily surface:
1. Distribution is harder than building. Every enterprise team I've worked with underestimates this. When you're building alone, you feel it immediately — a perfect product that nobody finds is a failed product. It recalibrates your instincts about where to invest.
2. Constraints are a gift. No budget, no team, no brand — you get very clear very fast about what actually matters. I now apply the same constraint-first thinking to enterprise programmes with eight-figure budgets and it consistently surfaces the right priorities.
3. Shipping matters more than planning. Not instead of planning. More than. The number of enterprise projects I've seen die in the planning phase because nobody had the personal experience of shipping something would fill a graveyard.
4. Users don't read your intentions. They use what you built, not what you meant to build. Solo building gives you this feedback unfiltered. No user researcher translating for you. No PM layer. Just you and the data.
The craft argument
There's a version of leadership that says your job is to get results through others, full stop. I half-agree. But I think the most effective leaders in technical disciplines are the ones who maintain genuine fluency in what their teams do.
Not so they can micromanage. So they can ask better questions. So they can smell the difference between "we're blocked" and "we're avoiding the hard thing." So they can walk into a technical conversation and contribute something real.
Side projects are how I maintain that fluency. They're my forcing function. Without them, the gap between what I say I know and what I actually know would grow — slowly, invisibly, until it mattered in the worst possible moment.
What I'd tell a senior leader considering this
Start small. One project. One hypothesis you want to test. Give yourself six weeks and a real constraint: no team, no budget, just you.
You'll be humbled. That's the point. The humbling is what recalibrates you.
And then take what you learned back into the room where you make the big decisions. You'll find you make better ones.