I realized eventually in my career that there were tasks required of my job that made me a worse engineer. It took some time to realize this counter-intuitive fact.
I want to explain what things you do that can make you a bad engineer, and how to avoid or mitigate them.
There are two criteria for defining a skill for engineering - transferability and whether the skill helps you make The Product. There is a philosophical question of why “The Product” is different for each company which isn’t in scope for this article.
In general, skills that are a nuance of a particular organization are not engineering. They do not transfer. They may look like engineering, they may quack and have feathers like engineering, but they are not engineering.
Learning a niche software that has custom functionality that you will never use outside of that organization is not an engineering skill. However, if using the tools taught you a nuanced and relevant analysis that you can carry on to tasks outside of that company, you’re developing an engineering skill.
are purely in the sense of their engineering ability for this article. Whether or not the organization is morally “good” or worthwhile is another topic.
A broken organization:
Pushes decision making upwards hierarchically in the organizational structure
Encourages or rewards design by committee
Treats documentation as a tool for decision making and not for enabling other engineers to make decisions
Has artifacts become proxy for the work
Does not put effort into growing the technical skills of its engineers
Abstracts products into tasks that aren’t performed and owned by a single individual
These do not require proof - it’s given that the opposite would grow engineers and make your organization more effective in an engineering sense.
but if you work for a great organization, you’re more likely to become great. Neither are given, but this is true more often than not. For the rest of this article, this is called the “Abyss Principle”.
This means if you are doing Stupid Things™, you will get very good at Stupid Things™. Getting good at and doing Stupid Things™ makes you a worse engineer because:
You spend less time getting better at doing and increasing your skill in engineering
You’re constantly increasing your tolerance for Stupid Things™
In some cases the decision making in doing Stupid Things™ is in opposition of good decision making in engineering, training you to be bad
Skill entropy outweighs your skill development and you worsen
You aren’t paid to write email, you’re paid to write email where you understand how and why the part failed the supplier outbound quality checks, and make the decision as to whether or not the failure is okay. Writing email is one of thirty tasks required in that sentence — writing email, checking drawings, running your tolerance analysis, checking yield stress against allowables, etc. Email is a sub-task of a larger task (getting your part delivered), because tasks can contain tasks.
Every role can be thought of this way - from a machinist to the CEO. Responsibility, scope, and the tasks will vary, but we are just task machines with egos.
as a way of creating their products. All organizations do Stupid Things™ at times as a necessary evil, but at some point the percentage of these tasks relative to your other tasks pushes you into the broken organization column.
Every day you clock out, you lose a percentage of your skill. This is “Use it or Lose it”. If you spend a decade not performing the tasks required of a technical role, you will either lose the ability to perform those tasks, or performing them will be slow enough to be as though you never knew how to do them in the first place.
This means that living in total orthogonality on the Task Vector Chart means you’re actively becoming worse. The only way to counter this is to do technical work.
My belief is that all tasks can be charted in a way to tell you if what you’re doing is a Stupid Thing™ or not. Here’s how:
Make a chart where the X axis is engineering skill, and the Y axis represents the non-technical and engineering irrelevant portion of the skill required for a task. In reality, a task is a high-dimensional vector where each task vector projects a single vector into many skill components — see the email example above.
This chart plots vectors that represent the task (interference check) in question and what portion of it is making you a better or worse engineer. Any vectors between 0 and 89 degrees contribute to you becoming a better engineer, and any vectors between 91 and 180 degrees contribute to you becoming a worse engineer per the Abyss Principle.
Good tasks require engineering skill and discipline and chart high on the X axis. In this example, this is an almost purely engineering skill related task (analyzing a part that requires high stiffness yet isn’t brittle and requires a commonly available alloy). This requires mechanics of solids, understanding of analysis tools (FEA or software engineering), CAD, physics, mathematics, etc, all the way to completion.
Some tasks are not particularly technical, but still chart positive on the engineering skill axis. For example - an RFQ is just a document, but buried in it are some of the most important skills an engineer needs to make The Product.
Managing vendors is critical. Bargaining with, motivating and managing your vendors is essential to making something, especially if it is new. So, despite not being outwardly appearing technical, this skill is critical to your engineering development and is one you should relish.
Let this example serve as a reminder to not become spoiled when considering tasks on the chart. One can’t just point at the chart and say “that’s not technical”. There is a wide gradient of gray area.
Tasks that do not make you a better engineer, but don’t pull you into bad decision making territory are at 90 degrees.
I chose expense reports specifically because they are required of the business, but are not of the engineer. They will eventually be automated away, like many things have for engineers (making drawing copies, etc).
The surprising thing is how much of our work lives in this area. Things that would seem like engineering work (a majority of our day in some organizations) are actually close to orthogonal and are not contributing to your engineering skill development.
Worse than engineering skill orthogonality are tasks that make you a worse engineer.
Writing a ten page document that neatly, clearly and concisely outlines your recommendation to choose Aluminum 6061-T6 over 5052-H32 sounds technical, and it is to some degree, but the amount of time spent preparing that documentation outweighs the benefit. Even worse, if you’re creating a ten-page document on a decision that should be relatively menial compared to the rest of your workload, it’s likely you’re pushing decision making higher up the hierarchy and this is a Stupid Thing™.
Most engineering tasks of the modern world live in the semi-orthogonal or negative directionality purgatory. It is one of the greatest challenges of engineers of the past few (and next few) decades until we can trick LLMs into doing our busy work for us.
Note that writing good (and not wasteful) documentation would be slightly X positive (not negative or orthogonal) because writing documentation about a thing makes you understand it better. If that’s all you do, it’s a problem, but if you’re documenting things so that another engineer can do their job well, you’re contributing to the art and this is a net skill positive.
Part of being a junior engineer is doing the work that the seniors don’t want to do — this is how they learn the basics. This has the secondary effect of forcing a senior engineer to think through tasks to ensure they’re really encouraging the juniors, and not just pushing busy work. It acts as a lighter form of the next recommendation:
I’m writing this despite it being borderline impossible to implement in an organization unless you have a dictatorial type rule over it (which you probably don’t). Stupid Things™ (aka Process) tend to have a Stockholm Syndrome component to them. Over time, people will feel comfortable with and protective of Stupid Things™ and they will fight against their removal.
It’s likely pointless to fight the organization you’re in.
Most engineering tasks can’t be automated. If you’re a Civil PE, you can’t stamp something you didn’t review. It’s that simple.
I implore you to find the things you can automate, but they will be difficult to find.
The usual best path. You can’t fix broken organizations from the bottom up.
Find a good engineering organization. There are ways to check for this in the interviews. I’ll write something about this soon.
Most of the time you can’t just quit, but while you’re looking for a new job, I recommend pursuing your skills outside of work. The good news is that I’ve found entropy to be a small fraction of the knowledge I gain in a single hour of post-office engineering. A couple hours a week will keep you sharp.
This matters. Stay sharp. Don’t fall into the trap of gladly being a high performer at a Stupid Things™ organization because you will develop bad habits, worsen your skills and ultimately make yourself toothless for when the time comes that you need to operate outside of it.
You can be a high performer, but it will take conscientious effort to not diminish your abilities. Take the time to recognize Stupid Things™ and how you can counteract them.