How Embedded Teams Can Cope With A Remote Workforce

I've always been torn about rooting for a remote workforce. On the one hand, the ability to recruit the very best people no matter where they live is a huge win for any company. Not to mention it helps smaller companies stay competitive by allowing them to hire top-notch talent by looking in places that don't have the same cost of living as SF or NYC. And for employees who are always struggling to find that elusive work-life balance, it allows you to look much farther and wider than ever before to find that perfect spot you can call home for you and your family without sacrificing your career options.

But on the other hand, I really love the camaraderie and friendships that are built when you work closely with a group of people who share a space together. I also think that for hardware teams there's a competitive advantage to having a team co-located, because so much of hardware development is hardware debugging. And being able to debug a physical device with a colleague who is standing right next to you is typically much more productive than with one who is beaming in via satellite link.

Of course, then COVID-19 happened. And it became abundantly clear to me that a remote workplace is definitely a net good. That said, for hardware teams this is still a particularly challenging problem. Because even though humans have gone online, in a manner of speaking, the physical devices we're developing still exist in the physical word. One way teams have attempted to solve this problem is to give lots of money to FedEx and UPS. This works, but it feels a lot like using pigeon's to communicate via TCP/IP, but with hardware. There's a lot of lost time and money in shipping your hardware all over the world.

On the surface, this seems like a perfect scenario for technology to disrupt the status quo.

One solution would be reliable (and usable) Device Under Test (DUT) simulators for all the different MCU's, peripherals and other circuitry that is found on a modern embedded device. Kind of like what Apple has done for iPhone development. But unless I'm missing something, it seems like something that is usable "right out of the box" for embedded developers is still on the distant horizon.

A second solution would be to figure out how to give embedded engineers full access to the physical hardware from anywhere. In other words, completely de-couple where an engineer is located from where the hardware is located. This is definitely an attainable solution. One could quickly sketch out a system that consists of some combination of a local (to the DUT) linux machine, cloud service, and host client. However, building such a system requires expertise in a number of different technologies, not to mention the long term-up upkeep necessary to keep it functional. For most companies the time and money required to implement a robust solution is prohibitive from even trying.

A third solution (although really it's just a riff off of the second solution) is for a company to productize the technology and infrastructure required to geographically de-couple engineers from their hardware, and then offer that as a service, a la Zoom, GoToMeetings, Skype, but for hardware instead of humans. And yes, technologies like Team Viewer already exist, but these are heavy weight applications aimed at remote desktop sharing. What's needed is a lightweight solution that allows you and your team to quickly scale up from a single DUT connection to a dozen connections. It should also seamlessly integrates into your existing toolchain. Connecting and working with your remote DUT should feel almost identical to working with hardware that's sitting on your workbench.

I think adopting such a technology will take time, especially on the trust side. Getting comfortable debugging something remotely after a career having done it in person will take some getting used to. But if such a technology can deliver on its promise, then pretty soon we'll have a whole generation of  engineers who grow up in a world where doing a board bring up from a coffee shop, even though the board itself is a thousand miles away, will be the status quo.

Want to stay up to date on the future of firmware? Join our mailing list.

Section
Chapter
Published