The future is for the operators.

For most of the last twenty years, the person who built valuable companies was the engineer who could also think about a business, or the business person who could hire the engineer.

The next ten years will belong to a different person. The operator who can now build.

My operating career started in 2013.

I had done my MBA at INSEAD, a summer at flynas in Riyadh, a couple of years back at the airline through the Arab Spring, and a stint in strategy consulting after that. Those were training chapters. The operating chapter began when I joined a private equity firm that owned a portfolio of multi-location service businesses in North America and Europe, and my mandate was to scale them nationally and internationally.

That was the first job in which I owned the whole business. Not a slide in a deck. Not a workstream inside a client's project. The actual profit and loss of a business-to-consumer service company that had to find customers, serve them well, invoice them, and grow. Multiple businesses, in fact. Different industries, different geographies, different unit economics, one after another over several years.

What that experience did was force me to become fluent in every discipline that touched the customer journey. I could not delegate any of them to a specialist team and hope, because if any single link in the chain broke, the whole business broke. I had to know enough about each layer to build it, hire for it, review it, and fix it when it went wrong.

A customer had to find us online, through search engine optimisation and paid performance marketing on Google and Meta. They had to land on a website that converted, which required a designer who understood the funnel, a developer who could actually build it, and a conversion-rate optimisation practice that ran experiments continuously against the drop-off points. They had to book an appointment through a booking system that pushed into a CRM that fed the operating team. The operating team had to deliver a service, whether that was a clinical procedure, a home services visit, a real estate showing, or a hospitality experience, and they had to do it inside a piece of software built for the workflow. Embedded analytics had to track every interaction so we knew where the customer was, what they did, and what they did not do. On the back end, the appointment had to produce an invoice, the invoice had to reconcile against the payment provider, the payment had to reconcile against the bank, and the accounting layer had to produce clean books so we knew whether we were making money.

Every link in that chain required a discipline. Every discipline required either a hire or a partner. And every hire and every partner introduced a cost, a delay, and a translation layer between me and what was actually being built.

That was 2013. That was the shape of building a service business at scale. It was also the shape for the next decade, across every chapter of my career after that.

Twelve years of the same problem

I moved from that first private equity firm to Passport Health, where I led the expansion of the business from the United States into Canada. Starting from zero in-country presence, we built the Canadian operation to more than forty locations across the country in three years, on a path to twenty million in annual revenue. Same pattern as the previous chapter. Same disciplines. Different sector, different geography.

I then launched a new United States line of business inside a European hearing-aid platform, focused specifically on consumers with low credit scores. It was a segment the mainstream US hearing-aid market had never structured for, and one that required a different customer acquisition funnel, a different financing partner, and a different operating cadence. Same pattern.

I moved into single-family rental, joining Darwin Homes when the company managed roughly twelve hundred homes across four Texas markets for individual retail owners. Weeks after I joined, the whole business pivoted to serve institutional capital, and I was part of the team that onboarded the first institutional portfolio the company took outside of Texas. Two years later the platform managed six thousand homes across more than twenty American markets. Same pattern, at very different scale, with an engineering and product organisation that had grown to serve the pivot.

Most recently, I led the operational and commercial activation of one of the largest branded residential platforms for senior international professionals in Saudi Arabia. Four communities. Close to a thousand households. Every one of the disciplines above, plus the layers specific to hospitality-grade residential: reservation systems, facilities management platforms, resident applications, concierge desks running on operating software, back-of-house maintenance tracking.

That last chapter was where the operating problem I have been describing throughout this piece became most acute for me, and where the resolution I am about to describe first became visible. The pace at which the Saudi market moves and the pace at which a technical roadmap organised at a distance can move are not the same pace. Not even close. My role on the ground in Riyadh was, in significant part, the translation layer between what the operation actually needed and what any system built without immediate proximity to the operation could deliver. Every requirement had to be assembled in-country, packaged for review, sent, waited for, revised, sent again. It was a version of the problem I had lived with for a decade, in its most concentrated form.

