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.
Every 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.
So 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 et.al, 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)
New Product Visions is a consulting company that helps organizations improve the effectiveness of their new product development processes. We specialize in small to mid-sized companies that manufacture highly engineered products. Contact us today about how we might help you!
Specialties: NPD consultants, new product development consulting, developing new products, new product development seminars, small business consulting, new product development expert, product development process, new product development strategies, integrating NPD for mergers & acquisitions, organizing for innovation, management role in NPD, project risk analysis