Is Specialization Good For Hardware Development?

Last night I started reading “The Machine That Changed The World”. It’s a book from 1990 that I’ve been meaning to read for a couple years that documents the rise of lean production through the 1900’s at companies like Toyota. The second chapter called The Rise And Fall Of Mass Production foreshadows a point on specialization that is discussed in detail (I’m assuming) later in the book. I thought it was interesting enough to post here for opinions on how it may or may not apply to specialization in hardware development.

From page 31 of The Machine That Changed The World, this is part of the last paragraph in a section that describes specialization of the skilled workforce in a mass production system:

As time went on and engineering branched into more and more subspecialties, these engineering professionals found they had more and more to say to their subspecialists and less and less to say to engineers with other expertise. As cars and trucks became ever more complicated, this minute division of labor within engineering would result in massive dysfunctions…”

What if we mangle that last sentence to apply to hardware development?

“As [systems become] ever more complicated, this minute division of labor within engineering [will] result in massive dysfunctions.”

Does that comment make sense when we take count all the people required to put a piece of hardware together? I can think of systems engineers, design engineers-digital and analog, functional verification engineers, physical design engineers, software developers, support and application specialists, tech-writers and various layers of management. I know I’m missing others.

Some specialization is necessary, but how much is too much? Do you see massive dysfunctions arise from specialization in hardware development?

-neil

One thought on “Is Specialization Good For Hardware Development?

  1. Neil,

    I believe it is too much. I can clearly see from my experience that extreme specialization leads to functional silos and limits accountability. However having only generalists doesn’t work neither. I think you need to be expert in your domain, but be able to understand and as well perform the tasks in other areas. Only this can lead to high-performing team with a “one for all, all for one” mindset.

    Looks like I need to add this book to my reading list as well 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.