Building the Right Team for Electronics Design

Ari Mahpour
|  Created: May 19, 2025
Building the Right Team for Electronics Design

Building and growing the right team for electronics design in today’s job market can be quite challenging. We sometimes feel that as our company grows, the talent pool dwindles. We embark on a search for the perfect designers, seeking out individuals who can “do it all.” For some, we idealize this knight in shining armor as a senior engineer, armed with his HP calculator in one hand and electronics textbooks in another. For others, it is the whiz kid who can crank out designs at the speed of light and learns to “fail quickly”. Regardless of who or what this designer appears to be, the important factor we must consider is that our “target profile” isn’t a one-size-fits-all. Our team must comprise of many different ranges, skill sets, and capabilities.

An Army of Clones

Consider a team comprised strictly of whiz kids who blast through those new designs, or only of pocket protector heroes who will not rest until “no datasheet is unturned”. Building an army of clones may yield a systematic and streamlined way to build your group, but it may also come with unintended consequences. Imagine trying to build a team completely out of “fresh outs” who are guided by a single “fearless leader”. One would have to put together rigid systems with traffic cones to keep the junior team on the straight and narrow. This leader would spend the majority of their time checking the team’s work, and the reality is, building a strictly homogenous team is an unsustainable model—as people are naturally different. These types of leaders are getting fewer and farther between.  

Observing the opposite extreme: seasoned veterans close to the end of their careers. Their knowledge is vast, but their careers are coming to an end. Having them focused solely on churning out product after product without transmitting that information to the next generation is a ticking time bomb, exploding after the last employee walks through the door to their retirement. The transfer of knowledge must be taken seriously and set up in a way that fosters that level of collaboration (as discussed in a previous article). This also addresses companies dealing with high attrition rates.

Both of these scenarios are rather extreme. Most people know that the majority of today’s good workplaces consist of a healthy level of diversity. In this Altium blog series, we will be focusing on how to play to each engineer’s strengths, specifically addressing role definition and how that fits in within the Altium Designer and Altium 365 ecosystem.

An Introduction: The Different Types

There are many different types of engineers and personalities, far too many to discuss within this or future articles. To introduce this series, we will cover a few “generic” (though not exhaustive) personalities and characterize them. 

  1. Subject Matter Expert: This engineer narrowly focuses on a specific area of engineering. If all you do is build USB-based products, having someone who understands USB in and out is mighty helpful when trying to do a deep technical dive on protocols or electrical characteristics of USB signals. These are the folks we want focused on application specific circuits or deep dive investigations.

  2. Analyzer: This engineer is an ace when it comes to analyzing circuits and picking out a design for little tiny flaws. This team member will ensure that your products will never fail when they arrive in the customer’s hands, and will never rest until it’s perfect. Their strength is in analyzing your parts and reusable circuits (via managed sheets) and then blessing them for release.

  3. Fresh Out: This engineer usually comes fresh out of school and has a strong desire to dive right in. They’re resourceful enough to be a good self start but need guidance and traffic cones set up to make sure they are kept on the right track. Frequent check-ins with these folks are a must. Have them focus on building generic reusable blocks with the help of the Analyzer.

  4. Architect: This individual has a high-level view of all the moving pieces. They are able to architect solutions and implement the vision of the leader. These are similar to the executives that deliver the “how” as Simon Sinek describes in his book Start With Why. Have them focus on putting together the building blocks (e.g., managed sheets) and don’t let them get bogged down in the details.

  5. Diver: This person loves to dive off the deep end, only to resurface for air when absolutely necessary. They will lock themselves in a room until they’ve solved their problem. You can always count on these people to solve your problem, but don’t expect any status between the start and end. Let them focus on solving specific issues within your design system. Give them bounded projects with concrete expectations.

  6. Leader: This individual drives the “Why” as described in Start With Why. They are able to articulate why we do what we do and enable the architects to implement that vision. They ignite the fire that starts the engine for success. They are the ones who carry the team and challenge them to take it to the next level. You definitely need one of these for every group.

Workflow Assumptions

