Where I'm Coming From

I don't believe you can judge how someone will work with you from a list of competencies. What matters is where their instincts come from — what they were doing when they learned what they now treat as obvious. So instead of a career history (my LinkedIn holds that format), this is the shorter version of the question every client eventually asks me: why do you work the way you do?

It started with code

I came to technology leadership through the long way: a computer engineering degree, then years of writing software hands-on — low-level code first, then platforms, then the architecture that holds them together.

That origin left me with an instinct I've never been able to switch off: I cannot make a decision about technology without understanding what it costs to build and what it costs to keep running. It's why my strategy work never floats free of engineering reality — I've been the person who had to live with the diagram.

Hard places are honest teachers

The defining move of my career was geographic: taking enterprise engineering into emerging markets across Africa. Environments where connectivity, budgets, and vendor ecosystems can't be assumed — and where a system that isn't simple and locally owned simply dies.

Comfortable environments let bad technology decisions hide for years; hard ones expose them in months. Working there taught me to scope every system for total cost of ownership, for the team that inherits it, and for adoption rather than delivery — because I watched what happened to systems scoped any other way.

What humanitarian work adds

Three years in Lusaka, Zambia with the United Nations World Food Programme — the world's largest humanitarian organization — building field-level digital systems, including a food tracking system carrying real distribution operations for real beneficiaries.

Humanitarian delivery is enterprise IT with the margin for error removed: multi-stakeholder governance, austere infrastructure, and software that people's food security depends on. It's where engineering discipline and change management stopped being separate subjects for me — a technically perfect system that the field staff route around is a failed system, full stop.

Seeing how the best run

With EPAM Systems I worked from the other end of the spectrum: product engineering for global enterprise clients, inside one of the world's strongest engineering organizations.

That chapter answered a question the hard places couldn't: what does good look like at scale, when it's resourced and mature? Much of what I bring to organizations still building their capability is exactly this — knowing which practices of mature engineering organizations transfer, and which are luxuries of their context.

The practice this adds up to

Today I lead IT and digital strategy for enterprises, international NGOs, and UN agencies. Everything above compresses into a few working principles:

• No technology decision without its full cost — build, run, and the organizational change it demands.
• Simplicity and local ownership beat sophistication — a system the organization can't run without me is my failure, not theirs.
• Adoption is the deliverable — engineering and change management are one discipline, not two workstreams.
• Judge practices by their context — what works in a mature global organization may be poison in a constrained one, and vice versa.

If where I'm coming from sounds like where your organization is going, the next step is a conversation.