The short version: I learned business before I learned software. I grew up around companies, where how work gets promised, priced, and delivered was ordinary conversation, and the engineering degree came afterward — almost as a way of understanding the other half. By the time I was managing projects, reading a codebase and reading a budget felt about equally natural, and what kept standing out was how often good work went wrong: not because the idea was weak or the engineering was bad, but because no one had reconciled the two.

That turned out to be the part of the job I cared about most. A business decides it wants something and describes it in the language of outcomes and deadlines. A team of engineers builds it in the language of systems and trade-offs. Most of the time both sides are competent and working in good faith — and they still end up describing two slightly different things, and no one notices until it is expensive to fix.

So most of what I do is translation. I turn intent into a spec the engineers can actually build against, and turn technical constraints back into plain language the business can make decisions with. I sit in the meetings where the two sides would otherwise talk past each other, and I keep asking the unglamorous question — are we sure we mean the same thing? — until the answer is genuinely yes.

"Most of the job is making sure everyone in the room is describing the same thing."

These days I do that at Bold XP in Riyadh, where the projects are larger and the rooms more crowded, but the work is the same. Seventeen projects in — across fintech, health, commerce, and social products — I've stopped thinking of it as project management in the coordinating-timelines sense. It's closer to interpretation: keeping the thing that was imagined and the thing that gets built pointed at each other, all the way to delivery.

I don't think that's a method I picked up so much as the only way the job ever made sense to me — coming at it from both sides at once.