Can you teach adaptability? 

For years, adaptability has been treated as something people either have or they don’t, a personality trait rather than a skill. Working with engineering teams inside major financial institutions over the past year, I’ve come to think that assumption is not just outdated, it’s actively getting in the way of how organisations train engineers for what’s coming. 

Five years ago, adaptability barely featured on a list of important engineering skills. Technical depth, the right languages, the right cloud platforms, was enough. If your knowledge stayed current, you were considered well prepared. 

AI has changed that. New models, coding assistants and tools now emerge faster than most training programmes can be updated. The engineers who thrive won’t just be the ones with the deepest technical knowledge, they’ll be the ones who can accurately tell when a previously effective way of working has stopped being effective, and change course before that costs them. 

That’s the definition I’ve settled on for adaptability in an engineering context: the ability to notice, accurately, when a process or approach that used to work no longer does, and to act on that signal. In practice, engineers fail at this in one of two ways. Either they don’t notice the signal at all, because nobody has given them a structured way of looking for it. Or they notice it and don’t act, because changing an established habit under time pressure is hard, even when you know intellectually that you should. The first is a detection problem. The second is inertia. Any serious attempt to build adaptability has to address both. 

Why engineering leaders are asking different questions 

One of the biggest shifts I’ve seen over the past year isn’t the demand for AI training itself. It’s the questions engineering leaders ask before a programme even starts. 

They’re no longer asking “can you teach our engineers AI.” They’re asking what exactly is being taught, how often the content is refreshed, whether their engineers will understand the underlying principles rather than just today’s tools, and how you prepare people for technologies that don’t exist yet. 

That’s a genuine shift in mindset. Leaders no longer see AI capability as learning a single platform. They’re asking, implicitly, how you build engineers who can keep re-orienting as the ground moves. Which is really the adaptability question again, just framed as a procurement question. 

Teaching it inside the work, not next to it 

Most training separates professional skills from technical content: a module on communication, a separate module on the architecture pattern, a separate module on the AI tool. We’ve moved away from that. An engineer doesn’t experience communication and technical judgement as separate activities in their job, they experience them fused together in specific situations: a daily standup, a technical presentation to a non-technical stakeholder, a 1:1 with a manager, mentoring a junior engineer. Each of these needs a different blend of technical substance and communication approach. 

So where it makes sense, we teach the two together, inside the scenario. Communication in the context of a simulated standup, not as a stand-alone module about clear communication in general. Our experience is that skills built this way transfer to real work far more reliably than the same skills taught in isolation and then, hopefully, combined by the learner later on their own. 

A structured approach to build the habit

The teaching-in-context piece explains where adaptability gets practised. It doesn’t yet explain how you actually build the habit of noticing and acting on signals, rather than leaving it to chance. 

The technique we lean on most heavily is adapted from something the US Army developed in the 1970s and later formalised at its National Training Center: the After Action Review (AAR). After every exercise, a facilitator runs a structured conversation built around four questions. Three of the questions we ask are very close to the original AAR questions: what did you expect to happen, what actually happened, and what will you do differently next time. However, we add a fourth question of our own: did you actually change your behaviour based on the answer you gave to that third question last time. 

That last question is the one doing the real work. The first three build detection, they force you to compare expectation against reality, which is exactly the kind of structured noticing most engineers were never taught. The fourth targets inertia directly, because it makes it very hard to say “I’ll change that next time” and then quietly not change it, when someone is going to ask you about it again next week. 

This isn’t a light-touch reflection. Facilitators actively challenge and validate what learners say in the group discussion, so it can’t become a box-ticking exercise. Where it’s useful, we bring in a concrete number too, for example asking someone to estimate how long a task will take, and tracking over successive cycles whether the gap between their estimate and the actual time narrows. We run this multiple times per week, always structuring it around technical exercises. 

The obvious risk, and how we handle it 

There’s a fair criticism of all this: that focusing on adaptability as its own thing can dilute technical training, turning it into something soft and theoretical at the expense of depth. We think that criticism is right if adaptability is taught as a separate topic. Our answer is to never let it become one. We only address it at the point of an actual technical exercise. There is no module on adaptability in the abstract. It only ever shows up attached to a real engineering task, which keeps it grounded rather than becoming another soft-skills slide deck. 

What we’ve seen in practice 

We ran this approach through a four-week graduate engineering programme for a global bank, working with engineers straight out of university. Most of our standard feedback metrics barely moved. But one question consistently shifted from good to excellent: whether learners felt ready to apply what they’d learned to their actual role. Several graduates told us, in their own words, that the structured reviews gave the exercises a clear purpose beyond simply following steps, that they could see their own skills developing over time rather than just completing tasks. 

That’s still a self-reported signal, not proof that we’ve built lasting adaptability. But it’s a specific, honest result, and it’s the clearest evidence we have that the mechanism is doing something real. 

Building engineers for what’s next 

The pace of change in AI isn’t slowing down, and the way we develop engineering talent shouldn’t stay still either. The better question isn’t whether engineers know today’s tools. It’s whether they have a structured way of noticing when their approach has stopped working, and enough practice at acting on that, that doing so becomes a habit rather than an occasional accident. 

I’d be genuinely interested to hear how other engineering leaders are approaching this. Are you building anything into your own training or onboarding that deliberately targets the gap between noticing something isn’t working and actually changing course? I’d like to hear what’s working, and what hasn’t. 

If you’re exploring how to build adaptability into engineering training or onboarding, we’d be happy to share what we’ve learned and discuss what could work for your teams.