← Opinions

Tech Talent Differential

Across Southeast Asia, I kept encountering the same scene while commercializing software: capable, nouveau tech companies aka vendors on one side of the table, and buyer’s IT teams optimized for an entirely different game on the other. The mismatch was more than just knowledge and skills. It was about incentives and the kinds of problems each side was paid to solve. Over time I started to think of it as the tech talent differential : an asymmetry that quietly dictates the adoption of new technology and becomes even more pronounced when the technology is moving fast.

These tech companies that I worked for often were venture-funded or founded by capable tech specialists. As a result, these companies had the means to employ reasonably good quality tech talent that were both (i) capable and (ii) sufficiently aware of technical trends churning out in the US.

Enterprise buyers, on the other hand, varied. If customers were similar venture-funded tech startups, we could expect similar calibre of tech talent. With such customers, familiarity with general trends or concepts such as APIs and modern tooling (such as Postman to demo APIs) were a given.

But if they were traditional industry players, such as in healthcare SMBs or even larger F&B chains, the talent differential was stark. One memory from healthcare SaaS made this concrete. We were trying to demonstrate to a lab’s IT team how we can deliver lab results at scale and in near real-time to their clinics. Our API was documented in OpenAPI and browsable via Swagger UI—the sort of thing any CS graduate at NUS would find familiar. Yet a technical person in that organization couldn’t translate the documentation into a quick proof of concept. What followed looked less like selling software and more like pair-programming: I was walking through endpoints line by line and explaining how he could deploy it in his organization. Here I was, a law grad still learning the ropes of code, somehow talking him through implementing an API for testing.

I continued to witness this pattern when I worked in FinTech and SaaS at other companies as well. In fact, when we tried to scale SaaS to retail sector in developing markets, we deprioritized IT as a target persona, given their limited influence and knowledge.

Traditional companies in non-tech industries such as healthcare, retail, and F&B are often behind the digital transformation curve, especially in markets such as Southeast Asia. These companies are tech laggards and have not experienced the 10X leverage that a well-executed digital transformation project can bring to their organization. IT remains a necessary but non-strategic layer. As a result, IT teams tend to be cost-centres, with KPIs heavily focused maintenance, efficiency, and issues specific to the governance structures of their respective companies.

When a disruptive technology is launched, these organizations might experience top-down corporate curiosity about the technology. But IT teams lack the skills or know-how on integrating these technologies meaningfully to their organization.

Once you see the tech talent differential , you can start designing around it. The product you ship is the code and documentation, yes, but it’s also a runnable POC, a UI that doesn’t assume expertise, and office hours that turn one motivated employee into a credible internal champion. The commercial plan includes solutions engineers, customer engineers, or partner integrators who can carry the first implementation over the line. And the metric that you game for is time-to-first-POC , allowing buyers to see value in their own context.

This is why pre-sales and after-sales support becomes so important. From a value-add perspective, you need —something— to fill this gap. You have to bridge the tech talent differential to:

  1. educate the organization about the core concepts of a new technology

  2. understand the organization’s business model, context, and strategic issues

  3. frame problem-statements

  4. identify solutions deployable with your technology

  5. build those solutions out (sometimes, co-creation is out of the picture)

  6. educate the broader organization on using these solutions

There’s always a question about productizing the differential. Sometimes you can. If a meaningful fraction of customers share systems and workflows, you can turn what used to be services into managed connectors, recipes, and setup flows. But productizing assumes abstractable problem statements, scalable solutions, and generalized user behavior. That’s not always the case at enterprises, which often develop their unique workflows and tool stacks.

It’s also worth remembering that much of what we sold into traditional industries wasn’t bleeding edge at all. REST as an architectural style was formalized in Roy Fielding’s 2000 dissertation in early twenty-first century. SaaS was a commercially viable technology in 1999 with Salesforces’ founding. And yet we were still introducing those patterns into organizations optimized for processes from the 1990s.

This acute tech talent differential made GTM an interesting challenge.

Implication

This pattern is likely to show up when we see breakthrough technologies like LLM, especially if the new technology is evolving faster than any other technology that came before it (see Mary Meeker’s fun report on this: https://www.bondcap.com/report/tai/).

New technologies require new skills. Changes to new technologies require fast un-learning and re-learning. To truly understand and apply such technologies to new problem areas, you need technical teams with raw intelligence and mental agility for 3 things:

  • Becoming familiar with new technologies

  • Adapting to changes to the technologies

  • Understand different domains — technical and non-techical — to apply these technologies to drive business outcomes.

Such talent are hard-pressed to be in more traditional organizations where technology is merely treated as a cost centres. As a result, they will cluster in organizations where they drive revenue and strategic value.

Even tech companies, not just companies in traditional sectors, that are far removed from inventing platform-shifting technologies might suffer from a lack of such talent in the face of breakthroughs, because their core business might be some other technology. For instance: consider a FinTech company founded in 2015 which focuses on making payments faster. Not all of their engineers might have the time to understand and evaluate the applications of LLMs on their core revenue drivers.

This is true at least for a short period of time while technology continues to evolve.

The bottom line is simple: the tech talent differential is real and structural. It doesn’t disappear just because the technology is “easier” or “more powerful.” Contextualising new technology —particularly one that evolves rapidly— to old problems will be the chokepoint for adoption and retention.