Every engineering leader eventually asks the same question about their team.
What happens when the person who knows the most about a critical system isn’t available?
If the answer is that delivery slows, questions go unanswered, or another engineer has to start from scratch, there is a capability gap. And the gap is rarely visible until the person concerned moves teams, takes leave, or leaves the business.
We have been thinking about this question for thirty years. In that time, more than 10,000 engineers have gone through the practitioner-led programme we deliver for a leading global investment bank. What we have learned about closing capability gaps at that scale is what this article is about.
Building engineering capability means closing that gap deliberately, before it turns into an incident.
The organisations that do this well end up with something more resilient than any single engineer. They end up with engineering capability that scales.
Engineering capability is more than the technical skills held by individual developers.
It is the collective ability of an engineering organisation to understand its technology, solve problems, make sound technical decisions, and continue delivering as systems, teams and technologies change.
A developer who knows how a particular system works has knowledge.
A developer who understands why it was designed that way, can diagnose problems when it behaves unexpectedly, and can explain the reasoning to another engineer has capability.
When that knowledge and judgement can be transferred across a team, the organisation itself becomes more capable. That is the outcome to build for.
Most engineering teams have people who know more about particular systems than anyone else.
They know why a decision was made. They understand an unusual dependency. They remember the workaround introduced three years ago. They know which part of the architecture needs to be treated carefully.
That expertise is valuable.
The problem starts when the organisation becomes dependent on a single person to access it.
This is critical-person dependency. It is the quiet operational risk sitting inside almost every engineering team we work with, and it rarely appears on any risk register until the person concerned gives notice.
Building engineering capability means addressing critical-person dependency before it becomes a problem. Not by making individual engineers less important, but by making sure their expertise has an impact beyond the work they personally deliver.
Technical documentation is essential. Architecture decisions need to be recorded. Systems need to be documented. New developers need reliable information to work from.
But documentation alone cannot create engineering judgement.
A document can tell an engineer what a system does. It is much harder for a document alone to teach them why it works that way, what trade-offs were made, or what to do when something unexpected happens.
That understanding develops through experience: working through real problems, hearing experienced practitioners explain their reasoning, and applying what has been learned with feedback from someone who has done it before.
The most effective knowledge transfer combines documentation with practical learning, mentoring and exposure to real engineering environments. Neither element on its own gets the organisation there.
Complex engineering environments cannot be understood through generic training.
The tools may be familiar, but the way an organisation uses them is shaped by its architecture, engineering standards, development practices, regulatory environment and business requirements. Java at one bank looks different from Java at another. Cloud infrastructure at a fintech scale-up looks different from cloud infrastructure at an asset manager.
That is why practitioner-led learning is so valuable. Engineers learn from people who understand not just the technology, but how it behaves in real engineering environments.
Alwyn Tan went through a practitioner-led Mallon programme at Morgan Stanley in 2008. Eighteen years later, now leading Developer Relations at Open Government Products in Singapore, he still uses the mental models he was taught. The specific technologies have changed. The way of thinking about how technology works has not. That is what practitioner-led capability development looks like on a career horizon.
Case Study
In 2008, Alwyn Tan was a graduate engineer on a Mallon Practitioner-Led Programme. Today he leads Developer Relations at Open Government Products. One phrase from that programme is still part of how he works.
Read the case study →Engineering capability starts developing before a new developer makes their first contribution to production.
The onboarding experience shapes how quickly someone understands the technology, the engineering culture and the way the organisation works. A strong developer onboarding programme does more than introduce tools and processes. It should help new engineers understand:
The objective is not to complete an onboarding checklist. It is to build the foundations for independent engineering capability.
Knowledge transfer is often treated as an activity that happens when someone is changing roles or preparing to leave a team. By then, it is usually too late.
In capable engineering organisations, knowledge transfer is part of normal engineering practice. Experienced engineers explain decisions. Developers document systems as they evolve. Teams review technical work together. Engineers teach one another. New developers are given opportunities to solve problems rather than simply being given answers.
Over time, this creates a culture where knowledge naturally moves through the organisation. The result is not just better documentation. It is a deeper and more resilient engineering capability.
AI is changing how software is produced. Developers can now generate code, explore unfamiliar codebases, create documentation and accelerate parts of the development lifecycle in ways that were not possible two years ago.
That creates opportunities, and changes what organisations need from their engineers.
When code can be generated quickly, the ability to judge that code becomes more important, not less. Engineers need to understand architecture, security, performance, maintainability and the context in which a solution will operate. They need enough underlying knowledge to recognise when something looks plausible but is fundamentally wrong.
AI can accelerate the production of technical output. It does not remove the need for engineering judgement. If anything, it makes that judgement more valuable.
That is why organisations investing in AI engineering also need to invest in the underlying capability of the engineers using it.
The clearest test of whether an engineering organisation has built capability is what happens when good engineers leave.
Sam Moorhouse joined the Mallon practitioner-led programme as a graduate at Morgan Stanley in 2006. He later taught on the same programme as a Mallon instructor, in New York, London, Shanghai, Bangalore and Mumbai. He then founded Turntabl in Ghana, where he now hires Mallon to deliver the same practitioner-led model to his own engineers.
That is engineering capability compounding across three roles and two continents. It is what happens when the model behind the training is durable enough that a graduate can become an instructor, and eventually a client, without the model needing to change.
Mallon has been running the same practitioner-led programme at a leading global investment bank for over thirty years.
That is not a training relationship.
Over thirty years, more than 10,000 engineers have gone through the programme.
That is engineering capability sustained at institutional scale.
There is no single programme or tool that creates engineering capability. It comes from combining several elements.
Practitioner-led learning. Engineers learn from people with genuine experience of the technologies and environments they are working with.
Structured developer onboarding. A consistent pathway from introduction to practical contribution.
Contextual technical documentation. Capturing not just what systems do, but the decisions, assumptions and reasoning behind them.
Deliberate knowledge transfer. Creating opportunities for experienced engineers to teach, mentor and explain their thinking.
Learning through real engineering problems. Applied knowledge rather than isolated theory.
Engineering judgement. Developing the ability to question, assess and improve technical solutions rather than simply implementing them.
Continuous capability development. Treating learning as part of engineering practice rather than something that ends when onboarding finishes.
Technology organisations will continue to change. New platforms will emerge. Legacy systems will need to evolve. AI will reshape development workflows. Engineers will move between teams and businesses.
The organisations best equipped to handle those changes will not necessarily be the ones with the largest engineering teams. They will be the ones that can develop, transfer and retain engineering capability effectively.
That means investing in people. It means creating better onboarding. It means learning from practitioners. It means treating technical documentation as knowledge management, not administration. And it means building an environment where engineers are continually learning from one another.
Because engineering capability is not measured by how indispensable one person becomes. It is measured by how effectively the organisation can keep moving when knowledge needs to move with it.
For more than thirty years, Mallon Associates has helped financial services organisations build the engineering capability they need to operate in complex technology environments.
Every engagement starts with a conversation.
Talk to us about your 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.