There are many different workflows and ways in which people work. This can vary by personality, company, culture, etc. In this article, we focus on a module-based workflow, where part of the team creates design blocks, and the others generate a design using those blocks. Additionally, we have characterized six different personality types you might find on a team. In reality, your team may consist of just some or even none of these personality types, so this article is only being used as an example to illustrate how to play to team members' strengths.

Recall the six different team members discussed in Building the Right Team for Electronics Design: An Introduction. They are:

  1. Subject Matter Expert
  2. Analyzer
  3. Fresh Out
  4. Architect
  5. Diver
  6. Leader

Using a Venn diagram of the two groups, block producers and block consumers, we can categorize each team member as a producer, consumer, or both.

Venn Diagram showing block producers which contain the analyzer and the diver on one side, block consumers which contains the architect and the leader on the other side, and a shared area containing the fresh out and the subject matter expert

Figure 1. Depiction of team members and their roles with respect to block production/consumption

The producers are the ones who build each circuit block into a Device Sheet or Managed Schematic Sheet within a Hierarchical Design. For an optimal workflow, I recommend a Managed Schematic Sheet using Altium 365, as it performs all the release cycling for you, enabling you to distribute the workload across the team. Consumers are the ones who are taking these design blocks and dropping them into their designs. Both groups depend on each other, and in this environment, the team thrives when they are able to focus within their realm.

Two Buckets: Producers and Consumers

We’ve taken each type of designer and intentionally classified them as a producer, consumer, or both. We do this to utilize them at their maximum potential. Here is a quick summary on our classification for each archetype.

  1. Analyzer: The analyzer’s strengths lies within working through the details within the design blocks. For this reason we want them focusing on reviewing every detail to make sure that block is perfect.
  2. Diver: Divers love going deep into a project, and as a result, they should focus on getting into the details of block building. Focusing narrowly on how to create the block (versus how to use them) makes the most use of their abilities.
  3. Fresh Out: The fresh out is usually a junior engineer with limited experience or someone who just finished school. They still have not figured out whether they want to be a producer or consumer of blocks. It is important to give them the opportunity to experience both sides, which is why we place them in the crossroads between the two. They can learn how to build hierarchical designs by producing blocks, but at the same time, create some of those blocks themselves. It is important, however, that an Analyzer (or other engineer) review their produced blocks to validate that they can be re-used among the team. This is where the importance of Managed Sheets in Altium 365 comes in. The workflow has been designed for you so your team does not have to spend the time reinventing the wheel.
  4. Subject Matter Expert: Naturally one would expect the subject matter expert to fall into the producer bucket. The subject matter expert narrowly focuses on a specific technology that usually ends up within blocks. In Figure 1, the subject matter expert sits between the two groups. This is due to the fact that the subject matter experts also understand the application of their technology, therefore, it is imperative that they are part of the review and discussion process of the block consumption. Questions, such as how to use that circuit and the application of that technology can sometimes only be answered by an expert in that subject.
  5. Architect: By the title of these folks,it is clear what their role is: to take each block and architect it into a masterpiece. These engineers understand the high-level function of a design and can easily see the forest for the trees. These individuals should be focusing on their biggest strength: architecting.
  6. Leader: The majority of the time, leaders are not involved in the design, but when they are it is important that they focus only on the high level details (similar to the architect). If they get bogged down in the weeds then they may not be able to focus on what is more important for the group and company as a whole. Playing to their strengths, leaders should be focusing on the block consumption rather than the block production.

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.

Embedded Electronic Pieces & Engineers
Figure 1. The pieces and people that make up an embedded electronic product

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. 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. 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

In this article, we discussed the concepts of block production and consumption with respect to hierarchical design. We evaluated each engineer type presented in Building the Right Team for Electronics Design: An Introduction and placed in with the appropriate block bucket. After understand where to place each team member and how to play to their strengths we can start to develop a solid process on how to recruit, build, and grow our design engineering team to its fullest capabilities.

Would you like to find out more about how Altium can help you with your next PCB design? Talk to an expert at Altium and learn more about making design decisions with ease and confidence. 

About Author

About Author

Ari is an engineer with broad experience in designing, manufacturing, testing, and integrating electrical, mechanical, and software systems. He is passionate about bringing design, verification, and test engineers together to work as a cohesive unit.

Related Technical Documentation

Back to Home
Thank you, you are now subscribed to updates.