A field batch of cold-chain data loggers starts dropping readings after a frosty night in a hill-station warehouse. The fix needs a change to the temperature sensor driver and a fresh firmware build. The engineer who wrote that driver is on leave in his village with patchy signal. Nobody else knows which compiler version the build expects or where the signing key lives. The customer waits, and the owner discovers how much of the product sits inside one person.
Among the people risks in electronics and embedded firms, this is the one owners most often notice too late. One developer can end up holding everything about a firmware stack or a board design, and their departure then threatens the business itself.
Tell-tale signs of a single owner
- Only one person can produce a release build from a clean laptop.
- Board errata, workarounds and jig settings live in that person's notebook or memory.
- Customer engineers phone that person directly and skip everyone else.
- Code reviews on that product are skipped or waved through because nobody else follows the code.
- Leave requests from that engineer are quietly refused whenever a release is near.
The cost lands before the exit as well as after
Everyone sees the stalled release, or the field fix nobody can ship. The quieter costs pile up beforehand. The engineer never takes proper leave, so exhaustion creeps in. New hires get no meaningful work on the product. The owner hesitates to challenge that engineer on anything, behaviour included. When the resignation finally arrives, the notice period dissolves into frantic handover meetings that capture a fraction of what matters.
A sale or an investment round can expose it too. Buyers and investors ask who understands the product, and an honest answer of one name dents their confidence.
How small teams drift into it
Embedded start-ups are built for speed. The first engineer writes the bootloader, the drivers and the application because nobody else is there. Later hires join other products. Design notes never make the sprint plan, and appraisals ignore them. Pairing looks like halving output. The engineer may even enjoy being indispensable, especially when pay and recognition have lagged behind.
Spreading the knowledge, one move at a time
- 1
Draw the map first
For each product, list the firmware stack, the board, the test jig, the build and signing process and the customer contact. Mark who can handle each item unaided. Single names form your risk list.
- 2
Name a backup for every single-name item
Choose a second engineer and give them a target date by which they can do it alone.
- 3
Make the build reproducible
The backup produces a release image on a clean machine using only the repository and written steps. Toolchain versions, keys and scripts are recorded and stored securely.
- 4
Pair on live work
The backup takes the next bug fix or feature on that product, with the owner reviewing. This teaches more than any document.
- 5
Rotate code and design reviews
Every change to the product gets reviewed by someone other than its owner.
- 6
Write it into goals
Documentation, pairing and a backup who can deliver alone become part of the owner's appraisal, with credit for doing it well.
Product: ________.
Firmware stack and repository: owner ________, backup ________.
Board design files and errata: owner ________, backup ________.
Test jig and calibration settings: owner ________, backup ________.
Release build and image signing: owner ________, backup ________.
Customer technical contact: owner ________, backup ________.
Date the backup last handled each item alone: ________.What the notes should capture
- Pin-mux and clock-tree choices, with the reason for each one.
- Known silicon errata on the microcontroller and the workaround in code.
- Why the linker script, memory map or partition table looks the way it does.
- How to recover a bricked unit through JTAG, SWD or the UART bootloader.
- Pogo-pin wear on the programming jig and how often the pins get replaced.
- Which customers run which firmware version in the field, and why any are held back.
None of this needs polished prose. A markdown file in the repository, a few annotated scope captures and a short screen recording of the recovery procedure will save a backup days of guesswork.
Our succession planning service begins with exactly these roles. To write the backup duty into a role, see role design at embedded systems companies. To plan headcount around single points of failure, see workforce planning for IoT device makers.
Bringing the owner along
Spreading knowledge can feel like a threat to the engineer who holds it. Explain that the point is to free them for harder problems and real holidays, not to replace them. Link the change to a lead or principal title and give visible credit for the notes they write. If their pay has slipped behind the market for their skills, correct it in the same conversation. The resigned-tomorrow test is a quick way to run the same check across every team.
