Work.

The hardest problems I've worked on had less to do with code than you'd expect. They were about teams that had stopped communicating, systems that grew around org charts instead of business needs, and the gap between what a company says it wants and what it actually needs.

These are a few of those stories.

When people stop caring

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.

Making the undefined concrete

A 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.

People name their services

A company ended up with around 120 microservices across siloed teams — because microservices were “the next thing.” 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 overly attached to 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 silos, 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.