An IoT device maker runs on two clocks. The mobile app and the cloud backend can ship a change by Friday. The device cannot. A new board spin means fabrication and assembly lead time. A new enclosure means tooling. A radio or antenna change may mean fresh testing and certificates before a unit can be sold. Firmware sits in the middle, asked to release as often as the app while the hardware beneath it changes slowly. The IoT device makers page lists this as the first strain for these firms.
Symptoms of two clocks
- The app team builds a screen for a sensor that the next engineering build does not carry.
- Hardware engineers first hear about a planned feature at the sprint demo, too late to change the board.
- Firmware engineers are asked for an over-the-air update every sprint while chasing bring-up on a new spin.
- Reviews turn into each team explaining why the others are late.
- A field return arrives, and nobody can say whether the fault sits in the board, the firmware or the backend.
Where the two calendars collide
- Antenna tuning and radio pre-scans that cannot start until the enclosure plastic is frozen.
- Battery-life budgets that rule out a feature the app team has already designed.
- Provisioning keys and device certificates that firmware, cloud and the factory jig must all handle the same way.
- Bootloader and flash partition layout that cap how large an over-the-air image can grow.
- Staged rollouts that need someone on call when a cohort of devices fails to reconnect after an update.
- Board spins whose fabrication and assembly lead times swallow two or three sprints.
Each collision is predictable months ahead. The trouble is that each one is visible to only one team until it lands on another.
The cost of running out of step
Wasted work comes first: features built for boards that then change, or boards spun for features that were dropped. Delay comes second, as each team waits for another with no shared date. The third cost is people. Firmware engineers caught between calendars burn out. App developers whose work stays blocked for months leave for pure software firms. Hardware and RF engineers, who are hard to replace, feel unheard.
How the clocks drift apart
Many IoT firms begin with a founder and a few engineers who did everything together. As teams grow, each discipline adopts its own rhythm: sprints for software, EVT, DVT and PVT build phases for hardware. Nobody owns the join between them. Roles were never written, so it is unclear who decides when a feature waits for a board. Pay and titles grew case by case, so disciplines compare offers and feel the gap.
Five habits that set one rhythm
- 1
Publish one milestone calendar
Hardware build phases, firmware freezes, app releases, certification slots and pilot shipments on one shared calendar. Each lead updates it, and it is reviewed every fortnight.
- 2
Hold a joint review before each hardware build
Hardware, firmware, cloud and app leads agree what the build must support and what waits for the next one, with the battery and power budget on the table.
- 3
Write roles across disciplines
Descriptions for hardware, firmware, cloud, app, test and field support, including who decides when a feature depends on hardware.
- 4
Name one owner per device
A product owner for each device settles trade-offs between teams, so arguments end in a decision rather than an escalation to the founder.
- 5
Explain every change of priority
A short written note on why the plan changed and what it means for each team, sent before the news travels by corridor.
The calendar and the joint review also show when hardware or firmware capacity will run short, so they belong in workforce planning for IoT makers. Writing the roles is covered under role design for IoT device makers.
Pay, titles and hiring across disciplines
App developers can compare offers from software firms every week. Hardware, RF and low-power firmware engineers are fewer and slower to hire. Put every discipline on a visible grade path, so people can see how they grow without leaving. Open hardware searches early, since a vacancy can take months, and keep software hiring steady rather than in bursts after each funding round. The hiring side is covered by recruitment for IoT device makers.
Where to look first
- Which teams depend on which for the next release, drawn on one page.
- Whether a shared calendar exists, and when each lead last touched it.
- Who decides when a software feature waits for hardware.
- The pay gap between software and hardware engineers of similar experience.
The hub for electronics and connected-device firms places IoT makers alongside PCB and EMS shops, and keeping IoT engineers covers retention once the clocks agree.
