A firmware engineer leaving halfway through development is rarely just a staffing problem. It’s a knowledge problem, and knowledge is much harder to replace than headcount. The person who leaves usually isn’t just writing code – they’re the one who remembers why a particular workaround exists, which peripheral has an undocumented quirk, and which of three plausible architectural choices was actually made, and why.
Anything not captured in a commit message, a test plan, or a test report is no longer available. The worker with the knowledge is not available to be asked.
What actually leaves when the engineer does
Undocumented architectural decisions
Every embedded project accumulates decisions that made sense at the time but look arbitrary in isolation: a particular interrupt priority chosen to avoid a timing conflict discovered during bring-up, a buffer sized larger than the spec strictly requires because of a field issue on an earlier revision, a communication protocol implemented one way rather than another because of a constraint that no longer applies. A specification document captures what the system is supposed to do. It rarely captures why a specific implementation choice was made over the alternatives, and that reasoning is exactly what a new engineer needs to safely change the code later.
Hardware-specific tribal knowledge
Embedded firmware is unusually entangled with the specific hardware it runs on, in ways that are harder to fully document than pure software logic. Which pins are more sensitive to noise on this particular board revision. Which peripheral driver or bootloader has a quirk that required a specific workaround. Which test conditions actually reproduce an intermittent fault. This kind of knowledge tends to be built through direct experience with the hardware rather than written into any specification, which makes it the hardest category to hand over cleanly – and the easiest to lose entirely.
The schedule cost of rebuilding context from scratch
A new engineer, even a strong one, can’t be handed a codebase and told to “become an expert as soon as possible” without a significant cost in time. Every hour spent reconstructing undocumented decisions through trial and error, or re-discovering a hardware quirk the hard way, is an hour not spent moving the project forward. On a project already running to a launch date, that cost compounds: the schedule doesn’t pause while someone rebuilds the context the previous engineer carried in their head.
Why this is worse in embedded projects than in general software
In application software, a departing engineer’s knowledge gap can often be closed by reading the code in isolation – the logic is usually self-contained, and the runtime environment is predictable. Embedded firmware doesn’t offer that luxury. Understanding why the code behaves a certain way frequently requires understanding the hardware it’s running on, including quirks and workarounds that exist nowhere in the codebase itself, only in test logs, commit messages, email threads, or a departed engineer’s memory. This is also why embedded teams are more exposed to a single point of failure: it’s genuinely common for one engineer to be the only person who has worked closely with a particular RTOS or platform, especially on a small team or a project with a lean specification budget.
What to do in the first week
The instinct when an engineer leaves is to move fast and reassign their work immediately. It’s usually more effective to spend a few days doing something narrower first: identifying what’s genuinely undocumented versus merely uncommented, and prioritising the handover of anything safety-critical, anything touching hardware interfaces directly, and anything the departing engineer built without much peer review along the way. A short structured handover conversation, even a partial one, is worth significantly more than the same amount of time spent independently reading code, because it surfaces the “why” that code alone doesn’t communicate.
If the departure was sudden and no handover is possible at all, the priority shifts to controlled discovery: getting a new engineer – internal or external – comfortable enough with the specific subsystems at risk to make safe changes, before asking them to take on new feature work.
Where an external partner fits
Bringing in an external firmware partner to absorb a knowledge gap works differently from bringing one in to add general capacity. Bringing in an external firmware partner to absorb a knowledge gap is a different exercise from bringing one in to add general capacity. It isn’t really about extra hands. It’s about experience: a team that has picked up unfamiliar, partially undocumented codebases before, and knows how to get productive in them quickly. That means not assuming the documentation is complete, and not assuming anyone will be around to answer every question.
This is close to the situation we found ourselves in on a fire safety curtain fault investigation, where a developer had introduced an undocumented change with no access to the reasoning behind the original design. Diagnosing and resolving that kind of issue without the original engineer’s input is a specific skill, not a byproduct of general firmware competence – and it’s exactly the skill this situation calls for. As Dr Mike Fletcher, Technical Manager at one of our long-standing clients, put it:
“Their expert staff have helped to move projects forward quickly and efficiently, augmenting our own in-house development team. For detailed knowledge and speed of response I thoroughly recommend Peter and the team at Bermondsey.”
An external partner brought in for this reason should expect to spend real time upfront on structured code review and requirements reconstruction before writing new code – not because it’s the safe, cautious option, but because skipping it is how mistakes get made in code nobody currently understands. If you’re evaluating who’s actually equipped to do this well, the questions worth asking a potential partner matter just as much here as in any other engagement.
How to reduce the risk before it happens again
The uncomfortable truth is that most teams only think seriously about this risk after it’s already materialised. A genuine skills gap and a single-point-of-knowledge risk are related but distinct problems, and closing the second doesn’t require solving firmware hiring – which is hard, and slow, on its own. It requires treating architectural reasoning and hardware-specific knowledge as things that need to be captured deliberately, not as a byproduct of writing code that will naturally get documented along the way. It’s a pattern we’ve dealt with across a range of past engagements, and it’s part of why clients bring us in as an extension of their team rather than a one-off contractor.
If you’re dealing with a knowledge gap left by a departing engineer and want to talk through how to close it without derailing the project, book a free 30-minute consultation with one of our engineers.
FAQs
What happens when a firmware engineer leaves mid-project?
Beyond the immediate staffing gap, undocumented architectural decisions and hardware-specific knowledge typically leave with them, since embedded firmware knowledge is often built through direct hardware experience rather than captured in a specification or code comments.
How do you recover from losing a key firmware engineer?
Start with a short, structured handover if any is possible, prioritising regulated code and hardware-facing interfaces. Where no handover is possible, focus on controlled discovery of the highest-risk subsystems before assigning new feature work to a replacement engineer.
Should I hire a replacement or bring in an external partner?
It depends on whether the gap is capacity or specific knowledge recovery. A partner experienced in picking up unfamiliar, partially undocumented codebases can often absorb the immediate risk faster than a new permanent hire can be found, hired, and brought up to speed.
How do you document firmware knowledge to prevent this in future?
Beyond standard code comments, capture the reasoning behind non-obvious architectural decisions and any hardware-specific quirks or workarounds as they’re discovered, rather than assuming they’ll be self-evident to a future engineer reading the code.
Is this risk higher in embedded firmware than in general software development?
Generally yes, because embedded firmware behaviour is often tied to specific hardware quirks that exist nowhere in the codebase itself, unlike application software where the logic is usually more self-contained and the runtime environment more predictable.
What should I look for in a partner brought in to absorb this kind of knowledge gap?
Evidence of having picked up unfamiliar or undocumented codebases before, a willingness to spend real time on code review and requirements reconstruction before writing new code, and references from engagements where they worked alongside – rather than replaced – an existing team.
Other services we offer
- Embedded Firmware
- Embedded Software
- Embedded Design Verification
- Embedded Software and Firmware Development Services
Industries we serve
Related blogs
- Why Is Hiring Qualified and Experienced Firmware Developers So Hard?
- Addressing Skills Gaps When Developing Embedded Firmware Systems
- Zephyr vs FreeRTOS vs ThreadX: Choosing the Right RTOS
- Is Zephyr OS Too Complicated? What the Learning Curve Actually Looks Like
- The Missing Link Between Requirements Documents and Hardware-in-the-Loop Testing
- How to Choose an Embedded Software Development Partner (And the Questions to Ask)
- Supporting Legacy Firmware When the Original Developers Are Gone
- The Firmware Decisions That Delay Your Product Launch
- Where AI Actually Helps in Embedded Firmware Development (And Where It Doesn’t)
- Yocto vs Buildroot: Choosing an Embedded Linux Build System
