Skills Roadmap

Step 1 – know where you are. Step 2 – know where you want to go. Step 3 – decide how to get there.

If you read my About page you know that my whole goal in writing this blog is to push myself to improve as an engineer. In order to do that I decided to deconstruct being an engineer into its major sub components. These categories are interconnected, but I think I have found workable dividing lines between them. Feel free to disagree with how I grouped these. I’m sure I will disagree with myself in the future; let’s call it rev 1.

The first five categories cover the basic phases of engineering: researching, design, analysis, prototyping, and testing. You would be forgiven for saying these are everything an engineer does. The last five categories are: communication, documentation, time management, leadership, and business skills. I added these on because they are critical things done throughout the project, and they quite often separate the good from the great engineers.

1. Learning/Researching

Every project involves finding out new information or picking up new skills. When you don’t know something, but think someone else does – it’s time to break out the learning. This category would include things such as finding useful resources, reading for understanding, memorization, note taking, effective practice, etc.

2. Design/Invention

This is an iterative process that is shaped by the other subcategories. The core of it is coming up with ideas or adding detail to those ideas. Skills in this heading would include: brainstorming (individual and group), sketching, CAD modeling, system architecture, requirement prioritization, design for manufacturing, design for inspection, and a host of others.

3. Analysis/Calculations

Engineering is the application of science to make things, and the language of science is quite often math. This is what you learned in school and in many ways this skill is what separates you from all the other disciplines working in the project.

4. Prototyping

This is when you start turning ideas into reality in order to learn things. There is a huge variety of ways to go about that, and most of us find this pretty fun to do. Depending on your industry, some skills will be more helpful than others. Everything from working with hand tools to CNC machining fits in this category.

5. Testing

Every prior phase of the project was pointed at this phase. Testing can range from confirming something you are almost certain of (fit and finish) to finding out things you can’t predict through analysis.

6. Communication

This is one that engineers get a lot of flack for. It is critically important though, because most things worth doing require a team to do it. To me this encompasses face-to-face, phone calls, emails, instant messages, presentations, etc.

7. Documentation

One could argue that this is just a subset of communicating, however, I think it deserves its own place because it entails more than just written communication. There is a lot of process and procedure around this at different companies. Engineers do this a lot, and it is often a major deliverable of the project.

8. Time/task management

This one is obviously critical to the efficiency and effectiveness of an engineer. This involves everything from not forgetting tasks, to prioritizing, to learning when to say no.

9. Teamwork Skills

I believe that leading and following are two sides of the same coin. They are both essential to having an effective organization. Few people only lead or only follow. You need to know how to do both effectively to be a good member of a team.

10. Business skills

It is easy to turn a blind eye to this one. “As long as I met the project requirements then I was successful.” I’ve worked at small companies for too long to believe that. Business is the underlying landscape of everything you do as an engineer. Money is the life source required for engineering. It’s highly dependent on your company and your role how often you will use these skills.

Now that I’ve explained my different categories. I want to evaluate how I stack up. For each category, I’m going to evaluate three numbers: how critical is it to project success, what percent of time do I do this, and how good am I currently. This isn’t very objective, and I don’t expect to be able to track my “progress” over time. This is simply made to be food for thought in choosing where to focus.

Skill GroupHow Critical?% TimeStrengthComposite Score
Learning/ResearchingHigh = 310%Strong = 10.3
DesignHigh = 330%Strong = 10.9
AnalysisMed = 210%Weak = 30.6
PrototypingMed = 215%Medium = 20.6
TestingMed = 25%Medium = 20.2
CommunicationHigh = 315%Strong = 10.45
DocumentationMed = 25%Medium = 20.2
Time ManagementCritical = 45%Strong = 10.2
TeamworkMed = 25%Strong = 10.1
Business SkillsLow = 1<1%Medium = 10.02

The composite score is meant to point toward the most fruitful areas to improve; if it’s important, something I do a lot, and something I stink at – I should start there. Some interesting insights into myself from filling out the table this way:

  1. I rank myself as strong in every category that I rank as critical. Yikes! Let’s just eat some humble pie and acknowledge that probably has some cognitive bias baked right in. Although, there could be something there as well. I do try to put the most effort into the things I think are most important. Or at least I tell myself that 😉
  2. Improving my design skills ranks number 1 in my composite scoring. I spend a lot of time there, and it is very important. However, it is one of the hardest things to improve on since I already have strong skills. Maybe I can look for specific weaknesses within the category and focus on those.
  3. Business skills ranks as last place. So much so that it kind of makes me wonder if I should keep including it. I’ll keep it for now; I have a dream of starting a business someday. Noted but shelved.
  4. This is all variable from project to project. As a consulting engineer it is important that I don’t fixate on the present. Being well rounded is helpful in being able to handle anything that comes.
  5. Representing all of my responsibilities as a string of 30 numbers definitely squashes out the finer detail that is reality. This is a high level view and not the only perspective.

All in all I found this exercise interesting and helpful in evaluating myself as an engineer and thinking about where I want to go. I actually did this once before about 10 months ago. Since then I have picked a lot of the low hanging fruit in ways to improve my design skills. Because of that, I’m going to partially ignore the numbers and focus on the two runners up: analysis and prototyping. I’ll let you know how things go.

Leave a Reply

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