Top 10 Technology Operators to Watch This Year
Not the founders with the largest rounds. The operators quietly making the infrastructure, governance and deployment decisions that the rest of their sectors will copy within two years.
Daniel Achebe
Technology Editor, WEVN
14 min read
The technology press covers capital. This list covers deployment.
Each of these ten has made a technology decision in the past year that was structurally awkward, internally contested and, in our reading, likely to become standard practice in their sector. We have deliberately favoured people who run systems over people who announce them.
Rafael Mendoza
Chief Technology Officer, Meridian Data
A stopped pilot used to read as a write-off. Now it reads as the system working.
Rafael Mendoza's contribution to this list is not a technology. It is a one-page gate that most of his own colleagues resent filling out. Between 2023 and 2025, Meridian Data's nineteen artificial intelligence pilots produced three production systems — a ratio Mendoza came to see as a governance failure rather than a technology one, since the budget approvals that let all nineteen proceed sat on his own desk.
The gate now asks three questions before any pilot receives further funding: who owns the resulting workflow once the pilot team disengages, what the operating baseline was before engineering became involved — recorded by the business side, not the technical team, so the pilot cannot grade its own homework — and what a confidently wrong output actually costs in the specific workflow it touches. Six pilots have run through the gate since. Four reached production. Two were stopped, and Mendoza treats the stops as evidence the process works rather than evidence of failure, since a quarter spent discovering a workflow was not ready is cheap and deploying into an unready workflow is not.
What makes Mendoza worth watching for an operator audience specifically is how uninterested he is in the model layer. Asked what he would tell a peer starting the same exercise, his answer skips the technology stack entirely: write the baseline down before engineering starts, and put a name on the door of every system before it ships. Neither instruction requires a procurement decision. Both, in his account, are the actual reason four systems shipped instead of zero.
Priya Nair
Head of Platform, Corvid Payments
Forty-one services was a map of our org chart, not a map of what customers needed.
Priya Nair inherited a platform team at Corvid Payments maintaining forty-one internal services, a number that had accumulated over several years as each new initiative shipped its own service rather than extending an existing one. Over eighteen months she cut that number to nineteen, a consolidation that meant retiring services still actively used by internal teams who had, in several cases, built workarounds specifically because the existing services did not do quite what they needed.
The disruption was real and Nair does not minimise it. Teams that had built dependencies on soon-to-be-retired services lost velocity during the migration windows, and several of those teams pushed back hard enough that the consolidation timeline slipped by roughly a quarter against her original plan. What she held firm on was the principle rather than the pace: a service count that reflects an organisation's historical initiative structure, rather than its current operational needs, becomes a permanent tax on anyone trying to reason about the system as a whole.
Incident volume has fallen to a level Nair describes as, for the first time in her tenure, actually investigable — a team can trace a production issue through nineteen services with a shared understanding of ownership in a way that was not realistically possible across forty-one. She is candid that the number nineteen is not itself the point, and that she expects it to be wrong again within a few years as the platform grows; the discipline she is trying to institutionalise is the willingness to consolidate again when it does, rather than defending the service count on the grounds that a previous consolidation already happened.
Erik Halvorsen
Director of Data Engineering, Nordlys Retail
Six of eleven requested dashboards died the moment someone had to name the decision they'd change.
Erik Halvorsen's team at Nordlys Retail received eleven dashboard requests in a single planning cycle. His response was not to prioritise them. It was to require each requester to state, in writing, the specific business decision the dashboard would change and how that decision was currently being made without it. Six of the eleven requests were withdrawn during that exercise, not because Halvorsen rejected them but because the requesters could not complete the form.
The withdrawal rate is, in Halvorsen's account, the actual value of the process, and a more useful outcome than building all eleven and discovering later which ones nobody opened. Retail organisations in his experience accumulate dashboards the way they accumulate meetings — each one individually reasonable to request, collectively representing a build queue that crowds out data work tied to a decision someone can actually name. Requiring the decision to be named up front moves that filtering cost from after the dashboard is built, when a data engineering team's sunk effort makes the tool hard to retire, to before, when the cost of saying no is a form left incomplete.
He has since extended the same requirement to internal data pipeline requests more broadly, and reports that the completion rate for the decision-justification field has become, informally, a better predictor of whether a request will actually get used than any priority score his team previously assigned. The five dashboards that survived the original round of eleven are, notably, still in active use over a year later — a retention rate Halvorsen contrasts pointedly with his team's historical experience of dashboards quietly abandoned within two quarters of being shipped.
Sarah Boakye
Chief Information Security Officer, Ashgrove Financial
A permanent temporary exception is just a risk nobody scheduled a conversation about.
Sarah Boakye found, on taking over information security at Ashgrove Financial, a backlog of several hundred security exceptions managed through email threads with no consistent expiry. Each individual exception had, at the point it was granted, a reasonable justification. Collectively, the backlog represented an accumulating set of risks that no one in the organisation could summarise, prioritise or defend to an auditor without a multi-week reconstruction effort.
Her fix was structural rather than a renewed effort to chase down the existing backlog. Every exception now lives in a register with a mandatory expiry date, and expires automatically unless someone actively renews it with updated justification. The change reframed the default from permanent-until-someone-notices to temporary-unless-someone-actively-decides, which sounds like a small reordering and produced, in practice, a collapse in the backlog from several hundred live exceptions to a number Boakye can now read aloud in a board meeting without referring to a spreadsheet.
The resistance she encountered came less from the security team, who welcomed the visibility, than from business units accustomed to exceptions that quietly persisted for years without anyone revisiting whether the original justification still applied. Several renewal conversations surfaced exceptions granted for systems that had since been decommissioned entirely, still nominally "live" in the old email-thread system because no one had been prompted to close them out. Boakye's broader argument to peers considering the same change is that an exception register without expiry dates is not really a control at all — it is a historical record of decisions that stopped being reviewed the day they were made.
Diego Salcedo
Vice President of Engineering, Lumen Grid
If you ship the change, you carry the pager for it. Everything else is a polite way of avoiding that sentence.
Diego Salcedo rebuilt Lumen Grid's on-call rotation around a single rule: whoever ships a change carries the pager for it, replacing a rotation staffed by a dedicated on-call team largely disconnected from that week's deployments. The rule sounds obvious stated plainly and was, in practice, a significant behavioural shift for engineers accustomed to shipping code and handing operational risk to someone else's schedule.
Deployment frequency fell for roughly a quarter after the change took effect, which Salcedo had anticipated and describes as the expected and correct short-term cost — engineers newly accountable for their own changes' operational consequences slowed down, in many cases because they had not previously had to think carefully about rollback plans or blast radius before shipping. What followed the initial slowdown was a recovery to above the pre-change deployment frequency, alongside a materially lower rollback rate, which Salcedo attributes to engineers internalising operational risk at the point of writing code rather than treating it as a downstream problem for whoever happened to be on call that week.
The policy required Salcedo to defend an uncomfortable transition period to his own leadership, since the visible metric — deployment frequency — moved in the wrong direction for several months before the underlying behavioural change produced the results he had predicted. His advice to engineering leaders considering the same move is to commit to the policy for a full quarter before evaluating it, since the discomfort of the adjustment period is, in his account, indistinguishable from failure if you are only watching the topline deployment number.
Anika Reddy
Head of Machine Learning, Steppe Insurance
We used to design the model first and figure out what to do when it wasn't sure afterward. We reversed the order.
Anika Reddy instituted a rule at Steppe Insurance that no machine learning model reaches production without a documented, tested answer to what happens when the model abstains — declines to make a confident prediction rather than guessing. The rule sounds like a minor engineering requirement and has, in her account, restructured how her teams approach model design from the earliest stages of a project.
Designing the abstention path first, before the model's core prediction logic is finalised, forces an earlier and more honest conversation about what a human reviewer actually does when the model punts a case to them — a workflow that teams building the prediction logic first tended to treat as an afterthought, often discovering only at deployment that no one had built the review queue, the escalation path or the staffing to handle abstained cases at the volume the model actually produced them.
The unexpected benefit, Reddy reports, has been regulatory rather than purely operational. Insurance models face a level of scrutiny around explainability and failure handling that many machine learning teams are not accustomed to from consumer technology backgrounds, and a documented, deliberately designed abstention path has made her team's models substantially easier to defend to regulators and internal audit than a model whose behaviour in uncertain cases was never explicitly specified and had to be reverse-engineered after the fact. She now treats the abstention design document as a required deliverable earlier in the project timeline than the model's accuracy benchmarks — a sequencing that several of her engineers initially resisted, on the grounds that designing for failure before the system worked felt premature.
Bram de Vries
Chief Technology Officer, Wijnhaven Logistics
A third of the migration scope turned out to support workflows nobody had used in two years.
Bram de Vries froze a multi-year platform migration at Wijnhaven Logistics that was, by the time he arrived as chief technology officer, roughly a third of the way through its planned scope and consuming a significant share of the engineering organisation's capacity. In place of continuing the migration, he ordered a full written inventory of what the legacy system the migration was meant to replace actually did — not what its documentation claimed, but what functionality was genuinely still in active use.
The inventory found that close to a third of the planned migration's scope existed to support workflows that no one inside Wijnhaven had used in over two years, remnants of business processes that had been superseded by other systems without anyone formally decommissioning the legacy functionality that supported them. Migrating that unused third had been consuming real engineering time on the theory that a complete migration was inherently safer than a partial one — a theory de Vries's inventory directly contradicted.
The freeze was unpopular with an engineering team partway through execution and invested in finishing what they had started, and de Vries describes the internal case for stopping mid-migration as harder to make than the original case for starting it, since a paused migration reads, to people who have not seen the inventory, as wasted effort rather than as a correction. The rebuilt migration plan, scoped to the two-thirds of functionality the inventory confirmed was actually in use, ran over its revised budget modestly and has already, in de Vries's assessment, returned more value than the original full-scope plan would have delivered on schedule — chiefly by not consuming engineering capacity on functionality nobody needed migrated in the first place.
Fatima Al-Rashidi
Director of Infrastructure, Qanat Telecom
We had a recovery plan. We had never once run it end to end. The outage was the first time.
A regional cloud outage exposed, for Fatima Al-Rashidi and Qanat Telecom, a gap that had existed on paper for years without anyone treating it as urgent: a documented multi-region recovery plan that had never actually been executed end to end, tested only in tabletop exercises that walked through the steps conceptually rather than exercising the actual infrastructure failover. When the outage hit, the plan's untested assumptions proved costly in ways the tabletop exercises had never surfaced.
Al-Rashidi's response was to negotiate Qanat out of its single-region cloud footprint entirely, a rebuild she describes candidly as unglamorous and over the initial budget she proposed to the board. The project offered none of the visible feature progress that typically makes infrastructure investment easy to justify internally — for most of its duration, the rebuild produced no customer-visible change at all, which made it a difficult budget line to defend in a planning cycle dominated by initiatives with clearer near-term returns.
The rebuild has, by Al-Rashidi's account, already paid for itself once, in a subsequent regional disruption that Qanat weathered without customer-visible impact using the newly built multi-region failover — a direct contrast to the earlier outage the original single-region architecture had been unable to survive. Her standing recommendation to infrastructure peers is to actually execute a full-scale recovery drill at least annually, not a tabletop version of one, on the grounds that a recovery plan's untested assumptions are, functionally, no different from having no plan at all until the moment they are tested for the first time during a real outage.
Joon-ho Park
Head of Product Engineering, Baekdu Software
Deletion needs its own budget line, or feature work will always outbid it.
Joon-ho Park gave every product engineering team at Baekdu Software a standing budget for code deletion and made that budget explicitly non-transferable to feature development — a team that does not use its deletion allocation in a given cycle loses it rather than reallocating the capacity to shipping new functionality.
The non-transferability rule is, in Park's account, the entire mechanism that makes the policy work. He had observed, before instituting it, that deletion work reliably lost every prioritisation conversation against feature work with a visible customer or revenue outcome attached, regardless of how strongly individual engineers argued for the long-term value of a smaller, more maintainable codebase. Making the deletion budget forfeitable rather than fungible removed deletion from that competition entirely — teams could no longer trade it away under pressure from a roadmap deadline, because there was no mechanism to do so.
Codebase size at Baekdu has fallen for four consecutive quarters since the policy took effect, while release velocity has held steady rather than declining, which Park treats as evidence against the assumption — common among his own engineers before the policy — that time spent deleting code is necessarily time not spent shipping product. His broader observation, offered to peers at other software companies considering a similar approach, is that most engineering organisations already agree in principle that technical debt matters; the actual obstacle is rarely disagreement about the value of deletion; it is that nothing in a standard prioritisation process protects deletion time from being traded away, cycle after cycle, for whatever feature is most urgent that particular week.
Louise Tremblay
Chief Digital Officer, Meridienne Group
Every vendor proof of concept we ran with the vendor's own engineers in the room came back looking great. That was the problem.
Louise Tremblay ended a practice at Meridienne Group that had, until her arrival as chief digital officer, been standard for every significant vendor evaluation: running proofs of concept with the vendor's own engineers embedded directly in the implementation team. The practice was well-intentioned and produced, in Tremblay's assessment, systematically misleading results — a vendor's own engineers, deeply familiar with their product's configuration and edge cases, will reliably produce a smoother implementation than Meridienne's internal team would achieve unsupported after purchase.
Her replacement policy requires every vendor evaluation to run entirely on internal staff, using internal infrastructure, with vendor personnel available only for documentation questions rather than hands-on implementation support. The immediate effect was a longer and messier evaluation process — internal teams unfamiliar with a new tool's quirks took noticeably longer to reach a working proof of concept than a vendor-assisted team had previously taken, and several evaluations surfaced integration friction that vendor-assisted proofs of concept had never once revealed.
That friction is precisely the signal Tremblay was trying to recover. The number of tools failing within four months of a full purchase and rollout has fallen sharply since the policy took effect, which she attributes directly to evaluations now measuring what Meridienne's own team could actually accomplish with a product rather than what a vendor's specialist could accomplish on Meridienne's behalf during a supervised trial. Her standing guidance to other digital leaders evaluating enterprise software is blunt: if the vendor's engineers are in the room during your proof of concept, you are not evaluating the product, you are evaluating the vendor's implementation team, and you will not have access to that team after the contract is signed.
A note on selection
We do not accept payment for inclusion in this list. Where a leader on any WEVN list has separately taken part in a paid feature, that feature is labelled as sponsored on its own page and the relationship is disclosed here.
Nominations are open year-round at editor@wevnnow.com.
- #top 10
- #technology
- #operators
Keep reading
Related Articles
Top 10 Leaders Shaping Global Business in 2026
Our annual roundup of the executives whose decisions this year will still be visible in their industries in five. Selected by the WEVN editorial desk for operating judgement rather than profile.
21 min read
Mid-Market Capital Is Quietly Returning to Corridors Large Funds Left
Sponsors who spent two years concentrating on core markets are reopening conversations in secondary corridors, and the terms on offer look different to the ones that were available before the pullback.
1 min read
Boards Are Tightening Oversight of AI Spending, and Asking a Harder Question
Directors who approved exploratory AI budgets on strategic grounds are now asking who is accountable for a wrong output. Several technology chiefs say it is the most useful question their boards have asked.
1 min read
The Journey of Adaeze Okonkwo: Building a Logistics Network Across Fourteen Markets
The Kestrel Logistics founder started with three trucks and a spreadsheet. She now moves freight across fourteen African and Gulf markets, and she still reviews the routing exceptions herself every Monday.
3 min read