February 2021 - Edition 22, Engineer Skills


Vaccines are being distributed and schools are reopening. Either we’re at the verge of not having to make every decision based on COVID risk or it’s about to go downhill again. Regardless of which is occurring, life and work must go on.

Demetri's Corner

For those that don’t know, I caught COVID since the last newsletter. In many ways it’s ironic given my interest in how to prevent spread. In my case, the most likely culprit is that the virus was spread to a family member in the hospital which led to my infection. Luckily my experience wasn’t terrible, but I was tired for a long time and had nagging headaches. I never had respiratory issues or a fever though. I’m fully recovered and supposedly I have some anti-bodies, so time to go out and party! Just kidding. You know how I feel about that sort of selfishness.

I’ve had a lull in work between contracts – nothing concerning, just normal down time associated with being an independent contractor. During this time I’ve been reflecting on where I want SES to be in the future and where I am right now. For SES to become that premier prototyping facility, at some point I’m going to have to make something for a client. I don’t have the facilities, but I’m itching to get my hands on some equipment and get back in a shop.

That led me down the rabbit hole of planning out the priority acquisitions that will allow me to make something useful with a minimal investment of equipment that will have long term value. What I also realized is that I’d likely be doing most of the work myself at first, and it’s been a couple of decades since I welded or machined anything. The first point is going to be reserved for a future discussion, but the latter is what I want to talk about today. Engineers need a wide variety of skills and knowledge of all adjacent disciplines. Too often we consider those disciplines and skills secondary to the analytical aspect of the work, often with dire consequences.

Today's Subject - Engineers Need Skills

This sounds like engineers have some special skillset that makes them good at their job. The challenge is that almost every engineer needs a different skillset dependent on what they do. There are various levels of skills which I will separate into proficiency, competence, and familiarity. When engineering skills are discussed, it’s usually about those that are in the proficiency category. They are the foundation of what we do – knowledge of how to use math and science to logically solve problems. But to extend the utility and effectiveness of an engineer, the skills of adjacent disciplines must also be part of their toolbox. The level of that skill will be dependent on the organization, type of work, and many other factors.

We need to make a discrimination between the type of engineering work being performed. Engineers generally fall into one of two categories – those that analyze and recommend improvements to existing solutions, and those that create solutions to new problems. For this newsletter I’m going to focus on the latter type of engineer as the examples are more concrete, but the discussion is equally valid to the former. To highlight that point, I’ll provide a quick parallel discussion at the end of the newsletter.

Our Example Engineer

Examples will be centered around a specific engineer and job description to highlight the types of skills required. I’m going to consider the extreme version of a design engineer – one that works in a small prototype facility using the latest manufacturing technologies.

This engineer is relatively new and does the following things regularly: define design requirements, component design, and performing acceptance testing.

Proficiency Skills

These are skills that can be learned just by going to college and working as an engineer. No special effort should be required for an engineer to gain these skills. An engineer not competent in these areas isn’t very valuable to a company. These skills break down into the broad categories of engineering process, and technical capabilities.

Engineering process includes all of the menial stuff we know takes most of our day. It’s often tedious, but without the process and associated discipline, outcomes are mostly a best guess. This includes design specifications, determining critical characteristics, defining and evaluating quality requirements, and documenting designs. We rarely learn this stuff in college, but just working with other engineers will result in unavoidable contact with this knowledge and learning through osmosis. It’s really just up to the engineer to pay attention.

Technical skills are mostly learned in college, but are expanded as an engineer gets experience. This includes the ability to do solid modeling, perform analyses, and program. The variety of technical skills will depend almost entirely on the engineer’s industry, the tools the company uses, and specific job functions.

Our example engineer is studious and pays attention, so all of the engineering process skills will be fairly well mastered within a few years. This engineer will also be doing a lot of solid modeling, machine design, and structural analysis. Within a few years, they will be fluent in several associated software packages and experienced in associated methods of analysis.

Competence Skills

These are skills that an engineer should be able to perform, but perhaps with low efficiency or fluency. Which skills are required will depend on the type of engineer, the things they are working on, and the environment where they work. To know if you are competent at something, you have to ask yourself, “If I was abandoned on a desert island, would I be able to do this and have an acceptable (though perhaps not optimal) result?” In many cases an engineer has to seek out opportunity to learn these skills, but the normal interfaces with people proficient at these skills provides the needed opportunities. Extra training or direct experience should be encouraged by the company. An engineer that has collected many of these skills can be a valuable asset due to their flexibility as this increases the utility of the engineer.

