How I lead

Titles describe scope, not behavior. These are the five principles I actually use — the ones I reach for when a team is struggling, a roadmap is slipping, or someone asks why we work the way we do.

The team is the product

My job is not to build the product; it is to build the system that builds the product. Team topology, hiring bar, career paths and the seams between teams decide more about what ships than any technical choice. When delivery hurts, I look at the org design before I look at the code.

Shipping is a habit, not an event

Big launches are where momentum goes to die. I optimize for small batches, short feedback loops and a release cadence boring enough that nobody fears Fridays. Predictability is what buys an engineering org the trust to take real bets.

Design is not a department

I trained as an industrial designer before I led engineers, and I have never managed to separate the two. Performance is design. Error states are design. The API a team exposes is design. Engineers who understand the user ship better systems, so I put them in front of users early and often.

Give ownership slightly too early

People grow when the responsibility is real and a little uncomfortable. I hand engineers ownership just before they feel ready, then back them visibly and coach in private. Most of the managers and leads I’ve grown started with a problem that was technically still mine.

Platforms are products too

Internal tools, APIs and developer experience deserve roadmaps, users and quality bars — not leftover time. Years on API Manager taught me that treating the platform as a product is the difference between teams that compound and teams that grind.

---

None of these are original, and none of them work as slogans. They work as defaults — the thing I do when there is no time to think. If you want to compare notes on any of them, tell me what you’re building.