Ask the owner of a small electronics firm what happens if the firmware lead resigns, and most say they would manage. Then ask who else can produce the exact binary that shipped to the customer last March. Usually there is a long pause. The source code sits in a repository. The compiler version, the linker script, the licence dongle and the signing step live on one laptop and in one memory.
Our electronics hub answer fits on one line: written knowledge someone can actually use, a second person on the product, rotating reviews, and all of it inside the engineer's job. Here that answer is taken apart, followed by the questions that come up once owners begin.
Where does the dependence actually sit?
Rarely on the whole person. It sits on a handful of tasks only they can do. Walk through each product with the engineer and list those tasks. Be precise. 'Knows the firmware' tells you nothing. 'Alone can flash the bootloader on revision D boards' points you at the work.
- The build: toolchain version, linker settings, licence dongle and the steps that produce a signed release image.
- The bootloader, the fuse settings and the factory programming jig configuration.
- Board bring-up: power sequencing, which rail to probe first, the microcontroller errata the startup code works around.
- Production test scripts and the fixture code that the line depends on every day.
- Customer memory: why a requirement was waived, which field units run which firmware version.
- Supplier memory: which alternate parts were qualified, and why one was rejected after a failed soak test.
Put the list on one sheet per product. Add a column for the second person and the date they last did each task alone. Most firms find three or four lines with an empty second column. Those lines are the risk. Everything else can wait.
Files and tools the understudy must be able to find
- The makefile or build script, the exact compiler release and any licence server it contacts.
- The linker map, the memory layout and the reason for each reserved region.
- The code-signing key, who holds its passphrase, and the sealed escrow copy the owner keeps.
- Debug probe settings, flash algorithms and the fuse bits set at the factory jig.
- Vendor errata sheets, with each workaround marked against the startup code that implements it.
- The production test firmware, which often lives in a separate, half-forgotten repository.
- The bring-up notebook: rail voltages, scope captures and the order parts were populated on the first prototype.
How do I spread it without stalling releases?
- 1
Name a second engineer per product
Choose someone at mid level who will stay on that product for at least a year. A fresh graduate on their own cannot absorb a whole firmware stack.
- 2
Run the clean-machine build
The second engineer rebuilds the last shipped release on a machine that has never seen the project, using only what is written. Every point where they get stuck becomes a new paragraph in the notes.
- 3
Hand over one real task
The next bug fix or small feature goes to the second engineer, with the senior reviewing the merge request. Doing the work teaches more than reading about it.
- 4
Rotate reviewers
Code reviews and schematic reviews go to a different reviewer each time, so more than one person has read every module.
- 5
Lead bring-up together
On the next board spin, the second engineer runs bring-up with the oscilloscope and debug probe while the senior watches and answers.
Notes fail when nobody tests them. The clean-machine build is the test. If the second engineer's binary matches the shipped checksum, the notes work. If it does not, you know exactly which page is missing.
Will the engineer resist?
Sometimes, and for reasons worth respecting. Some fear that being replaceable makes them easier to lose. Others are simply stretched, and writing notes feels like time stolen from the release. Name both openly. The aim is to let them take leave, move to a new product and be promoted. None of that is possible while they alone can ship a fix.
Then make the handover count. Write it into their goals with a check anyone can see, such as the second engineer shipping a release unaided by a named quarter. Credit the mentoring hours when you rate their year. Performance management that ignores those hours will produce the opposite behaviour.
Should I pay a retention bonus?
Some owners use one to hold a key engineer through a release. It does not reduce dependence. On the day it ends, the exposure is exactly where it was. If you use one, link it to the handover. Release part of it as the second engineer completes each listed task alone.
What if they resign before any of this is done?
Use the notice period deliberately. Put the task list in front of the engineer on day one, agree which items move in which week, and keep them on handover rather than new features. The overnight-resignation drill covers the wider plan. Ask whether they would take a few questions after leaving. Many will, if they part on good terms.
Where should I begin this week?
Pick your most important product. Write its single-person list with the engineer who owns it, name the second person and book the clean-machine build for next month. Succession planning can widen this to every key role later. The retention work for embedded firms helps keep the senior engineer while the knowledge spreads, and one engineer owns a whole product describes the pattern in full.
