Work.

I've been writing code for close to twenty-five years, and I'm still a technical person at heart. But the work that matters most to me now sits at the intersection of business and technology — making sure teams build the things that actually need building, and that the systems underneath can carry what comes next. The hardest problems I encounter aren't in the code. They're in the gap between what a business needs and what an engineering team is delivering.

These are a few recent examples of the kind of problems I tend to work on.

Project Turnaround A European fintech

From adversarial to autonomous

Six engineers, demotivated. A client, frustrated. Both sides on the verge of walking away from a relationship that had turned purely adversarial. Priorities shifted daily, nobody owned decisions, and capable people had been reduced to ticket executors.

The fix wasn't technical. It was about boundaries and ownership. We defined what belonged to the client and what belonged to us. We started saying no to work that didn't make sense — controversial with a paying client, but necessary. The team went from taking orders to driving decisions. We scaled from 6 to 15. The client relationship became genuinely collaborative. The real shift was simple: people started caring again because they were trusted to.

Product Discovery & Delivery A global payments company

Building ID&V from vague requirements

A multi-alliance payments company wanted to integrate identity verification into their onboarding platform. The direction was clear — the details were not. No spec beyond the high level, a developer experience that made integration harder than it needed to be, and whatever we built had to fit into an established ecosystem without breaking it.

We worked backward from what the platform actually needed — drawing on domain experience and industry standards to turn a broad goal into concrete requirements. We designed a multi-tenant, multi-provider solution and built it while refining the product direction along the way. The result became one of the core capabilities of the platform. The lesson was familiar: when the details are undefined, the most valuable thing you can do is make them concrete.

Technical Reorganization A global bank

Microservice consolidation

Since microservices were “the next thing,” the company ended up with around 120 of them across siloed teams. Boundaries that no longer made sense. Services that existed because someone once needed one, not because the architecture called for it. Operational costs climbing, coordination near impossible.

The technical side — which services to merge, which boundaries to redraw — was challenging enough on its own. But the harder part was that people felt ownership over their microservices. They'd built them, named them, maintained them for years. Consolidating felt like erasing their work. So the real job was organizational: restructuring into stream-aligned teams, breaking down walls, getting people oriented around business capabilities rather than defending their own services. We got to 80 services. The system became cheaper to run and easier to change. But the bigger win was that teams could finally work across what used to be borders.