Design, Manufacturing, and Testing are the basic categories for all types of engineering.

It's taken me years, but I now feel that most engineering roles can be broken down into design, manufacturing, or testing. This is probably more applicable to hardware than software, but it's not limited to hardware. To summarize:

• Design - People at the start of the product lifecycle process, who design the thing to meet requirements.
• Manufacturing - People who build the product.
• Test - People who make sure that the product meets the requirements.

To some extent this is a narrow view, because when it comes to things like requirements, there is a market and a business case that drives the whole engineering process. If there was no business case, it's just a hobby and not a business. Why am I writing about this?

2011 through 2018 I was at a company with very developed processes, and rather static hierarchy, which all worked very well for that company. The company was well over 100 years old, so they had a long time to sort out a system that worked well for them. Then I joined the world of startups and young companies, because it's thrilling and an adventure. However, young companies don't have their processes and hierarchy all worked out. 2011 through 2018 I started in analysis (a sub-set of testing) and then moved over to design. When I started in the startup world I started in design, and then moved over to manufacturing. Through several different organizations I now see how the three basics of design, manufacturing, and testing are really the foundation of bringing a product to market. 

A really small company can have the design engineers build the product and test the product, however that doesn't scale very well beyond the first one, not even to 10 total units. So in the world of race cars, Mars landers, and other highly highly specialized, super low volume products it works, but by the time the volumes creep up to something like the Concord airplane or B2 Bomber (about 20 units total), there needs to be division of labor to keep up with any sort of production schedule and make sure that each role is adequately resourced. Some sort of program schedule takes shape and goes something like this:

Design, Manufacture, Test

Obviously that's an overly simplistic representation of a product development process. In today's world, a lot of testing can happen before the final product is manufactured through virtual analysis tools. And of course, the goal is for the prototypes and production to be the same... but of course that rarely happens and leads to a whole other topic of change control. Also left out of this discussion is requirements for the product. The better the requirements are defined in the beginning, the easier this whole process will be down the road. Defining requirements is hard, and frankly, there comes a point where it makes sense to just start designing and building the product prototypes in order to learn all of the formerly unknown requirements.

I once had the experience where the assembly design (and bill of materials) was released/confirmed on a Wednesday and the very next day the expectation was that we would build it... needless to say supply chain had not bought all of the parts to make that possible. I've also been asked in the past why it's hard to build something without a released bill of materials from design engineers, with the simple answer being, if you want manufacturing to buy all of the parts and use all of them in the product, then yes we need a bill of materials to go off of. I've had another example where some test engineers were adamant that the wrong assembly was built, and yet all three physically built prototypes, and the original virtual design, and the work instructions were all in agreement about the particular issue.

In all three examples, people were upset. They felt like they had been failed by their peers, but it was really a misunderstanding of what their peers needed as inputs in order to do their jobs well. Yet going back to 2011, when I was in analysis (testing), I remember saying that a 25 mm steel plate would work in a location, the design guy said nothing, but the manufacturing engineer said that was unreasonable and we needed to figure out how to use a smaller plate, so we did, because we now had a better requirement (no 25 mm thick plates on this assembly), and this all happened two years before prototypes were built. I remember that interaction as something of the gold standard for getting design, test, and manufacturing in the same room, two years before the assembly was first built, and four years before production, so that when we went to production that particular assembly was very smooth.

The general flow of engineering information.

And again, this image is a simplistic understanding of engineering. However, for the purpose of this article, this is really about organizational structure, schedules, inputs and outputs. It's not possible to do everything at once. Many things can be parallel pathed but you can't drive a car without wheels. You can't drill a hole without a tolerance. You can't weld two plates together if you don't know the materials. Hopefully this small overview gives non-engineers a little more context into the different areas of engineering, as well as perhaps new engineers information about different roles that I didn't understand until I had years of experience engineering. My advice to new college graduate engineers, get your hands dirty doing a little of all three. It doesn't really matter what you do the first two years of your career, just learn how things are designed, manufactured and tested. You can figure out which part you like best when you understand the engineering industry better.