Mayen Ben-Koko, a master’s degree holder in biomedical engineering from Queen Mary University of London is of the opinion that technology should support human judgment, not replace it.

Ben-Koko who is an applied data and digital systems practitioner, with a focus on how machine learning and data workflow are used in real-world healthcare and operational settings said this during an interview with VICTORIA NWACHUKWU.

She is currently based in the United Kingdom, where she works with Giboel and Co. Ltd and also speaks about her work in the digital space.

How would you describe your approach to digital technology in a field often driven by hype and rapid adoption cycles?

I focus on building systems that work quietly and reliably over time. The measure of success is not how sophisticated something looks at launch, but whether it continues to serve people effectively once the excitement has passed. I am cautious about adopting new techniques simply because they are trending. Applying well-established principles thoughtfully, with attention to context and consequences, often delivers more lasting value than chasing the latest trend.

You have worked in an academic research environment and applied implementation settings. How do their approaches to technology differ?

Academic research environments are built for exploration. They encourage experimentation and pushing boundaries, without immediate pressure to deploy or scale.

Applied contexts impose different constraints. You have to consider how systems are actually used, what happens when they fail, and how much complexity people can realistically manage. The focus shifts from what is possible to what is appropriate.

Bridging the two requires restraint. Analytical rigour still matters, but in real systems, clarity and reliability usually take precedence over optimisation.

Your work spans engineering, data analytics, and digital systems applied in healthcare and operational settings. How has your background shaped this system-first perspective?

Engineering trains you to think in terms of systems, constraints, and trade-offs. You are constantly asking how different components interact and what happens when something fails. When you apply that mindset in healthcare or other high-consequence environments, you become acutely conscious of downstream effects.

Poor system design is not just inefficient, it can affect clinical decisions and patient outcomes. Early in my career, I examined a digital workflow where a minor data formatting inconsistency created disproportionate downstream issues because different parts of the system interpreted the same data differently. The fix was simple, but the lesson was not.

That experience shaped how I approach digital work. Reliability rarely comes from complexity. It comes from getting the fundamentals right. If data definitions, workflows, and hand-offs are not sound, adding more technical sophistication only hides the real problem instead of solving it.

What does responsible digital practice mean to you, particularly in regulated contexts?

Responsible digital practice starts with restraint. Not every decision should be automated, and not every pattern in the data should be acted on. Technology should support human judgment, not replace it.

It also means being clear about limitations. Systems should be interpretable, auditable, and designed with appropriate oversight, especially where decisions have real consequences. The goal is not to push capability as far as it can go, but to apply it in ways that are proportionate and defensible.

Responsibility also includes paying attention to who a system works for and who it might exclude. Design choices can unintentionally disadvantage certain users if context is not considered early. Asking those questions upfront is part of building systems that people can trust.

Digital transformation conversations are often dominated by artificial intelligence (AI) and advanced analytics. From your perspective as a systems-focused digital practitioner, where do digital initiatives most commonly break down in regulated or high-stakes environments?

Most real-world problems do not fail at the level of algorithms. They fail at the level of systems. That usually means unclear workflows, inconsistent data definitions, or assumptions about how people actually work in practice.
From looking closely at how digital systems operate in regulated and operationally complex settings, a consistent pattern emerges.

Organisations are often quick to adopt advanced analytics or machine learning tools while foundational issues remain unresolved. Fragmented spreadsheets, duplicated manual entry, and loosely defined processes are treated as minor inconveniences, even though they shape everything that comes after.

In an operational setting I analysed, teams were attempting to generate forecasts from operational data while different groups maintained conflicting versions of the same underlying records.
The models behaved exactly as designed, but the system feeding them lacked shared definitions and clear ownership. The result was an analysis that was technically correct yet difficult to translate into action.

That is why I am cautious about treating machine learning as a default solution. Without aligned workflows and well-defined data structures, advanced models tend to amplify existing weaknesses rather than resolve them. In many cases, clarifying how data is captured, defined, and handed off between people delivers more real-world value than introducing any new algorithm.

Machine learning is increasingly treated as a default solution, particularly in complex analytics. When does it actually add value?

Machine learning adds value when the problem is clearly defined, the data is reliable and representative, and there is a clear feedback loop between outputs and real-world decisions. When those conditions are not met, models tend to amplify existing weaknesses rather than resolve them.

I have reviewed situations where organisations deployed sophisticated predictive models while still debating basic definitions, like what exactly is being measured, when a process starts or ends, or who owns the data at each stage. When those fundamentals are not agreed, model outputs may be technically sound but practically unreliable.

In regulated or high-stakes settings, interpretability often matters more than marginal performance gains. A slightly less accurate model that decision-makers can understand and question is usually more useful than a black-box system that performs well on paper but lacks contextual trust.

You have argued that incremental system improvements can sometimes deliver more value than sophisticated models. What does that look like in practice?

In a digital workflow I assessed, teams were trying to generate forecasts from operational data while the same information was being captured in multiple formats across different tools. A significant amount of effort went into reconciling discrepancies rather than using the analysis to support decisions.

Instead of introducing a new model, the focus shifted to restructuring how data entered the system. Definitions were clarified, duplicated fields were removed, and a single, consistent workflow replaced a patchwork of manual hand-offs. The change itself was not technically complex, but it materially improved the usability of the data.

Once the workflow was simplified and the data structure stabilised, analysis became easier and more reliable without changing the analytical approach at all. The biggest improvement came not from adding intelligence, but from reducing ambiguity. That pattern has repeated itself across contexts I have looked at: when systems are coherent, even simple analytics become powerful, and more advanced models can be introduced later with far less risk.

Why does that kind of foundational work often go unrecognised?

Because it is not spectacular. There is no dramatic technological breakthrough to point to, and no single moment where a new tool suddenly changes everything. Foundational work tends to happen quietly, in the background, through careful decisions about structure, definitions, and process.

When systems start to work properly, they often become invisible. People stop noticing them because things simply flow as expected. Ironically, that invisibility is what makes the work easy to overlook, even though it is what allows everything else to function reliably.

There is also a tendency in the field to equate novelty with impact. New tools and techniques are easier to talk about than careful system design. But in practice, long-term value usually comes from work that is methodical, restrained, and deliberately unglamorous.

Beyond implementation, you also mentor early-career technologists. Why is documentation such a focus for you?

Poor documentation creates fragility. When systems are not clearly explained, people end up relying on assumptions, oral knowledge, or guesswork, which makes systems harder to maintain and easier to misuse over time.

Good documentation forces clarity. It explains not just what a system does, but why it is structured a certain way and what assumptions it depends on. That is essential for sustainability, especially when systems evolve or change hands.

For people early in their careers, learning to document their thinking is also a way of developing judgment. If you cannot clearly explain why you made a design choice, it is often a signal that the choice needs to be revisited.

As digital tools continue to expand into sensitive and regulated domains, what should organisations prioritise?

Trust, reliability, and context. The aim is not to deploy the most advanced technology, but to build systems people can understand and rely on.

That means designing around real workflows, maintaining clear oversight, and knowing where human judgment must remain central. In regulated settings, clarity and alignment matter more than speed or novelty.