I design the conditions where teams do their best work — then measure whether it actually happened.

15+ years across engineering, product, operations, and leadership. Currently Team Architect / Staff-level engineer operating under a Senior Software Engineer title — building on purpose, not by accident.

I’ve spent 15 years moving between engineering and leadership — not because I couldn’t decide which one I was, but because I kept finding the same problem from both sides: teams that had the skill to deliver but not the conditions to do it well.

I don’t wait for a role to be defined for me. Four or five times across my career, I saw work the organization needed that nobody owned, started doing it without the title or the pay to match, and then made the case — with evidence, not persuasion — for the role to formally exist. That’s how I ended up running engineering career paths, hiring systems, and eventually a whole company, before choosing to come back to hands-on engineering.

The clearest example of that return: in 2018 I became COO of a ~70-person software consultancy. In six months, client NPS went from negative to 99, and employee eNPS went from 10 to 95 — not through new metrics or mandates, but by rebuilding trust first and letting delivery follow. A year later, leadership asked me to start treating people as cost lines instead of the reason the numbers were working. I said no, and went back to engineering. Not a retreat — a decision to keep building the same way, from a different seat.

That’s the thread through everything I do: care and trust aren’t the soft part of the job. They’re the mechanism. When people trust each other, they share problems earlier, coordinate without friction, and ship better work. I’ve measured that trade more than once, and it holds.

Today that shows up as full-stack engineering with an architectural bias — designing the first implementation of something so the second one is configuration, not new code — and as one of the earliest people in my orbit building real multi-agent AI workflows into a production SDLC, not a demo.

What I actually do, day to day

Most days there’s no ticket telling me what to do. I go find the team member who’s stuck, the PR that needs a second pair of eyes, the product idea that hasn’t been scoped yet, the other team that needs an integration assessed. I own work from definition to production, and I do the same review-and-help cycle for whoever’s next to me doing theirs. That’s not extra effort — it’s the actual job, whatever the title on the org chart says.

What I bring that’s harder to find in just one person

Most people are strong in either the technical work or the people work. I’ve spent equal time in both, deliberately, across two parallel tracks: engineering (junior through staff-level architecture) and organizational systems (career-path design, hiring methodology, COO). The engineering depth makes my people decisions precise. The people depth makes my engineering decisions strategic. That intersection — not either half alone — is what I bring to a team.

Two systems I built, not just used

Over 10+ years I built two proprietary people-management systems from first principles, not off a template — a hiring calibration method and a performance/potential framework, both built to work without me standing next to them. Full detail: /method.

Where I am now

I left Dealerware on April 30, 2026, after three years, when the company restructured and moved to cut non-US roles — I was offered a contractor arrangement but we didn’t reach terms. Currently working in fintech, across multiple countries.

On mistakes

I extend the same rule to myself that I extend to a team: a mistake is data, not an identity. Move on, adjust, keep going.