From frontend craft to owning the gap between building and deciding what to build.
Eight years ago I started as a frontend engineer. Built UI, shipped features, got decent at React and Angular, and genuinely loved the craft of it.
At some point I got curious about what was happening under the screens I was building, so I moved into backend and full-stack work. I wanted the full picture, not just my slice of it.
Then delivery happened to me more than I chose it. A client call needed someone in the room, an architecture decision needed an owner, and I stayed close to both. Turns out I liked being useful on both sides of that line, which is how I ended up leading technical direction and mentoring engineers as a Tech Lead, not just writing code.
That delivery instinct scaled into something more structured over time: running end-to-end delivery for concurrent client engagements across trading platforms, logistics systems, AI automation, and SaaS products, owning scope, timelines, and the client relationship from kickoff to close. I lead cross-functional engineering teams, mentor engineers toward their own delivery and leadership roles, and push engineering standardization through measurable KPIs and structured technical audits rather than tribal knowledge. The throughline is combining hands-on technical review (codebase audits, architecture assessments) with delivery discipline (structured reporting, risk management, stakeholder communication), so things ship reliably under real client constraints.
Now most of my time goes into AI Product Engineering: Claude Code, the Model Context Protocol, agentic workflows, building things end to end and delivering them to real users and clients.
One thing I hold to, regardless of how much of the work AI touches: AI gets you to about 80%. The remaining 20% needs a human to actually check it, and that 20% usually holds half the real risk. Review isn't optional overhead. It's the job.
Here's how that arc has played out in practice.
See the roles