I didn't start out wanting to lead. I started out wanting to build things that worked.

The work nobody wants

Twenty years ago that meant writing code. It meant staying late to fix the bug nobody else could reproduce, volunteering for the migration everyone else avoided, taking on the integration that had defeated two engineers before me. Not because I was told to — because those were the problems where you actually learned something.

The glamorous work teaches you execution. The avoided work teaches you how systems fail.

That instinct — chase the problem nobody wants to touch — turned out to be the most durable lesson of my career. It has taken me into the parts of organizations most people route around: the legacy systems, the compliance constraints, the ambiguous mandates with no clear owner. And almost every time, that's where the real leverage was. The avoided problem is avoided for a reason. Which usually means solving it changes something fundamental.

What fintech teaches you

Most of my career has been in fintech and regulated environments, which turns out to be an unusually clarifying place to develop instincts. When your software touches money and regulation, you can't defer the hard questions.

The audit requirement that seems like an obstacle is telling you something about your architecture. The compliance process that slows everything down is a signal about how much your stakeholders trust the system. I learned to stop treating those constraints as friction and start treating them as information.

The engineers and leaders who thrive in regulated environments are the ones who get genuinely curious about the problem underneath the problem.

Fintech compressed the feedback loop between a structural decision and its consequences in a way that makes you think very carefully about what you're building and why — not just whether it works today, but whether it will hold up when the requirements change, the team turns over, or the regulator asks a question nobody anticipated.

The mistake I kept making

For most of my early career, I optimized for the visible outcome. I shipped the feature because the feature was what was being measured. I gave stakeholders what they asked for because that was the fastest path to looking like I'd delivered. I was good at it — and that's exactly what made it dangerous.

The gap between what I was building and what actually needed to be built was invisible until it wasn't. Until the system that seemed clean at launch became the thing everyone worked around. Until the relationship I thought I'd built collapsed the moment I couldn't deliver what they'd assumed I would.

What I learned slowly — and only because I ran into the consequences enough times — is that outcome-independence is a compounding quality.

Doing the hard thing because it's the right thing to build, not because it's the thing being measured, accumulates in ways that are invisible for a long time. The codebase that stays flexible two years later. The stakeholder who trusts you when the news is bad. The team that follows you into the uncertain problem because they've seen how you handle the certain one. None of that shows up in a sprint review. All of it shows up eventually.

On influence and rigor

The same principle applies to influence. The most effective leaders I've worked with weren't the ones with the sharpest pitch. They were the ones who understood what the other person actually needed — and built toward that, rather than toward what they had to offer. Genuine curiosity about what someone else wants turns out to be a more reliable foundation for trust than any amount of persuasion technique.

And then there's rigor. I've sat in enough rooms where a confident presentation collapsed under the first serious question to know that thoroughness isn't about covering your bases — it's about credibility.

The strongest case you can make for anything includes the strongest argument against it. If you haven't steelmanned the opposition, you haven't finished thinking.

What twenty years produces

Those four things — chasing the avoided problem, doing hard things for their own sake, selling by genuinely caring, and stress-testing your own thinking — aren't a framework I arrived at in the abstract. They're conclusions I was pushed to by twenty years of building software, leading teams, and operating in environments where the cost of getting it wrong was real.

They're also, I've come to believe, the qualities that separate engineers and leaders who compound over time from those who plateau.

I write about these ideas here. I'm happy to be challenged on any of them — that's usually where the best thinking starts.