A Simple Over Generalization: The 3 Types of Engineers.

Ryan J. Riker
Silicon Mountain
Published in
6 min readJan 19, 2022
Stars over a hilly skyline
Stars over a hilly skyline

There are many ways to lump things together; almost all of them are gross oversimplifications. I am not saying this isn’t one of them. I am going to say even gross oversimplifications have their uses. In this case we are going to lump people together by their Star Trek Engineering class. I have used this same lumping logic at every level of employment along my career path. What really makes this system pop, no matter the circumstances, is that the categories are pretty readily identifiable pop culture icons. I have found that you can take any person you work with and put them into one of these three categories based on how they answer this question: “So, how long do you think it will take?”

The three Star Trek Engineer classifications are: “The Scotty Engineer,” “The La Forge Engineer,” and lastly, “The Engineer on the Ship That Couldn't Get Those Shields Up in Time.” The last one can be shortened to “The Engineer That Exploded.” If you are a project owner or project manager, once you know what sort of Star Trek engineer you have on your team. You can treat their estimate accordingly, thereby making your own estimates and timelines more accurate. If you are a technical minded person being asked to make an estimate, knowing what sort of Star Trek engineer you are can also help you adjust your estimates. Not to mention, it injects a little fun and levity into what is likely a very boring and some times painful part of the work process.

The Scotty Engineer

So, how long do you think it will take? Reaction to the question: A Scotty will take some time to think about it, give a range as an estimate, and then complete the task in the middle of the estimate, then walk away looking like a hero.

I know the most about the Scotty Engineer, as I think I am one. I will almost never give an exact estimated number of hours or an exact deadline. It will always be a range; depending on the task at hand and how much of it is unknown territory, that range can get very wide. I understand that Scotty in Star Trek TNG (The Next Generation) said he intentionally padded the estimates so he would look like a miracle worker. That’s not what I and other Scotty engineers are trying to do, but the outcome could look the same. I will estimate something along the lines of half a day to two days. Then I will hand the product over to management or quality control in maybe a day. I did rather famously once tell a project manager that the task could take “between 2 hours to 6 months to complete.” That is not the widest estimate I have ever heard. In “The Dilbert Principle”, Scott Adams mentions that its not abnormal for an engineer to estimate 2 days to 5 years. So, there is plenty of evidence that us Scotty Engineers are out there.

My particularly wide answer is really just a very long way of saying, “I don’t know how long it will take.” Now that I know I am a Scotty Engineer, I have gotten significantly better at saying “I can’t give you an estimate right now. Let me do some investigating and I will get back to you.” Then I go back to my desk, make a check list of all the steps to complete the task, give each of them a range of effort or risk and calculate a total range. Once done, I can return to the manager armed with my back of the envelope math and say something much more accurate. Still there will be a range, but the range will be much tighter.

The La Forge Engineer

So, how long do you think it will take? Reaction to the question: A La Forge will take some time to think about it, give a singular estimate, and complete the task very near to when they estimated — no matter the cost.

Scotty Engineers tend to annoy La Forge Engineers. They simply do not accept any level of flexibility in deadlines or estimates. To a La Forge Engineer the task has exactly one correct estimate. The estimates are so singular and precise they will break it down into minutes, such as 3 hours 45 minutes. Often their estimates are based on previous examples of similar work and getting the average time to completion. If there is risk, they will often take the short end of the risk range. Let’s say they look that the task and see that it can take between 2 and 3 days of work to complete. They will assume everything will go perfectly and estimate 2 days. Then if something does go wrong, they will crank up the effort and sometimes burn the midnight oil in order to hit the deadline. La Forge Engineers are easier on project managers and project owners, as they are much more like clockwork. If they say 2 hours, it’s gonna take 2 hours.

If you are a La Forge Engineer, you can find yourself working extra time to keep up with your estimates. Before you hand in an estimate, stop and re-examine the risks and variables. If you catch yourself giving an estimate “because you know how long it will take,” pause and double back to make sure you covered the plan entirely. Rather than relying on burning extra cycles to keep up with the unknowns, you can use that new free time to pick up a trending science fiction series, perhaps?

The Engineer That Exploded

So, how long do you think it will take? Reaction to the question: A Engineer That Exploded will assume the time frame giving to them was an ultimatum, put their head down, start working, and often miss the deadline, sowing disruption and vexation in their wake.

For years I talked about only the first two types of Star Trek engineers. One day it was pointed out to me that I was missing someone very important. One of my colleagues was the first to mention “The Engineer on the Ship That Couldn’t Get Those Shields Up in Time.” It was an interesting twist I hadn't thought of. It worked into the general conversations about scheduling and prediction effortlessly. So I added it.

It’s safe to say that everyone gets to be The Engineer That Exploded from time to time. Not all estimates workout as planned. Having even a modest explosion and earning this title isn’t always all bad; it’s helpful to reserve a small amount of effort to investigate what went wrong. It will go a long way towards learning the lesson of The Engineer That Exploded. Each explosion can help focus your skills. Some people might take several explosions/failures to figure out exactly where they are going wrong.

Sometimes deadlines can feel like acts of attrition. This pressure might be the cause of the failure, or maybe it’s an incorrect assumption. If you have identified yourself, or another, as being The Engineer That Exploded, it’s likely time for some self reflection. Reach out to the others and see what tactics are working for them. Help the project owner understand that if they have a date they need it by, they shouldn't tell you right away. They need to let you make a first pass it calculating how long it will take you to complete the project. If you let the “captain” of the project know ahead of time that it won’t be done when they expect it, perhaps they can change plans and avoid the explosion. I know it can feel like it’s wasting time to put your head down and try and figure out an estimate, but in the end its an invaluable time saver.

What about Barclay?

Star Trek is full to overflowing with engineer stereotypes for sure. In many ways, they are the main heroes of Star Trek and other science fictions shows. So why select only those three? When I look at the other Star Trek engineers, I don’t see that much of a range as it relates to just this one particular question. Most of the other Star Trek engineers seem to fit in one of the existing categories. They have different personalities and characters for sure, but not so much as it relates to work predictions and timelines. I would love to add another fun category like Rom or Barclay, but haven’t heard a good argument to expand beyond the three. What I find appealing about these three is that they are the most contrasting. While I don't think there is any chance of this replacing something like the Myers Briggs personalities types or the like, I do hope others can find this classification as fun and helpful as I have.

An image of a glass 3d printed self-portrait of myself as a star trek officer.
A glass 3d printed self-portrait of myself as a Star Trek officer.

--

--

Ryan J. Riker
Silicon Mountain

I am an unconventionally extroverted DevOps engineer. That wears lots of different hats. I take my experiences and turn them into interesting observations.