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