My Point of View
Not a blog post. A working thesis on how I think about technology, teams, and the work of leading engineering at scale.
These are the beliefs I keep coming back to — the ones that survive the next tool, the next framework, the next reorganization. They shape how I lead, how I hire, how I evaluate platforms, and how I pick the problems worth solving.
Technology is an operating model problem before it is a tooling problem.
Tools matter, but they rarely fix unclear ownership, weak incentives, or disconnected priorities. Before we argue about platforms, we should agree on who owns the outcome, how work flows between teams, and what the business is actually trying to do. The tooling conversation becomes easier — and cheaper — once those are clear.
AI will reward organizations that learn faster, not just ship faster.
The advantage will not go to the organization with the most AI pilots or the biggest model budget. It will go to the one that builds feedback loops, challenges its own assumptions, and adapts the operating model as the work changes. Shipping velocity without learning velocity is just expensive motion.
Platform engineering should reduce cognitive load.
A platform is not successful because it exists. It is successful when teams can move faster with less friction and more confidence. Every platform decision should be evaluated by whether it makes the daily work of engineers easier, not by how elegant it looks on an architecture diagram.
Developer experience is a business capability.
Developer experience is not an internal nicety or a recruiting perk. It shows up in delivery speed, quality, reliability, cost, and the ability to retain the engineers you want to keep. Treat it like a product with measurable outcomes, not a side project that gets attention when someone complains loudly enough.
Trust is the hidden architecture of high-performing teams.
Teams move faster when they trust the system, their leadership, and each other. No framework, ceremony, or tool substitutes for that. When trust is present, small process problems get solved quietly. When trust is absent, even good processes produce friction. Leaders spend too much time on process and not enough on the conditions that make process unnecessary.
Leaders need to stay close to the work.
Leaders do not need to write every line of code, review every PR, or sit in every design session. But they do need to understand how the work is changing — especially when AI, platform shifts, or new delivery models are rewriting the ground rules. Leadership that is three layers removed from the craft makes slower, weaker decisions.
If any of this resonates — or you think I have one of these wrong — I would genuinely like to hear it. Good points of view get sharper when they meet other points of view.
Get in touch