When Your Hardware Team Is Also Your Software Team
Most embedded teams do not have the luxury of specialists. The engineer who routed the power tree last week is the same person reviewing pull requests this week, and possibly the same person who will be on a call with the contract manufacturer next week about a component substitution. On paper, an org chart might show separate hardware, firmware, and software roles. In practice, on a lean team, those roles often live inside the same two or three people.
That reality changes how architecture decisions should be made, but it rarely gets talked about the way BOM cost or performance specs do.
The Real Cost Isn’t the Task, It’s the Switch
Context switching has a cost that shows nowhere on a project plan. An engineer who spends the morning debugging a DDR timing issue on the scope is not in the right headspace to review a driver update that afternoon, even if both tasks are technically “on schedule.” Every time a hardware problem pulls someone back into layout or signal integrity work, it’s not just their time that gets spent. It’s the momentum on whatever software or firmware work they were supposed to be doing instead.
On a large team, a hardware issue stays a hardware team problem. Software keeps moving because someone else owns it. On a small team, a hardware issue becomes everyone’s problem, because there often is no “someone else.”
Small Teams Don’t Get Small Problems
This is the part that catches teams off guard. A five person embedded team does not face five person sized technical challenges. DDR routing, power sequencing, and Linux bring up are just as demanding on a small team as they are on a fifty person team. The difference is that the small team has no one to absorb the disruption when something goes wrong.
If a board respin is needed, the same engineer who is supposed to be finishing the application layer is now pulled into reviewing new gerbers. If Linux bring up surfaces a hardware bug, the software roadmap slips right along with the hardware fix, because it’s the same person’s calendar. There is no parallel track to fall back on. There’s only the one track, now running behind.
Why Lean Teams Are Rethinking Architecture First
This is pushing more teams to make architecture decisions differently than they used to. Instead of asking “what does this cost per unit,” lean teams are increasingly asking “how much of my team’s limited hardware bandwidth does this design require, and for how long.”
That question changes what looks attractive on paper. A processor and memory system that requires custom DDR routing, a multi rail power design, and weeks of signal integrity validation isn’t just a hardware cost. It’s a claim on the only hardware engineer the team has, for however long it takes to get right, plus whatever time it takes to fix if it is wrong the first time.
This is part of why SiP (System-in-Package) designs have gained traction with smaller teams specifically. A SiP does not remove the need for hardware expertise entirely; someone still has to design the board, select the right variant, and bring the system up. What it removes is the open-ended part of the work: the DDR routing, the power tree design, and the BGA level signal integrity validation that a from scratch processor design would otherwise require.
Octavo Systems’ OSD32MP15x is one example built around this exact problem. It takes the STMicroelectronics STM32MP1 (dual Cortex A7 plus a Cortex M4) and integrates the DDR3 memory, the STPMIC1 power management IC, EEPROM, oscillators, and more than 100 supporting passives into a single 18mm by 18mm BGA package, the same footprint as the processor die itself. A team working from the OSD32MP1-BRK or OSD32MP1-RED reference platforms starts from a validated design and an open source Linux image, instead of a blank power tree and an unrouted DDR bus.
For a lean team, the value of that is not measured in board area saved, it’s measured in what the hardware engineer gets to do with their time instead. Less time spent re proving that a power sequence works, more time spent on the parts of the product that are actually unique to it.
The Real Advantage Isn’t Fewer Parts, it’s Fewer Interruptions
A smaller BOM is nice. What actually protects a small team’s schedule is fewer moments where a hardware problem reaches across the table and pulls a software engineer off what they were doing. The teams making the smartest architecture calls right now are not just optimizing for cost or performance. They are optimizing for how many times their own people get interrupted between now and launch.
Curious how much hardware bandwidth a SiP based design could free up for your team? Talk to an Octavo Systems engineer