In every chapter, the technology and the capital and the customers were in place. What almost always broke was the operating layer between them.

Across all of those chapters, the operating work I could do myself was worth something. The scaling work required the specialists. The moment the business needed software to run, I lost the pen. The technical team wrote the roadmap. I waited for what I got.

That ceiling has just moved.

What actually changed in the last two years

I have been building software this year at a pace that would have been physically impossible for me eighteen months ago. Full products. Working systems. Real customer-facing tools. Not toys. Not prototypes. Software that customers use, that generates revenue, that runs in production.

I am the sole operator, the sole product manager, the sole designer, and functionally the sole engineer, because the AI tooling that came out over the last two years has collapsed the parts of building software I could not do myself into something I can do.

I write the specification. I ship the code. I design the interface. I integrate the payment gateway, the accounting software, and the bank reconciliation API. I write the SEO copy, deploy the landing page, wire in the analytics, review the funnel data by lunch, redesign the flow, and redeploy by evening. I draft the pitch deck for the capital raise, work through the financial model, and write the memo the investor reads. I run the company formation end to end, from entity registration to bank account opening to tax and payroll setup. I screen the CVs, build the hiring funnel, run the first-round interviews, and draft the offer letter. I draft the agreements I used to send to lawyers, and I send only the ones that need a lawyer to a lawyer. The whole loop that used to require a five-person team and a six-week sprint cycle, plus a fractional finance lead, plus a talent partner, plus outside counsel, now takes me and the tooling and about four hours of concentrated work.

Every discipline that touched the customer journey and the company operating stack. SEO, performance marketing, funnel design, conversion-rate optimisation, product management, UI and UX design, engineering, embedded analytics, CRM configuration, invoicing, payment reconciliation, accounting integration, capital raising, company formation, hiring, and first-pass legal drafting. All of it has collapsed into a single operator role that I now hold entirely.

This is not a claim about being technical. It is a claim about a specific inflection in the tooling that has removed the technical intermediary between the operator and the software.

When the technical constraint drops away, the binding constraint becomes taste. What should the software actually do. What is the workflow the user is really running. What is the sequence of decisions the business is trying to compress. What does the customer notice. What does the customer never see. Which shortcut is worth taking. Which one will look like a shortcut in a year and cost you three months to unwind. Which experiment is worth running. Which one is a distraction dressed up as an initiative.

Those are operating questions, not technical questions. The person who has run the business already has the answers, or at least knows which questions to ask. The person who has never operated has to guess.

Why the trades matter here

The people I have most respected across seventeen years of operating are almost never the people who look impressive on paper.

They are the maintenance manager in a Riyadh compound who can tell you within thirty seconds which unit's air conditioning is about to fail, and why, and what it will cost to fix, and whether the tenant is the kind of person who will complain in a way that becomes a bigger issue than the fault itself. They are the property manager in the American SFR portfolio who could look at a rent roll and tell you which markets were softening two quarters before the data confirmed it. They are the front-desk supervisor who could read a family arriving in a lobby and know, before anyone spoke, whether the assignment would work. They are the pricing analyst at flynas who understood the Riyadh-to-Dubai route because she flew it herself most weekends and could see the passenger mix change month by month in a way no spreadsheet would ever show her.

Almost none of them had elite credentials. Most of them would never have been hired by a consulting firm on paper. All of them could do the specific thing the business actually needed, and none of it was learnable from a deck.

That kind of operating knowledge has always been undervalued in markets that reward the person who can present the work rather than the person who does it. AI does not change that dynamic in the abstract. It cannot manufacture judgment. What AI does, specifically, is remove the technical intermediary between the operator and the software the business runs on. It gives the person who actually knows what the business needs the ability to build the thing themselves, or something close to it, without paying the taxes of translation, roadmap negotiation, and the sixteen-month delay between the idea and the deployment.

The taxes were the whole game. When the taxes go, so does the previous shape of the market.

The rung that just disappeared

