Many engineers do not realise how much they have been limited, both skill-wise and success-wise, by their professional experience. They have just accepted it for what it is, along with its effects upon themselves, and not thought to correct for any limiting issues – they are thus trapped and don’t even know it.
Let’s talk about how you can tell if you are trapped and how to break free.
First off, I should note that my experience, especially in the early stages, was pretty good. So I should state that this is not a case of me living something out myself and then saying, “and you can too!” However, I still learned that my experience was not perfect, and I did need “escape” in a way.
So what are some signs you are trapped?

• You feel you do good work, but people still seem to have issues with what you do.
• You have a fixed notion of how administration should be run – maybe you think there should be none – regardless of the size of the company or the nature of the engineering work being done.
• You feel you need to always defend your work or remind people of what you have done.
• You are afraid to share any idea until you have it fully evolved.
• You work on your own tasks without engaging others working on peripheral or related roles.
• You follow a few guiding principles doggedly and don’t trust anyone suggesting deviation from them.
• When you are presented with an idea that is different, and seems odd, your emotional response overrides your engineering mind, and you dismiss or criticise instead of analysing.
• You expect there to be a prescribed process to solve each problem encountered.
• You like the idea of the engineering department being separate from all others so you can do as you wish.

It might be hard to see the common theme in the above idiosyncrasies, but the root cause is working in an organisation that did not encourage good engineering practice that is aligned with the company size and business model. In such situations, the following can happen:

• An influential mentor will instil in other engineers what has worked for them but is not universal. This one is one of the most common.
• The administration system is not designed or updated for the organisational needs. So it never supports the engineering team by helping to track or guide progress and documenting successes. And it is therefore always a burden for all engineers.
• There is no established culture of suitable exploration. And engineers are either criticised for thinking of something different or expected to implement set processes and solutions.
• There is no system, formal or informal, that encourages the engineering team members to engage each other or people from other teams.

An engineer working in this kind of environment will not develop the engineering attributes that allow them to grow into a professional engineer. Instead, they will simply survive the environment – and become reactive engineers just trying to get by from day to day. This becomes habit, and the engineer is then trapped in this mindset.
How to escape this trap.
The good news is that you do exactly the same thing as any other engineer who wants to improve. You need to focus on applying the attributes of the expert engineer regularly. I cover these attributes in detail in my book, but the key points are:

• You work on framing and reframing problems that are given to you.
• You think systemically when solving challenges.
• You apply first principles to assess ideas and inform your decisions.

As you continue to develop these attributes, you will break off the shackles of your prior work experience. You will then be free – and no longer trapped.
Once you are free, you will then be able to consider other aspects of your engineering ability. Things like your cultural, national and economic background. Then you are working toward being a global engineer.
And if the company you work for does not support this, then it’s time to leave. And you know what kind of company you do want to work for – so you won’t leave one trap just for another.

There are some things in engineering that are very counterintuitive that, if not fully understood, prevent engineers from doing their best work. These perceived paradoxes can limit or misdirect your thinking such that you are not the engineer you can be. In this article, I am going to share two examples of this and then introduce a maxim that can help you with this.

Example 1 – quality is cheap
The above statement seems very counterintuitive; indeed, it is the case that you can often cut back costs at the expense of quality.
However, when a system is easy to implement, making it cheaper to realise, there is also less chance of a mistake being made, meaning quality is higher.
This was one of the reasons Toyota was so successful in the automotive industry – by focusing on making things easier to produce for higher quality, they also became cheaper. The opposite was true as well. By cutting out waste (wasted time, wasted parts, wasted steps) to reduce cost, there was less that could go wrong so quality increased.
This is not to dismiss the importance of more expensive items when needed, but often they will be cheaper in the long run anyway. It’s just that engineers can sometimes give themselves false assurity by choosing the more expensive option.

Example 2 – simple code can do more than A.I.
One would think that with more lines of code and a complex algorithm there would be more going on so it can do more.
But code that has been written explicitly can be tuned so that it achieves the exact goal desired. If a trained ML system does something wrong, then you likely have no idea what’s causing the issue. All you can do is make a few adjustments to the training system, retrain, and hope for the best.
If, on the other hand, you have explicit code, then you can understand what’s happening (or not happening), and make changes to improve performance.
This is not to be dismissive of things A.I. Comparing ELIZA to what’s on offer today shows how powerful A.I. systems have become. It is more that we can think A.I., because of its complexity, will be the better option regardless.
But still, when one considers the success in the early 1970s of much simpler systems – such as the one documented by F. T. de Dombal et al. in Computer‑Aided Diagnosis of Acute Abdominal Pain where a relatively simple program outperformed senior specialists (91% success vs 80%) – there is the potential for simpler code to do more.

What is missing in engineering thought for this to happen?

It can be found in the 1920s.

For some time, it could not be determined if light was a wave or a particle. It had properties of each – depending upon the test. However, by the 1920s, it was accepted that light was both a wave and a particle.

The “OR” was replaced with the “AND”.

And that’s the key thinking difference you need to adopt.

Stop thinking things like:

• We can have low cost or quality.
• We can have efficient code or accuracy.

Instead start thinking things like:

• What can I do to have both lower cost and high quality?
• How can I approach this so I can use simple code and increase accuracy?

​In short, stop asking the “OR” questions and start asking the “AND” questions. Make this a habit, and you will start producing better engineering outcomes – because you will not full into traps of intuition.
Everyone wants to have their cake and eat it too.
And engineers should be trying to make that happen!