In an embedded systems company, a design is more than its files. The schematic shows what was built. It does not say why a second LDO regulator appeared on revision C. Nor does it say why the ADC is sampled by timer-triggered DMA, or which silicon erratum the startup code quietly dodges. That reasoning tends to live with one firmware lead or one board designer. The embedded systems companies page lists it first for design houses of this kind, and it threatens customer releases more often than any other strain.
Signs the design lives in one memory
- A meter maker asks for a small change to a board shipped two years ago, and only the original designer can say what else it touches.
- A new engineer spends weeks reading code because RTOS task priorities and watchdog timings are written nowhere.
- Bring-up of a new spin stalls on a Saturday because one person knows the power-up sequence and which rail browns out first.
- The firmware lead never takes leave in the month before a release, every release.
- Design reviews happen, but the same senior reads everything, so nobody else has seen the whole board.
What a firmware lead carries unwritten
- The linker map and memory budget, and which buffers can grow without overrunning the stack.
- Clock tree settings, DMA channel allocation and the reason one peripheral runs from a separate oscillator.
- Watchdog timeouts and brownout thresholds tuned after a field failure years ago.
- The CAN message IDs or Modbus register map agreed with the customer by email.
- EEPROM wear-levelling, factory calibration constants and where production test writes them.
- Debug-port lock fuses, and the order in which the factory jig must set them.
Each of these took days to settle. Each would take a newcomer days to rediscover, usually under deadline.
None of this is the engineer's fault. Small teams facing fixed customer dates take the quickest route, and the quickest route is asking whoever knows. Over three or four years that habit concentrates the whole design in one head.
The bill for single-head designs
The visible bill is a slipped release when that person is away or leaves mid-project. The hidden bill is steadier. Juniors stay junior longer, since they cannot work without the senior. The senior wears out, because every question routes to them. Quotes for customer change requests become guesses, as only one person can judge their scope. And part of the firm's value to a buyer or investor rests on someone who could resign next month.
Why nobody assigns the explaining
Most embedded firms never give anyone the job of explaining. Role descriptions say 'design firmware' or 'design hardware'. Goals count features shipped and dates met. Nobody is asked to make a second person understand the analogue front end or the CAN stack, so nobody does. Grades then reward whoever cracks the nastiest fault, which is often the same engineer who never wrote down how.
Five habits that spread the design
- 1
Keep a module and board ownership sheet
One line per firmware module, board revision, test script and toolchain, with an owner, a named shadow and the date the shadow last worked on it alone. Hold it with the employee records so it changes when people change.
- 2
Book a design walkthrough before every pilot lot
The designer talks the shadow through schematic choices, decoupling and filtering, power sequencing, interrupt timing and known errata. The shadow writes down every gap. The walkthrough sits inside the project plan, not after it.
- 3
Staff each project with a primary and a shadow
The shadow takes real tasks on the module, such as a driver fix or a bring-up step, under review. Rotate shadows across projects during the year.
- 4
Write explaining into roles and goals
The senior's description includes developing the shadow. Their goals include the shadow working alone on a named module by a stated quarter.
- 5
Grade bench and desk on one scale
Grade by what each person achieves unaided, so a technician who can bring up a board with a scope and logic analyser sits fairly against a firmware developer.
For writing the explaining duty into each remit, see firmware and hardware remits. For pricing a shared bench-and-desk scale, see benchmarking embedded engineers' pay.
Four things to look at first
- Which boards and firmware modules only one engineer can explain today.
- Whether the firmware lead has managed five straight days off since last Diwali.
- How long the last two hires needed before changing a module without help.
- Whether schematic and code reviews rotate or always land on the same reviewer.
Keeping the senior while the reasoning spreads
Some senior engineers read this work as groundwork for replacing them. Say plainly that it is the reverse. A senior who can hand a module to a shadow can lead the next product, take a proper holiday and grow into an architect or engineering head. Staged learning for firmware and hardware juniors shows how a shadow grows. Our question post on spreading one engineer's knowledge handles the doubts owners raise at the start.
Talk to the engineer first, then the team. For help drafting the ownership sheet and grades, begin at the requirements page. The electronics hub sets single-head design beside PCB, EMS and sensor pressures.
