Here’s a question we answered in the Interrupt Slack channel after the From Concept to Launch: What It Takes to Build and Ship a New Device panel discussion. We’re sharing the answer on our blog to make it available to a wider audience.
First, I want to provide context for this question. During the discussion, I pointed out a common hurdle that teams building embedded devices face.
Building and shipping an embedded system requires coordinating efforts across several disciplines: mechanical, electrical, firmware, backend servers, application software – just to name a few. You can’t ignore any of these factors if you’re going to ship successfully.
The challenge is that the leadership for an embedded product, especially at an early stage company, tends to be biased in one of two directions. These biases result in situations that I’ve repeatedly witnessed in my career.
- Hardware-focused (whether a mechanical or electrical engineer)
- Hardware development and build dates drive the schedule.
- The highest priority for the firmware team is validating the hardware design and writing manufacturing firmware.
- The schedule and development plan neglect software-related activities like customer software development, security, backend infrastructure, OTA updates, fleet management capabilities, etc.
- When the software team keeps pointing out that they need 6 more months to get their work done, they are accused of sandbagging or slacking.
- Software-focused
- Customer software development drives the schedule.
- The schedule and development plan neglect hardware-related activities, like the NPI process, manufacturing firmware/tests, calibration, reliability testing, certification, IQC, lead time for parts, lead time for tooling.
- Prioritizing aspects like device size + appearance, without considering factors such as manufacturability, repairability, thermal performance, or difficult miniaturization efforts.
- When late changes to the hardware design lead to lengthy delays (e.g., because of tooling or component lead-times), the hardware team is accused of sandbagging or slacking.
Ultimately, it doesn’t matter which end of the spectrum you’re on. It is difficult to get a product across the finish line when leaders aren’t focused on the integrated system. That’s simply the minimum requirement now.
On to the question:
The Answer for Leaders
If you’re in a cross-functional leadership role, it is important to have a high-level understanding of each aspect of the system development effort you’re responsible for. You need enough to know enough to:
- Understand what the risk areas and the open questions are, so you can drive the team toward addressing those (instead of letting them drag on)
- Ensure that critical steps aren’t being missed
- Ensure tasks are sequenced in the right order
- Recognize when the team is spinning their wheels or heading in a fruitless direction so you can intervene
If you’re an ME or EE, here’s what I think is important to understand about software development:
- What general components/capabilities/processes need to be developed on the software side
- Both product-specific and the standard aspects we discussed in the discussion: OTA updates, security processes, manufacturing firmware, test plans, release processes, etc.
- The relationship between firmware/applications/backend servers, and what the responsibilities of each are
- Gating/sequencing in the different components/capabilities to be developed
- A sense of the ballpark effort/scope for different capabilities/features/components
- 1 week to develop a driver? Sure, that could work.
- Leaving the manufacturing firmware to be handled 1 week before the build? Smells like trouble!
- What can/should be built internally vs purchased off-the-shelf vs outsourced
- The interplay/tradeoffs between software and hardware in an embedded system
- “We can do/fix that in software” is not always the right answer, even if it’s the default answer people reach for
For an opposite example: as a firmware developer and EE, I cannot do any actual mechanical design. I still know the high level details and risk areas to look out for,
- I have a basic grasp of the overall design process, machining, tooling, printing, etc.
- I understand how long it takes to produce custom tools and when designs need to be locked so we can get parts delivered in time for builds/MP
- I know to make sure material arrives at a build event early enough to account for IQC processing
- I know that we better have a “fit check” and review tolerance stack-ups
- I’m aware of the relationship between mechanical-electrical-software for thermal performance of the system
- I’m aware of the tension between PCB size/component selection/final form factor
- I know that the mechanical design needs to be assembled on a manufacturing line
- I know repairs occur, so ideally you’ll have a design that minimizes unnecessary attrition in components
Experience matters to a large degree. The more problems you’ve seen, the more you know to account for. Whether you’re a leader or not, pay attention to the activities going on around you. Read the status reports. Listen during the meetings. Connect with team members in other disciplines. Keep tabs on problems and their solutions. There is always something to learn. Over time, you’ll build an understanding of other aspects of the product development game, as incomplete as it may still be.
But we can’t know everything, of course. Ideally, you’ll have experienced people on your team you can rely on and learn from. If not, you need to find them or get people trained ASAP!
Barring that, I think it’s useful to gain exposure through webinars and books and conferences (like you’re clearly doing). I have friends in other roles, and we often pick each other’s brains. I also pay advisors whenever I need help/insight outside of my expertise.
Listening to your team cannot be emphasized enough. I have been in so many situations where my input has just been disregarded because it is unhappy news for the schedule. Doesn’t change the facts of what has to get done, however…
Recommendations are welcome!
References
- From Concept to Launch: What It Takes to Build and Ship a New Device
- Building an Embedded Organization
- A Look at Ten Hardware Startup Blunders, Part 3: Team
When the leadership team sets the schedule without input from the actual engineers doing the work, and the hiring takes longer than expected, the new engineers that join the team are immediately put under pressure. The firmware is almost always “late” by the time the first engineer joins the team, and everyone else on the team is anxious to see the system working. This situation leads to conflicts, cutting corners, unhappy engineers, and delayed releases.
- The Important Problems in Our Field