SUMMARY
Google’s DORA research found that AI amplifies whatever capability a team already has, for better or worse. McKinsey’s research on the tech talent gap shows why building capability, including through a structured graduate engineering programme, matters more than ever: generative AI isn’t reducing how many engineers organisations need. Efficiency gains are mostly being redeployed into more delivery, not fewer people, and AI adoption is creating new, specialised demand of its own. That leaves building capability internally as the lever every other option now depends on.
Only 16% of executives feel comfortable with the amount of technology talent they have available to drive their own digital transformation, according to McKinsey’s research, published March 2025. Sixty percent of companies cite scarcity of tech talent and skills as a key inhibitor of that transformation.
That figure predates the current wave of AI deployment. Five out of six executives didn’t feel ready before AI added a further layer of specialised demand on top: engineers who can embed, govern and interpret AI tooling, a category of skill that didn’t exist in most organisations two years ago.
The assumption doing the rounds in a lot of boardrooms is that generative AI quietly solves the talent problem on its own: automate enough of the work, and the headcount need shrinks with it.
McKinsey’s own data says otherwise. There is currently no evidence that AI is reducing demand for tech talent. Where AI has freed up engineering time, that time has mostly been redeployed into expanding what delivery teams can output, not into reducing the size of those teams.
Demand for tech talent is likely to be two to four times greater than supply over the coming years. Within the EU alone, the tech talent gap could reach 1.4 million to 3.9 million people by 2027.
Workforce planning built on the assumption that AI shrinks the engineering headcount need isn’t supported by the data available so far.
A team that becomes more capable because of AI doesn’t stand still, it takes on more ambitious work. That’s the amplifier effect at work again, just showing up in headcount instead of delivery stability this time.
Google’s own DORA team reached a similar conclusion from the engineering side in a May 2026 report on the ROI of AI-assisted software development, arguing that “return on investment is no longer a measure of how many developers an organization can replace. It is a measure of how much latent human creativity can be unlocked by offloading systemic toil to these autonomous agents.” Two different research teams, looking at two different data sets, are converging on the same answer: this was never a headcount problem AI could quietly solve.
McKinsey frames the response to the talent gap around four levers: buy, outsource, build, and partner. The report’s own analysis is that buying and outsourcing, the two levers most organisations reach for first, are both structurally limited in the current market.
Buying talent means competing for a pool that’s already short by design, at a cost that keeps rising. Outsourcing carries its own turnover problem, capability that doesn’t stay put.
That leaves building the capability an organisation already has, or is bringing in, as the lever the other three increasingly depend on.
| Lever | McKinsey’s constraint |
|---|---|
| Buy | Competing for a shrinking pool against every other employer doing the same thing |
| Outsource | Turnover risk, capability that leaves when the contract does |
| Partner | Useful, but doesn’t remove the underlying skills gap on its own |
| Build | The lever every other lever depends on working well |
Building capability is easy to say and easy to do badly. Mike Clarke, Mallon’s CEO, has been direct about the difference between capability that’s designed and capability that’s assumed:
“It’s only osmosis training. We don’t subscribe to that.”
Proximity to good engineers isn’t the same as a designed path to capability. A graduate sitting near experienced people absorbs some things by accident. A graduate on a structured, practitioner-led programme is taught deliberately, by people who are still practising engineers themselves, against a standard the organisation can see and measure.
Alwyn Tan went through a Mallon graduate engineering programme as a graduate in 2008. Eighteen years later, now leading Developer Relations at Open Government Products in Singapore, he still uses the mental models that programme taught him. That’s what the “build” lever looks like when it’s done deliberately rather than left to chance, capability that outlasts the specific technology it was originally taught on.
The 1.4 to 3.9 million EU figure and the two-to-four-times demand multiple are already sobering at face value. In financial services specifically, the usable talent pool is narrower still.
Regulatory requirements, security clearances, and the depth of domain knowledge needed to work safely inside a bank’s technology estate all reduce how much of the general tech talent market is actually available to a financial services employer, on top of a gap that’s already wide across the whole market.
That narrower pool is exactly why the build lever matters more, not less, in this sector. An organisation that can develop its own graduates and existing staff against its own systems isn’t competing for the same shrinking slice of experienced hires as everyone else chasing the buy lever.
Building that capability well takes real instructor time, and senior engineers in financial services are already stretched thin on delivery.
That’s precisely why Mallon’s programmes are taught by practising engineers who instruct alongside their own work, rather than asking a client’s own senior team to step away from delivery to design and run a curriculum from scratch.
Buying talent depends on a market that’s short by design. Outsourcing depends on a relationship that can end. Building capability internally is the one lever an organisation controls the timeline and the standard for.
That’s been true for practitioner-led programmes for thirty years. McKinsey’s research just makes it harder to argue with.
No evidence supports that assumption so far. McKinsey found efficiency gains from AI are typically redeployed into more delivery output, not fewer engineers, and AI adoption itself creates new specialised skill demand. Workforce plans built on AI shrinking headcount need aren’t supported by current data.
Demand for tech talent is running at two to four times supply, and outsourcing carries its own turnover risk. McKinsey identifies building skills within the existing or incoming workforce as the lever most organisations can’t avoid, which is exactly what a practitioner-led programme is built to deliver.
That depends on whether onboarding is designed or left to osmosis. A structured, practitioner-led graduate engineering programme puts graduates in front of real code, real instructors and real problems from day one, measured against a standard the organisation sets, rather than a slow, informal ramp shaped by whoever happens to be free to help.
Stop competing for a talent pool that’s short by design. Build the capability your stack actually needs.
For more than thirty years, Mallon Associates has helped financial services organisations build the engineering capability they need, on their own systems, on a timeline they control.
Explore Alwyn Tan’s eighteen-year case study to see how that approach has been applied in practice.
Every engagement starts with a conversation.
Talk to us about building engineering capability.
Michael Clarke is the Chief Executive Officer at Mallon Associates. With over two decades of experience, including deep technical expertise in C/C++, Java, and complex proprietary frameworks, Michael now focuses on technical leadership and scaling engineering operations for financial services firms. He is a recognised expert in developer onboarding strategy, dedicated to bridging the gap between high-level technology and sustainable business growth.