I'm an engineering manager. I've spent years building teams, shipping software, and keeping infrastructure from catching fire — sometimes successfully.
The name is deliberate. Rough edges aren't a failure of craft. They're what you get when you make real decisions under real constraints. Every system has them. Every team has them. Anyone who tells you otherwise is either lying or hasn't shipped anything lately.
The philosophy
I'm pragmatic by nature. I believe, genuinely and without irony, that perfect is the enemy of the good.
That belief shows up everywhere in how I work:
Building software. The codebase that ships and solves the problem is better than the elegant one still being architected. Technical debt is real, but so is the cost of never finishing anything. You make tradeoffs. You document the ones that matter. You move.
Running infrastructure. Nobody ever needed a five-nines SLA for an internal tool that three people use on Tuesdays. Right-sizing matters. The system that's up and understood beats the one that's theoretically perfect but too complex to operate without its original author.
Managing people. A team that ships regularly, learns from its mistakes, and trusts each other is a good team — even if the processes aren't textbook, the standups run long sometimes, and the roadmap gets renegotiated every quarter. Management isn't about optimising people. It's about creating conditions where good work happens.
What this blog is Link to heading
I’ll write about engineering leadership — the craft of it, the messiness of it. How to make decisions when the information is incomplete. How to give feedback that actually lands. How to think about technical strategy without disappearing into abstraction. When to push and when to let it go.
Some of it will be opinion. Some of it will be things I’ve learned the hard way. None of it will be theory for its own sake.
If that sounds useful, stick around.