For our example engineer these skills include project management, computer coding, quality assurance, and electrical circuit analysis. They may not be regularly asked to perform these tasks, but they are a regular part of the conversation in projects. In some instances, this engineer may be asked to check a calculation or fill in a capability gap for a time-critical design associated with these skills. As the engineer progresses in their career, these are the skills that will determine the rate and direction of growth.

Familiarity Skills

These skills are almost entirely driven by the interest of the engineer. Normally a company would not take an interest in fostering skills that an engineer may never use, so the engineer must seek them out. These skills are probably more important than competence skills for a design engineer as they represent the end of the manufacturing line, such as machining, welding, and fabrication. A strong familiarity with these skills improves the output of the engineer and reduces high-risk rework. In many cases the engineer will not have the access to the equipment or expertise necessary to acquire these skills, so this must be taken into consideration. A proactive company will gage the interest of its engineers and provide opportunities through training and partnerships with other companies when possible to foster familiarity. These skills make engineers better by understanding the entirely of the universe that interacts with their work. These skills make an engineer more effective.

For our example engineer, manufacturing skills as discussed above are pursued on their own time – during self-directed learning, after hours, or as a hobby. This engineer goes to the shop floor and asks for opportunities to perform non-critical welds, participate in a practice sessions with machinist, and create some tool path code and ask the machinist to check it.

Parallel with Analysis Engineer

Since the examples have all been about the design engineer, it’s hard to see the parallel of the analysis engineer. I was just such an engineer for the majority of my commercial engineering career and can attest that this is equally applicable. For this brief discussion I’m going to use a young version of myself as an example.

When I first started out my primary function was to perform safety analyses for commercial nuclear power plants, specific to water hammer evaluations in safety injection piping. The proficiency skills included the use of hydraulic analysis software, knowledge of fluid dynamics, ability to interpret prints, and define simulation scenarios. These skills were needed just to get the work done. I could do them without any assistance and got pretty efficient.

I also happened to be competent in project management, SolidWorks, ANSYS, and MATLAB (to name a few). These skills were regularly tapped into by the company for checking, temporary assistance, or the ability to take on more work than would otherwise be possible. It also defined my future at the company as a project manager and checker of mechanical designs. I also got opportunities to work in industries other than the commercial nuclear power industry because of these skills.


I retained and grew my familiarity with manufacturing and nuclear plant operations. This led me to regularly monitoring the latest trends in machining and fabricating and reading through nuclear plant procedures and regulatory submittals. Though not directly applicable to my work, this familiarity improved my ability to read drawings, aid in determining design manufacturability, and improving my communications with plant operators. This resulted to better and more efficient output of engineering products.


Engineers need to have various levels of skills to be the best at their job. This is probably true with most professions, but I know specifically about this one. At a minimum you can avoid mistakes that make you look foolish, and optimally you can significantly increase the quality of the end product. Optimally you provide greater value than the sum of your training, able to integrate your deeper understanding into more complete and viable solutions. It is difficult to justify the time and expense in acquiring these additional skills until we look back at our efficacy as engineers and realize the important role our broader knowledge plays in how we solve problems.

Dose of Aphorisms

This newsletter was about skills, but more importantly about constantly learning. It’s easy to learn the things that are “part of our job” as it’s almost unavoidable. The real challenge is extending your knowledge beyond the direct product you produce so that product can be even better. It’s hard to quantify because a design engineer without welding experience can successfully design a weldment. But a design engineer with welding experience will probably design one that they’d be willing to weld – a big difference, but not one that would be evident until it makes it to the shop floor.

What this really means is that you never know what knowledge is going to come in handy. Take the opportunity to learn at every stage. Stay curious, humble, and thirsty for information.

A day without learning something new is a day wasted.

Explanation of Fields in the SMARRT form submission

Reference Scenario Inputs:

Number of People Infected – How many potential members of the gathering are infectious. The simulation starts when they enter (time=0).

Type of Activity – Impacts the number of particles spread as aerosols per respiration. More strenuous activities result in more viroid particles being released.

Air Changes per Hour – This is the air exchange rate with fresh air for the volume of air being breathed by the gathering. If you use forced air exchange, you can calculate the number of air changes per hour for your specific situation.

Space Floor Area and Ceiling Height – These are used to calculate the total space volume.

Duration Infectious Person is Present – This is how long the infectious person stays in the space after their initial entry. For the reference scenario, this defines the end of the simulation.

Gathering Scenario Inputs:

See the reference scenario for all inputs up to Time of space entry.

Time of space entry and exit – These values represent when you enter and leave the space referenced to the infectious person. For example, if you show up fifteen minutes late, but stay an hour after the end of a one hour party, the Duration Infectious Person is Present is 60 minutes, the Time of Space Entry 15 minutes, and the Time of Space Exit 120 minutes