The Generalist vs. Specialist Engineer Argument

This topic comes up periodically and a recent article in Harvard Business Review entitled “Redesigning Knowledge Work” prompted me to re-visit my own thinking on the topic.

Specialist vs GeneralistEvery organization who employs engineers faces decisions about how to structure their roles on project teams. I am specifically talking about engineering organizations that employ a variety of skill sets who come together on teams for a period of months to years to develop highly engineered, standardized products. Some good examples include whether an electrical engineer should not only do architecture and design, but also do PCB layout. Or should the PCB layout be done by a lower-level ECAD employee? How about the more senior mechanical engineers with years of experience? Should they be responsible not only for 3D modeling, but detail drawings as well? I think in most cases the roles just “work themselves out” without any specific decisions being made one way or another. That may be a mistake. Of course, decisions about roles influence formal job descriptions, if used, and impacts hiring and recruiting strategies for new or replacement engineers.

A place to start this discussion is to address a looming issue for all companies who hire and depend on highly skilled knowledge workers, including engineers. The issue is the changing demographics of the workforce in the U.S. and every other major industrialized country. The fact is that the population is ageing rapidly. The “Baby Boom” generation in the U.S.  is nearly retirement, people are living longer, and birthrates are declining. In addition, U.S. universities and colleges are graduating too few engineers to fill long term demand in the U.S. for these skill sets. In the HBR article, a recent McKinsey Global Institute study is referenced that suggests by 2020 there will be a 38-40 million worldwide shortage of highly-skilled, college-educated workers, which translates to 13% of overall demand. Another study by the Employment Policy Foundation estimates that 80% of the coming labor shortage will involve skills, not raw numbers of employees (1).

This has many implications for companies over the medium to long term. They are certainly going to have to change how they view “retirement” and re-structure jobs to allow the mature worker cohort to continue to work, but maybe at a reduced level. There will be more competition for talent for sure. This is all happening at the same time that the basic concept of the “employment deal” is changing. For instance, more flexibility in how jobs are defined, flexible working arrangements, more work-life balance, are all becoming a consideration when people decide who they work for.

forkSo why is this important in the context of the original question? Well, since there will be a shortage of highly skilled workers, then one way to deal with the issue is to focus these existing resources only on activities where they have unique capabilities. In other words, keep your specialist a specialist. That
is really the focus of the HBR article referenced previously. The author comes at the issue from the standpoint of first deciding whether the expertise (e.g. the engineer for the sake of this discussion) represents a source of competitive advantage. If the answer is no, then it might be better to outsource the work or if it is kept in house, then off-load some of the lower-skill tasks to others so that the engineer focuses only on the areas that require his specific capabilities. For instance, that may mean for the EE, he/she would not do PCB layout but that would be performed by an ECAD employee instead.

If the expertise in question does provide a competitive advantage, then the question becomes: do you have enough in-house expertise? If the answer is yes, you may still want to off-load some of the lower-skill tasks from your key engineers to lower cost workers. If you don’t have enough of these skills, then of course you either have to recruit and hire the skills and/or train or develop the folks you already have. I would also maintain this is where you have to think about the mature workers and your company’s view on “retirement”. Is there a way to retain that expertise but accommodate their needs for a reduced work schedule for instance?

While the HBR article does make a good argument for keeping your key engineers focused on their specialty and resisting a generalist role, which also makes sense as it relates to the changing demographics and shortage of these skill sets, there are some counter-arguments that have to be considered.

First, for many small to mid-sized companies, it is just not practical to have roles defined that narrowly. You are more likely to have employees who “wear a lot of hats”, so to speak. I think it will be important in these situations to think about the critical expertise some of these generalist have and attempt to cross-train and develop additional expertise. Second, as the company grows, think about how you might want to change the roles and don’t get stuck in the “we have always done it this way” mode of thinking.

There is something to be said to have more generalists on project teams because it can lead to less hand-offs between resources, and potentially improve the “flow” through the NPD process by reducing the number of ques (2). This is an important concept and I have seen where increasing the number of part time members on a project team can definitely bog down the project. It may be an efficient use of resources, but you may pay a penalty in terms of the project schedule. Reducing the number of handoffs is an important approach to speeding up a project.

Another advantage of the generalist compared to the specialist, is that the generalist usually will have a better feel for how the entire system works, where the specialist may not have as great of an appreciation for the system and system level complexity.

