I like owning the whole problem, not just the technical part.

I have built product interfaces, backend services, data pipelines, cloud infrastructure, and production systems. I usually get involved when a problem does not fit neatly into one team or one layer of the stack, or when something important needs a clear owner.

For me, ownership means following the work beyond implementation: understanding the product, making sound technical decisions, helping the team deliver, dealing with what happens in production, and staying with the problem until it is actually resolved.

Some of that breadth came from working in startups, where responsibilities are rarely tidy. I have led business and partnership conversations, helped shape product direction, supported commercial decisions, and worked across technical and non-technical teams. But the habit has carried beyond startup environments: I am most effective when I understand the wider context around the system I am building.

I still stay close to the engineering. I write code, review implementations, investigate failures, and contribute to architecture and infrastructure decisions. Leadership has not meant moving away from the work; it has meant taking responsibility for more of what surrounds it.

How I work

I like understanding the product before deciding how to build it. That usually means asking what the user is trying to do, where the real complexity sits, and what will become painful to change later.

I prefer simple systems with clear responsibilities. When complexity is necessary, it should be visible, measurable, and explainable.

Outside work

I am usually playing table tennis or travelling across West Africa—occasionally both with more confidence than planning.