I've spent a meaningful chunk of my career in organisations where engineering and L&D sit in the same company but operate in almost entirely separate worlds. L&D builds courses. Engineering builds systems. L&D measures completion rates. Engineering measures shipped features and system uptime. They don't share vocabulary, they don't share tools, and they rarely share assumptions about what good learning looks like.
This piece is about the gap between what engineering teams actually need from L&D, and what most L&D functions deliver. The gap is wider than most L&D professionals want to admit — and it's almost entirely our problem to solve, not engineering's.
What engineers need from L&D
I'm going to be direct about this, because it took me a while to see it clearly.
Technical accuracy above everything
Engineers will immediately stop trusting learning content the moment it contains a technical error. Not gradually — immediately. And once trust is gone, it's very difficult to rebuild. The threshold for acceptable accuracy in technical content is essentially zero errors. This is different from most other audiences, where learners may not notice inaccuracies or may give content the benefit of the doubt.
This means L&D practitioners working with engineering teams need to either have genuine technical fluency in the domain, or have a structured review process with subject matter experts who do — and who are given enough time to do the review properly, not as an afterthought the week before launch.
The credibility threshold is very low. One wrong variable name in a code example. One outdated API call that no longer works. One statement about how a system behaves that doesn't match how it actually behaves. That's enough. Engineers will share the error, the team will hear about it, and your content will be labelled unreliable.
Practical tools, not conceptual frameworks
Engineers primarily learn by doing. Not by watching videos about doing. Not by reading about principles and then being left to figure out the doing on their own. By actually doing things, hitting problems, solving them, and building mental models from that direct experience.
This means the most effective learning interventions for engineering teams tend to be: hands-on labs, sandbox environments, documented internal runbooks, internal tech talks where peers share how they actually solved problems, code review as a teaching mechanism, and pairing arrangements with more senior engineers.
Courses work for foundational concepts. They work poorly for developing the judgment that comes from real engineering work. The L&D challenge is to build the scaffolding around real work, not to replace real work with simulation.
Peer learning is the default, not the alternative
In most engineering organisations, the dominant learning mode is already peer learning — through code review, internal documentation, Slack threads, architecture review sessions, and informal knowledge transfer. L&D is rarely the primary channel. Engineers already have their preferred channels.
The mistake many L&D teams make is trying to compete with or replace those channels. The opportunity is to strengthen them — better documentation processes, internal tech talk programmes, structured onboarding that connects new engineers with the right people, knowledge base infrastructure that makes tacit knowledge explicit.
Async by default
Synchronous training is a significant interruption to engineering work. Most engineers operate in flow states — periods of deep concentration that take real time to enter and that are expensive to interrupt. A two-hour synchronous training session is not just two hours — it's two hours plus the cognitive cost of context-switching, plus the time to re-enter flow state afterward.
Engineering teams respond much better to async-first learning — content they can consume on their schedule, reference documentation they can return to when they need it, short just-in-time resources at the moment of application rather than long batched training at arbitrary intervals.
What most L&D teams actually deliver
I am going to be honest here because I think it's more useful than diplomatic.
Generic content with a technical veneer
Off-the-shelf or vendor-supplied technical courses often have the right keywords in the titles — "Python fundamentals," "cloud architecture," "DevOps practices" — while being genuinely shallow on the specifics that matter for how those skills apply in your specific environment. An engineer who knows your codebase, your deployment pipeline, and your incident response process needs very different learning content from a course built for a generic audience.
The mismatch between generic content and specific context is where most technical L&D fails. Engineers don't just need to know how something works in theory. They need to know how it works here, in our systems, with our constraints.
Compliance-shaped learning
A lot of what engineers are mandated to complete is compliance training — information security, data privacy, code of conduct, workplace safety. Much of this content is built to satisfy a checkbox, not to change behaviour. It's long, it's dull, and engineers know it's long and dull. They click through it as fast as possible. This is probably fine for most compliance content, which exists primarily to establish organisational legal protection rather than to genuinely educate.
The problem is when L&D teams apply the same design pattern — passive content consumption, completion tracking, minimal interaction — to learning that actually needs to change behaviour. Compliance-shaped learning is not appropriate for building technical capability.
Engineers often have strong opinions about their own learning needs. These opinions are usually correct — they know what skills the work requires. The instinct to treat engineers as learners who need guidance toward what's good for them, rather than as professionals with valid self-knowledge about their development, tends to produce friction.
Why the gap exists
Several reasons, most of which are structural rather than individual failures.
L&D teams are often built for a different kind of organisation — one where the primary training need is behavioural (customer service, sales, compliance) rather than technical. The skills and instincts that work well in behavioural training transfer poorly to technical domains. Building a course on how to have a difficult conversation is fundamentally different from building content about distributed systems architecture.
L&D practitioners also frequently lack the technical fluency to be genuine partners with engineering teams. This isn't a personal failing — it's a hiring and development gap. Many L&D functions don't include technical learning experience designers who can hold their own in a conversation about code, systems design, or engineering practice.
Finally, success metrics are misaligned. L&D is often measured on completion rates, satisfaction scores, and cost per learner. Engineering teams are measured on delivery velocity, system reliability, and code quality. These metrics don't connect. If L&D cannot show a direct line from its work to outcomes that engineering leaders care about, L&D becomes something engineering tolerates rather than values.
What to do differently
If you're an L&D practitioner working with or aspiring to work with engineering teams, here is what I'd actually recommend.
Embed early. Get into engineering team rituals before you're asked to build content. Attend sprint retrospectives. Read post-incident reviews. Understand what actually goes wrong and why. Content built from that understanding is fundamentally different from content built from stakeholder interviews.
Build technical credibility before building content. This might mean learning to read code in the primary language your teams use. It might mean completing the same onboarding that new engineers complete. It definitely means not pretending to understand things you don't. Engineers have strong instincts for when someone is bullshitting them about technical topics.
Partner with tech leads, not just managers. Engineering managers often have less insight into day-to-day knowledge gaps than senior individual contributors and tech leads do. The people who review code, mentor junior engineers, and field the same questions repeatedly are the people who know what's actually needed.
Measure what engineering measures. Time to first meaningful contribution for new hires. Reduction in repeat incidents linked to the same knowledge gap. Code review cycle times. If you can't connect your learning interventions to these outcomes, you're probably building the wrong things.
If you're navigating technical L&D in an engineering organisation — or trying to build the case for it — I'd genuinely like to talk: connect on LinkedIn.