Leading a Team for Embedded Electronics

Putting together a team, and the infrastructure to support embedded electronics design, requires an understanding of how every part works and how they interact. In this article I want to talk about how to build that team and provide some insight on how to build the infrastructure necessary for your product development.

Definition: What are the different parts

Designing an embedded electronic product requires pieces from different facets of engineering. To build these products we need to bring in people from different disciplines to work together. Let’s identify what these pieces are and who are the people that create them.

Make Cross Functional Platforms - Not People

There are those who make the case for hiring a single engineer to perform the task of all the people listed above. It is absolutely true that there are individuals out there who can perform all those functions. There are engineers today who understand enough detail across electronics, software, and mechanical engineering to design an embedded electronic product from the ground up. Believing you can build a team consisting only of jack-of-all-trades embedded electronic unicorns, however, is a pipedream. As discussed in Building the Right Team for Electronics Design: An Introduction it’s difficult to staff a team of these folks and you lose out on your super deep technical divers. Rather than having everyone do everything I propose building a system that will capture “everything” in the same place so the collaboration between people from two different backgrounds happens just as seamless as if they were one. The benefit to this is that you will get two deep divers (which can be easier to staff in some ways) yet still fulfill the project requirements to design and build what you need. In Flattening Your Workflow: A Guide to “Flat” Style Project Management, I briefly covered the concept of using a tracking system that keeps everyone collaborating in a single place. Each type of engineer has their favorite toolset. The Atlassian tool suite, the product demonstrated in the majority of my articles, originated with Software Engineers. From the time they first released Jira until today, their customer base has broadened out to many different fields. It seemed like a natural fit for our team to extend it to PCB Design as well. The tools that you use is immaterial so long that everyone is able to work and collaborate out of the same place. Adopting a system that maintains a single source of truth engineers is key to the success of this type of product development.

Architecting for Success

We’ve established that your team will mostly consist of people who will be expert electronics designers, software engineers, etc. One cannot expect, for example, that the software engineer understands the electronics enough to architect that piece of the design. A mechanical engineer, as another example, may not know all the details that go into printed circuit board design. For this reason we’ve established in our team two camps in the design process: the architect and the builders. In Building the Right Team for Electronics Design: A Deeper Investigation, I discussed the concept of block producers and consumers. There are those that design the building blocks and there are those who put them together. When architecting a complicated engineering system consisting of a multi-disciplinary team it’s important not only to get those building blocks designed correctly but to also understand where to put them and how to fit them all together. It would be good practice to have someone who understands the higher level to do most of the architecting. I am not making the case for a bottleneck - I recommend having multiple engineers on the team who can architect and design some pieces as well. For example, I may architect a design that consists of some complicated electronics, embedded software, and challenging mechanicals but I won’t design the whole thing myself. I may take pieces of the software and other parts of the schematic capture but the bulk of the PCB design, simulations, or mechanicals will be done by other engineers. I will also make sure to capture all the requirements and design details in one place. This ensures that everyone is working off a single source of truth and that there is no confusion on who’s doing what.

Conclusion

Designing embedded electronics requires a multi-disciplinary team of engineers to work together. Having a process or system that keeps all the design requirements and collaboration promotes success for design. In this article I laid out some guidelines on what has worked for my team and how we collaborate together to design these complicated systems. While these guidelines may not be a one-size-fits-all the key takeaways can be extended to your team and workflow.