For twenty years, the standard shape of building a software-enabled service business looked like this. The operator had the idea, wrote a version of the requirements, hired a technical co-founder or a small engineering team, raised the capital to fund them, spent eight to eighteen months building the first product, released it, learned it was wrong in three or four important ways, spent another six to twelve months rebuilding, and eventually got to something that worked.

At every stage, the operator was paying a translation tax. The engineer heard "the customer wants X" and built something adjacent to X. The designer heard "the flow should feel Y" and produced something in the neighbourhood of Y. The product manager wrote a document, the engineering team estimated against the document, the sprint plan was made, the sprint plan slipped, the release date moved. The marketing team could not test the new landing page because the developer was still working on the last one. The accountant could not close the books because the invoicing system did not talk to the payment provider. None of this was anyone's fault. It was the shape of building a service business when the operator could not build.

The operator who can now build skips the whole rung.

I am not arguing that engineers become unnecessary. Serious software companies at scale still need serious engineering. Systems architecture, security, performance at very large user counts, the specific work of engineering excellence at scale is not disappearing. What is disappearing is the layer of pure translation, execution, and iteration across the customer journey that used to require a team of five to ten specialists and now requires an operator with the right tooling.

For the operator building the next version of a service business, this is not a marginal shift. It is the difference between shipping in eight weeks and shipping in eighteen months. It is the difference between being able to run three product experiments in parallel and having to bet everything on one. It is the difference between the operator retaining creative control over the product and losing it to the roadmap of the technical team.

The operators who understand this and act on it will build differently, faster, and with more control than the ones who do not.

What this does not change

None of what I am arguing removes the need for the operating work itself.

The tools do not build the compound. They do not train the maintenance technician. They do not sit across from the family arriving in Riyadh at nine at night with three suitcases and a story about a lost visa. They do not negotiate the lease. They do not calibrate a team through the second year, when the initial enthusiasm has worn off and the real work begins. They do not sit in the room when the difficult conversation happens. They do not have judgment.

Judgment is what compounds over a career. Judgment is what almost never appears in a person under thirty and what becomes almost impossible to fake by forty. Judgment is what an operator has built over a hundred small decisions, most of which they got wrong the first time, and slowly learned to get right by the tenth.

AI does not accelerate the accumulation of judgment. If anything, it makes judgment more valuable, because the volume of decisions an operator can now execute is far higher than before, and every one of those decisions still needs to be a good one. The operators who thrive in this environment will be the ones with the deepest operating instincts, not the ones with the flashiest tooling.

The person the market will pay a premium for, in five years, is the person who has done real operating work at ground level, and who has learned to build using the tools that now exist. Not one or the other. Both.

Why this matters especially now

The world is entering a period of infrastructure-scale build-out that has almost no precedent since the American postwar boom. Saudi Arabia is the clearest single example, but not the only one. Vision 2030, Expo 2030, the World Cup in 2034, the giga-projects, the residential and hospitality build-out that follows all of them. Elsewhere, similar concentrations of build-out are visible in India, in Indonesia, in specific pockets of Africa, in Latin America's more serious markets.

Every one of these build-outs will require operators. Not consultants. Not investors. Not observers. Operators who can hold the physical work in their hands and also build the software layer that makes it scale.

There are not enough of those operators in the world today. There are especially not enough of them in the markets where the build-out is most urgent. Which is why the operator who can also build has become, in the last eighteen months, one of the most durable and undervalued profiles in the global market.

For an operator with real ground-level experience, and the discipline to learn the tooling, the constraint that used to hold you back has substantially moved. The moment has come.

If you are an investor, an employer, or a partner looking for the person who can actually deliver in the next decade, you are looking for a different profile than the one you have been trained to look for. Not the polished consultant. Not the engineer-founder. The operator who can build.

This is the frame. The specifics, what the tooling now enables, what it does not, what this thesis means for the specific markets I operate in, will follow in later notes. For now, the observation is the argument.

The future is for the operators.