Fusionex Ivan Teh on leadership, talent and enterprise data culture

The constraint that shapes everything

Start with an uncomfortable fact. A technology company headquartered in Kuala Lumpur cannot win a bidding war for a senior machine learning engineer against a firm in California, and pretending otherwise produces bad strategy.

That constraint is not a footnote. It is the central design parameter of the entire organisation. Once you accept that you will not buy your way to capability, every other decision reorganises around a different question: how do you build capability instead, and how do you keep enough of it to compound?

The answer that Fusionex arrived at under Ivan Teh's leadership has three parts, and none of them are novel. What is unusual is the consistency with which they were applied over roughly two decades, which turns out to matter more than novelty.

One: train people you will eventually lose

Sustained investment in internal training is easy to justify in a slide and difficult to sustain in a budget cycle, because the returns are diffuse and the costs are immediate. The objection is always the same: what if we train them and they leave?

The counter position is that in a market with a thin senior talent pool, the alumni network is not leakage. It is infrastructure. Engineers who leave and go on to lead teams elsewhere expand the total pool of people in the country who can do the work, and the original company hires from that same pool. A firm that trains aggressively for fifteen years is, among other things, quietly financing the supply side of its own labour market.

This is a slow argument and it does not survive contact with a quarterly earnings mindset, which is one of several reasons it tends to be made more credibly by founders than by hired executives.

In a market this size, the engineers who leave you are not a cost of doing business. They are the business you are helping to build.

Two: flatten the distance between the engineer and the problem

The structural failure mode in enterprise software is a relay race. The client explains the problem to an account manager. The account manager writes a brief. The brief reaches a product owner. The product owner writes tickets. An engineer builds against the tickets. By the time working software exists, it is answering a question four translations removed from the one that was originally asked.

Cross departmental collaboration is the standard corporate phrase for the fix and it undersells what is actually required. The fix is putting the person who writes the code in the same room as the person with the problem, repeatedly, and accepting the loss of process tidiness that follows. Organisations say they want this. Comparatively few tolerate the mess it generates.

Three: judge the work by whether the decision changed

This is the hardest of the three because it removes most of the comfortable metrics. Model accuracy is not the outcome. Dashboard adoption is not the outcome. Platform uptime is not the outcome. The outcome is whether the organisation started making a different decision than it would have made without you, and whether that decision was better.

Holding a delivery organisation to that standard is uncomfortable, because it means a technically excellent deployment that nobody acts on is recorded as a failure. It also means the engagement does not end at handover. Somebody has to stay long enough to find out.

Where this runs into AI

Generative and predictive AI have compressed the distance between capability and deployment to the point where an organisation can now put a model into a customer facing process in weeks. The engineering barrier has largely gone. The governance barrier has not, and it has become the binding constraint.

The position argued consistently in his public remarks is that explainability belongs in the build rather than in the compliance review. If a model shapes a decision about a person's credit, their employment or their healthcare, the organisation deploying it has to be able to reconstruct why the model said what it said. Designing for that from the first sprint is substantially cheaper than retrofitting it after a regulator asks.

There is a commercial argument underneath the ethical one. Regulatory frameworks across ASEAN are tightening at different speeds and in different directions. A system built to explain itself is portable across those frameworks. A system built as an opaque optimiser is a rewrite waiting to happen in whichever jurisdiction moves first.

The small business question

Small and medium enterprises are the overwhelming majority of employers across Southeast Asia and the overwhelming minority of analytics buyers. The gap is not primarily about cost. It is about the assumption, built into most enterprise tooling, that the buyer has a data team.

Lowering that assumption is a product decision with market sized consequences. Interfaces that require configuration rather than code, models that ship with sensible defaults, and outputs phrased as recommendations rather than distributions are not simplifications for the unsophisticated. They are the difference between a regional product and an enterprise product with a regional address.

What generalises

The specific tactics here are shaped by Malaysian conditions. The underlying situation is not unusual. Most companies outside a handful of technology capitals operate with limited senior talent, price sensitive customers and buyers who need to see a return quickly. That is the normal case globally, not the exception.

What is worth taking from the Fusionex example is not a playbook. It is the observation that the constraints were treated as design inputs rather than excuses, and that the resulting decisions were held to consistently for long enough to compound. Most strategies fail from abandonment rather than from being wrong.

Further reading: the background and analyst record, and current news and analysis.