Finally, there are some engineers who may prefer the generalist role vs. a specialist role. They may find a generalist role more satisfying because of the variety of tasks. Of course, the opposite can be true as well.  If there is to be a hard-and-fast rule that certain positions, say EE’s, are always specialists, then you need to make sure that when implementing that rule with an existing group of engineers you understand the implications.

In summary, I believe you should take a more nuanced view of the “generalist vs. specialist” argument. Context will be important, as will the organization culture and the preferences of the employees. There is nothing wrong with considering employees preferences. You may just find that with the changing nature of the “employment deal”, there will be a higher level of employee engagement if you do consider their preferences. More employee engagement is not a bad thing (see this blog post)! A more important take-away from this discussion is to at least consider your key expertise and how you are going to maintain that over the longer term  and be more purposeful and thoughtful in how you define roles.

What are your thoughts and experiences? Do you have examples where defining the role one way or the other was important on a specific project? Do you specifically think about how the roles are defined, or has it just evolved into what it is today?


(1)  See page 9 in particular, but this entire book is an excellent source of information on the looming demographic changes: Ken Dychtwald, Workforce Crisis. (Boston: Harvard Business School Press, 2006)

(2) An excellent treatment of the concept of “flow” in the context of NPD can be found here: Donald G. Reinertsen, The Principles of Product Development Flow. (Redondo Beach, CA: Celeritas Publishing, 2009)



6 thoughts on “The Generalist vs. Specialist Engineer Argument

  1. Good summary. Most of my experience in this area was as Director of R&D in a NASA (and defense) prime. We found that generalists worked very well in R&D, Project Management, and Business Development support (proposals, meetings, sniff-tests). Specialists worked well in design optimization in later stages and under contract with customers, and only consulted/advised in early product development as guidance.

    This worked because generalists could understand whole systems better, be flexible to meet lean/agile/evolving demands, and be understand whole design cost-benefit and strengths-weakness that specialists could not. It also worked to keep costs down and specialists mean lower supply and hence higher cost, which is nicer to have customers pay for instead of eating up internal R&D budget.

    Generalists are also more interchangeable by nature so from an R&D point of view it was much easier to get projects completed as people got tied up with contracts and I could hand off to somebody else. You can’t easily do that with a specialist. They are very complementary, to be sure.

    However, I’m not sure they are also discrete. It’s more of a continuum. You can be a near specialist in one area and a near generalist. At one extreme you devote 100% of your time and effort to one area (specialization), or 10% to ten areas (generalist), or 50% to one area and, say, ~7% to seven areas (mixed).

    I think each company and individual needs to be considered independently without such summary rules. It is better to design both a corporate review process and individual employee development reviews to figure out how to best meet your needs with the people you have or to get other/more people. I’m often wary of attempts to come up with simplified, categorical rules instead of learning to deal with each situation on its own merits.

  2. The term specialist today allows an individual with large amounts of knowledge and experience but no bachelors degree to excel in a “BS required” society. Those degreed generalists would be lucky to have a few specialist working at their side, even though equality will never be established.

  3. Pingback: Measuring New Product Development (NPD) Success | New Product Visions

  4. This is a very interesting article. I’m currently a student looking for what engineering degree would fit best for me. I’m not particularly drawn to one aspect of engineering so the idea of being a generalist is very attractive to me. What kinds of Bachelor’s degrees should I consider if I want to be a generalist? I will eventually get my Master’s but I want a good foundation.

    • Hi Lauren. That is a great question. In my case when I decided to get a mechanical engineering degree (many years ago!), it was based on my general interest in things mechanical and I viewed the degree as a basis for a more general business career in technology manufacturing. I actually never envisioned myself long-term as a practicing engineer. So, if that is what you are talking about, then really any of the engineering degrees would be good. Though I would soul search and decide what you are interested in: mechanical things, electrical, software, chemistry, material science, etc. and focus there. In today’s world, I think electrical engineering with a focus on software, or a computer science degree might be a better choice. Of course in all cases, the first couple years of any engineering degree is basically the same curriculum so you will have some time. If on the other hand you want to be a generalist electrical engineer for instance, than that will really be a matter of picking jobs that will allow you to do that, continually learning new skills. Though you will end up specializing to some degree if you get a masters in that discipline. Within every discipline, like EE, there are multiple ways you can specialize. For instance, some EE’s end up focusing on embedded software. Really no right or wrong way to approach it. I would keep your mind open and explore options to find what works best for you and your interests. Hope that helps.

Leave a Reply

