You have likely heard the phrase “Greed is good”. It is from the movie Wall Street.
The full quote is actually “The point is, ladies and gentlemen, that greed -- for lack of a better word -- is good. Greed is right. Greed works. Greed clarifies, cuts through, and captures the essence of the evolutionary spirit. Greed, in all of its forms -- greed for life, for money, for love, knowledge -- has marked the upward surge of mankind.”
The point of the movie producer was to show the destructive attitude within the corporate world. Others have suggested that the quote is aligned with theories on how the free market (through things like Adam Smith’s invisible hand) and how it makes society better.
I was struck when I found that the quote includes the phrase “for lack of a better word”. It opens up the opportunity for the reader to insert their own nuance – and take what they want from the quote. Especially when linked to life, love and knowledge.
For this article, “greed” is going to mean a desire to make the most of what is available. And we will talk about how a capitalistic system based on this greed could be good for engineers.
If capitalism were to be good for engineers, then how would it be so?
Capitalism should allow for anyone with a good idea (and the sense of greed to make the most of it) to start a venture based on that idea. Therefore, capitalism should mean that there are many places for an engineer to work – offering a chance to find exactly the kind of role they want or pursue a change when they want.
This would be measured via the number of startups (ideas being commercialised) and the economic complexity index (indicating the number of different places an engineer could work).
Which countries top these lists?
The three countries with the highest economic complexity index are: Singapore, Switzerland, and Japan. Countries with the largest number of startups (deep tech – because that’s what you and I are interested in) are: the United States, China, and the United Kingdom. Per capita, the countries with the most startups are: Israel, Estonia, and Switzerland. These are countries that one would expect to offer more opportunities for engineers. Certainly, these seem like countries that have engineering activity. And most seem capitalistic. Although China is officially communist – it has been leaning into capitalistic practices in some ways of late.
So capitalism can be good for engineers – offering a diversity of opportunities, and a more satisfying career.
But it is based on the notion of doing what the customer wants, which might not be good for them in the long run, to remain profitable and competitive. And that in turn means looking for every opportunity to squeeze as much out of the resources available so that the customer sees the offering as the best value for money out of all the options on offer.
Therefore, an engineer who has come from a company (or industry or country) that has flourished in a competitive and capitalistic environment, would likely look for more input on what the market (end user, client, customer) wants. This is especially so when working on a larger, less defined, but well-funded project (like those associated with publicly funded research activities and public works). They could tend to create other constraints through goal analysis (where an engineer looks for more opportunities to improve the outcome for the end user) and then satisfy those as well. These efforts, while well-intentioned, are likely to be wasted effort – because there is no competitive advantage to be gained when there is no competition.
So if you are a global engineer moving from a competitive industry to one that is more regulated, then accept that it might very well be that what you initially think is helping the company could be just wasted time. And, if you are employing an engineer from a competitive industry into one that has different drivers, then think about what you can do to help them better understand the changing requirements and where they should now put their efforts. In short, tame that greed!

Do you ever give thought to who was the smartest person ever? Or, compare one supposed historical genius with another? I am more inclined to compare them. The notion of intelligence and smarts has proven to be too difficult to quantify in this context to work out who the smartest is. A comparison though, I have found, reveals more about the way we choose to think and what we choose to learn so that we can be better at what we do.

So, in this article, I am going to compare two people history has decided are geniuses for two rather different reasons: Sir Isaac Newton and Leonardo da Vinci.

One of the things I find most remarkable about Newton is the story of how he solved for the Brachistochrone curve. This is because I am quite fascinated by the related isochronous curves and because of how quickly Newton found the solution compared to others at the time. It was a challenge set by Johann Bernoulli in a scientific journal for all those who read it. It seems that Newton did not read it because Bernoulli sent him a letter directly. While another requested one and a half years to find the solution, Newton found it on the night he read the letter (after getting home from work at The Royal Mint).

What strikes me about da Vinci is how he used the scientific method to find knowledge to help him with things as diverse as inventing machines for specific tasks and his painting. He got his hands dirty – literally. He would dissect people so he could then understand their form – allowing for better paintings. He also paid detailed attention to what he saw – using his studies of light to revolutionise the use of shadows to enhance the 3D effect in paintings. He never learned mathematics or Latin and never pursued any formal advanced studies. He was not part of the contemporary scientific community. But with the knowledge he gained, he evolved insights for ideas on mechanisms and inventions such as a strut bridge, an automated bobbin winder, a rolling mill, a tensile strength tester of wire and a lens-grinding machine.

While Newton invented the reflecting telescope, it is hard to imagine him making such advances in art or contemplating numerous types of mechanisms and inventions like da Vinci did. While da Vinci showed considerable scientific expertise, it is hard to imagine him deriving formulae for natural phenomena.
It is indeed as if each of them had powerful brains made for different things, and one could not expect one to also be good at what the other did.

But is this true?

If we go back in time further again, then we can consider Archimedes. He was definitely inventive. Think of things like: the Archimedes' screw, the compound pulley, a crane used to lift and drop attacking Roman ships, an odometer. He also came very close to inventing calculus without algebra and only geometry – making him all the more impressive.

Could Newton have achieved even more if he got his hands dirty? He did put on disguises to bust counterfeiters so he was the type to get visceral if needed – if only he put that ability to something scientific or technical.

What would da Vinci have achieved if he could have applied mathematics to his inventions for faster optimisation and assessment? He certainly had the mental capacity to learn and master mathematics – imagine if he could have used mathematics to find the most viable invention ideas to progress further.

Or, would they each have lost what made them unique and impressive?

We will never know, and each can, regardless, be very content with what they did achieve.

But it is hard to imagine any harm in them broadening their skills to augment those they already have.
​
And that’s the lesson for you as a global engineer. As you move from one role to another, think about the new skills you might need – and then develop them. Even now, think about skills that could help you just a little or might help in the future – and then develop them.

I have just finished reading a book called The Cognitive Athlete by Clint Rahe.
The book focuses on methods used in the military, professional sports, and other high-performance fields, and then explains how you can apply them to efforts that are cognitive in nature.
I am not going to review the whole book, but I am going to share with you the basic thrust and something I noticed that is ideal for global engineers.

The basic thrust.
We should not think about time management to maximise our performance as professionals. Instead, we should better understand how our energy levels work so that we can work on the right things at the best time.
This could mean working out when you are most able to think clearly and take on the most challenging of tasks – and then scheduling that time to be free of meetings so you can focus on the hard stuff.
It could also mean finding the time when you are least capable, and then allocating that time to reply to routine emails.
By aligning your periods of maximum energy with the more challenging tasks, you become much more productive.
Further, you should also find ways to automate or routinise as many tasks as you can so that you have energy reserves left over for the tasks that truly need your cognitive capabilities. This includes things like checklists for checking drawings, a standard procedure for approving purchases, and a uniform way for reporting faults in maintenance.
In addition, if you are going to have a period of high demand, then you need to have a period to ramp up prior and then a period of recovery and reflection afterward. What was interesting about this aspect was that these periods could be throughout a day, a week, a month or a quarter. There was no consideration of periods that go for longer. Meaning, if your job is pushing you to 100% until the end of the year, when you can rest, then you are not operating at 100% energy levels – and you are likely far from working optimally.
This is a very rough summary, and if you want to know more about how to maximise your cognitive ability so that you can perform at a higher level, then get yourself a copy.

Why this is important for the global engineer.
As a global engineer, you need to be able to shift to new contexts and still perform well. The perspective of The Cognitive Athlete allows you to understand the nature of cognitive energy expenditure that is required in any new role you find yourself in.
This could be a result of national practice, company practice, or the nature of the specific challenge.
I now know times when I need this more:

• I have worked in countries where the norm is 5.5 days a week so I needed to management me energy differently from other places.
• Some roles were continuous in their nature – always solving problems as they presented – so I had to plan my energy usage on a daily and weekly basis to ensure I would not burn out.
• Other roles had definite busy periods and periods of different task types – I would therefore need to plan for periods to note lessons learned (so I would recall them for the same time next year) and use a short break to get myself in the right frame of mind for the next period.
• I have also worked in roles where, due to time-zone differences, I needed to work at times not aligned with my natural rhythms, and I would need to be more mindful of making the most of those periods where my energy aligned with the opportunity to work on more demanding tasks.

As a global engineer – or as any type of professional – you too can find you will need to better align your energy levels with your job. And efforts for better alignment will pay off big time.

My biggest takeaway from the book.
I certainly appreciate the new perspective on managing energy instead of time. But for me, the one thing that really stuck was the notion of taking time to reflect upon performance after a major event. I am going to think now about those kinds of large singular events where it is beneficial to pause afterward to contemplate how well it went and in what ways so I can do even better next time with better long-term preparation.
Think now about those rarer large events where you don’t get to learn from your experience as much as would be ideal. Maybe you too need to pause after those and take some notes for future reference. 

If you have been paying attention, then you have heard about the USD 12 Billion that Jeff Bezos and Vik Bajaj raised to develop an AI general engineer. One that can do what any other engineer can do – so it should be much like a global engineer. Read more here if you are not aware.
If possible, then what would that mean for professional engineers like us?
Bezos thinks this will help augment engineers and give them more time. Others think that all engineers will eventually be replaced. And what has been achieved thus far is not yet in the public domain.
In this article, I am not going to talk specifically about what Prometheus will or will not be able to do. Instead, I am going to use this as an opportunity to talk about the following:

1. What would be needed to train such an AI system?
2. What that means for the nature of such an AI system?
3. What would that mean for engineers working with such an AI system?
4. Should we even expect such an AI system to think the same way as human engineers?

I am not going to assume that I will know exactly what is being done on Project Prometheus. Nor that I will have the exact answers, but this conversation will help you and me think more about what’s needed to make an AI engineer and what it is to be an engineer in general.
What would be needed to train an AI engineer?
In my book on being a global engineer I noted what has been found about the way the best engineers think. In summary, they do 3 things really well:

1. They frame problems in a way that makes them easier to solve. They do not accept the problem as is. They look at it from different angles to find another way to define it – and then find an angle that makes the solution obvious and easier to implement.
2. They think systemically. They do not focus on just the challenge in front of them. They look at all peripheral elements for both challenges in accomplishing their goal and opportunities to help achieve those goals.
3. They use first principles. They do not make arbitrary decisions about the values of key parameters. They calculate the optimum value based on theory. They also use theory to understand the nature of any challenge they face.

Would an AI engineer explicitly be trained on these three attributes?
If so, then would we explicitly state these as needs or would we train the system to engage in these actions by default?
Not only that, but would we consider other, very human aspect of engineers?
One example is fixation. Where someone, in this case an engineer, stays focused on an idea that has come to them. It might be because it is the first one that showed promise, something they are excited about, or something that seems obvious because they have been working in a certain field for so long.
Fixation can, at first, seem like a bad thing. However, it has also been found to provide drive – and engineers have developed remarkable innovations by overcoming the challenges caused by this fixation. Sometimes better than what would be expected by someone objective who could see that fixation taking effect.
Would we want the AI engineer to show this tendency toward fixation to explore ideas fully?
Which brings us to another attribute: co-evolution
Many engineers talk about the need to iterate a design. I agree with the need, but I do not think the word “iterate” explains the depth of what is going on. The word “co-evolution”, I think, elicits the true deeper meaning of what is happening. As a solution is implemented in some sort of trial, new information is generated about the problem. So as we generate the solution, we better understand the problem. The solution and the problem evolve together.
As we co-evolve both the solution and the problem, we expand our understanding of the solution and problem space. It is like exploring a new land – but one where the terrain is the challenge we are solving. Some solutions find a path through rocky terrain that opens new areas to explore that we never knew about.
Do we need to find a way to train an AI engineer to explore like this?
If so, then is it all through simulation or do we need to run the physical tests under its instructions and then report back (expecting questions about how well we ran the tests)?
What does this mean for the nature of such an AI system?
Considering the above, do you feel that there is data enough to train an AI system to be a general engineer?
Personally, while I do think AI engineers will eventually be a thing – and eventually be better than us, I am not sure it will happen as a result of ingesting large amounts of data.
I think there will at least need to be some kind of reinforcement learning. Where the AI will adjust through trial and error to provide better outcomes.
That means the system will need some kind of objective measure of success. It will need to be able to assess how well an idea has performed. Maybe based on a numerical goal. Maybe on some other system that is more “reflective” so it can ponder how it could have done better – comparing what it actually did with other things it could have done.
This is something that many engineers do. You have possibly thought back to things you did years ago and thought “now why didn’t I do it like this?” I know I have done that.
So the AI engineer would need to have some kind of inner monologue. Is that possible?
Maybe it will actually need to be a team of AI engineers – each with different parameters from their own training – interacting with each other. Comparing the performance of each other’s ideas and then adjusting their own parameters to think in a better way.
So it might be that we never have a single AI engineer in the true sense, but a collection of AI engineers working together and then presenting output as if it is from a single AI engineer.
This considers the “cognitive” aspects. But what about the physical or real-world execution?

• Will the AI engineer call up suppliers to confirm current capabilities and use that as an input?
• Will it have hyper-generalised transducer (maybe a humanoid robot) that allows it to build and run prototype tests?
• It will likely be able to connect to rapid prototype machines, but will humans (with their nimble hands) still be the ones putting the parts together and finding (with their comprehensive senses) the ideal place to run the assembled product?
• What is the most economic execution of the above actions at this time, and what does that mean the AI engineer should be like?

The above does seem to point to the notion put forward by Bezos that the generalised AI engineer will be working with other engineers to increase productivity and free up the time for humans. For now, at least.
What does this mean for engineers?
If you do ever find yourself working with a general AI engineer, then it would seem likely that you will be using it to do the things that would normally be time consuming for you. Explore numerous ideas, source the appropriate first principles, conduct simulations and calculations, generate test plans, come up with questions to better refine the problem statement.
You could then share your own ideas to help move things along.
At first that seems like you get to enjoy the fun parts more. And have more free time.
 
However, in the continued pursuit of profits, I am sure there would eventually be fewer engineers working for the same amount of time. History just shows that’s how things go.
But how will you interact with the AI engineer?
Again, in my book on being a global engineer I covered how words are not enough to explain engineering concepts. How engineering is very much a visual thing – even though other senses can help better understand any challenge you are facing. How do you convey what’s in your mind’s eye to the AI engineer?
Engineers are either going to have to improve their CAD skills to quickly convey their ideas or work on their ability to sketch. You might be able to use words to ask for an initial concept, but sooner or later you will need to edit some sort of visual to convey what’s in your mind.
But will the AI engineer visualise the way we do?
Should we even expect such an AI system to think the same way as human engineers?
We have developed our engineering skills by working with the brain that biological evolution gave us. This does not mean it is the only way invention can come about.
There are numerous examples in nature of animals showing the action of invention. Sometimes it is thought to be a result of instinct from evolution and sometimes from actual intent. But, as we learn more, the definition of intelligence and creativity seems to broaden.
Such ideas have also been explored in literature.
In the Children of Time series, Adrian Tchaicovsky explores how creatures with multiple brains or limited memory capacity could evolve inventiveness. In some, there is a separate brain that takes the problem as given by the main brain and then returns a solution some time after processing. Others have an ability to install and uninstall knowledge so they can use what is needed for the respective task.
In the West of Eden series, Harry Harrisson explores the nature of intelligence and inventiveness of an evolved reptilian brain. Where all technological advancement is an iteration on previous efforts with no major leaps – keeping them away from metal working and machinery, but phenomenal selective breeding.
Given the diversity of thought that we have found in nature and what we can conceive when we put the effort in, we can expect the possibility of a general AI engineer that thinks very differently from how we do while still generating excellent solutions.
Will we be able to work with such an engineer? Will we automatically think it inferior? Will we try emulating it ourselves after it reveals new ways of thinking to solve engineering problems?
In this article, I have only covered the major and some select aspects of engineering cognition. I have also only covered a select number of engineering activities associated with the full implementation of any engineering solution. I have also only alluded to the importance of engineering teams. And the diverse nature of the potential forms of intelligence was given only a cursory coverage. To deal with them properly would require an entire book.
That means there is much more to explore and consider. I currently can’t make any solid predictions about how this will all end up.
However, I do now feel convinced that the effort to make this general AI engineer will reveal much more about what it is to be an engineer. Even if it fails. So I plan on following it in detail, and I think you should too.
As you think about it now, what challenges and opportunities do you see? What would you want a general AI engineer to be like?
Share your thoughts – this is a conversation I would like to extend so we can all learn more about what it is to be an engineer.

Here is a scenario you have likely been involved with if you have had even a short amount of engineering experience.
Someone in a meeting suggests something that is unorthodox. Others dismiss it – maybe even derisively. But the one who put it forward continues to think it is a perfectly good, and logical, idea to pursue further. Neither side agrees with the other nor even understands the other.
How can engineers, who should be using sound and rational reasoning to assess all ideas, disagree like this? Surely, they should be able to explain their point in sufficient detail to ensure clarity – and not degrade into unfounded disagreement that seems more like personal preference.
The reason for this is that at least one party (probably all) is relying on their instinctive response and they don’t actually understand that response.
If you take a moment now, then you can probably recall a time when someone presented you with an idea to which your initial response was just discomfort. You did not know exactly why you felt uneasy with the idea. You might have even acknowledged that their explanation as to why it was a good idea made sense. But still, you simply did not like it.
This was your instinct.
It might have been right. But if you can’t explain it, then you will not have agreement. And just so you know, engineers can’t say things like “It just doesn't feel right to me” and expect that to be argument enough.
For a global engineer, this can be more extreme. If your instincts are based on experience in one context, then those instincts could be perfectly correct for that same context. But in another context, which is more likely to be experienced by a global engineer, the likelihood of it being corrects is much less.
You therefore need to dig deeper into your feelings, and turn them into sound logic.
Such feelings come from your unconscious, which holds numerous memories. One of these memories was triggered by the idea put to you. Something you experienced in some way suggests this idea would not work.
So your job is to delve deeper into your mind and find what it is that generates this feeling.
This is much easier said than done. You will likely need to sleep on it before you realise what caused this feeling. However, as you continue to put effort into accepting the feeling for what it is and then trying to extract what caused the feeling, you will get better at this. Eventually, you will find that you can extract this information in moments and with little effort – because you have created the mental paths that allow for easy flow.
The other side of this same story is when you come up with an idea, but others just don’t get it. And you don’t know how to explain it well enough – because it is instinct, and not clear thought.
This time, the idea came from the same place as did your unease with other people’s ideas. And without those mental pathways, you just can’t get the important knowledge out to create the argument you need to explain what you are thinking.
Once again, you need to work at it – until it eventually becomes something that happens in the moment.
Once you do this, you will:

1. Better explain your ideas – releasing the genius within.
2. Only critique ideas that have real issues so that good ideas are not dismissed – controlling the idiot within.

So next time you have that instinctive feeling, dig into it. And reveal the genius you have within or foolishness you need to excise. 

While it is important for an engineer to utilise all sensory options to fully understand any challenge, the ability to visualise remains the most vital skill.
So in this article, I am going to talk about a way you can improve this.
It might seem a bit hippy, but it works.
Pretty much everything you do can be improved with dedicated training. From something physical like running to something incorporeal like having compassion for all others. So it would be the same for your ability to visualise.
There is a practice that requires, probably more than anything, excellent visualisation skills.
And that’s meditation.
In some parts of the world, this is considered a daily activity. In others it is thought to be similar to prayer. In much of the West, it is associated with hippies and alternative life styles.
Regardless of how you view it, I am, in this article, going to view it as a cognitive process – and then take from it aspects that are useful for visualisation, and thus engineering.
Because I was raised in an area that had a community with a significant element of people pursuing an alternative lifestyle, I was introduced to meditation and its various tools in my teens.
Later in life, I found that the visualisation skill this developed in me, was perfect for many engineering tasks.
And what follows is the primary technique used to develop this skill. Try it daily if you feel your ability to visualise could be improved.

1. Find a quiet place you can sit or lie down for a period without being disturbed.
2. Relax. If you have a technique you use for this, then use that. Otherwise, Try this:
   1. Close your eyes.
   2. Now focus on the peripheral sounds around you. Slowly work out to the sounds farthest away (not the quietest – the farthest away).
   3. As you do this, think about the greater world and your physical place within it. This will help distract you from other worries so you can relax.
   4. Now focus on your breathing so your breaths become deeper and slower.
   5. You might not be totally relaxed, but you will be in a better position to try the next step
3. Imagine you are sitting in a movie theatre – visualise the colour of the furniture, all the seating, the screen in front, the speakers on the wall, the aisles for people to enter and leave, the exit signs. All the different details – try to see them in your mind’s eye at the one time. It might not be easy, but this is training so you can always come back to it to see it get better.
4. Now imagine the lights going dark so you can see what will be presented on the screen.
5. An image is now projected onto the screen. It is nothing more than a bolt. But you can visualise every aspect of the bolt. The thread, any flash from forging, the shape of the head, the colour. Focus on creating every detail in your mind’s eye. Again, it might not be easy, but this is training so you can always come back to it to see it get better.
6. Keep this image in your mind’s eye for about a minute. You will likely lose the image at times, and you will need to bring it back – this is all part of the training and improving your skill.
7. Open your eyes and remember to do this again tomorrow – until you feel you are better at visualising.

There are many other things you could use meditation for (including engineering) so don’t think the above was meant to be a thorough coverage of meditation. It is simply a training exercise to help you improve your visualisation skill.

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!

In this article I am going to talk about a common phenomenon that has afflicted at least one engineer (usually more) in every company I have worked for. It affects engineers (and others) around the world.
And it might affect you!
And if so, then you want to know it – and how to overcome it.
Because this phenomenon is practically the first key thing you need to overcome if you wish to be a global engineer. In fact, once you crack this, the rest is fairly easy.
Which is why it is so sad to see engineers who have been limited by the phenomenon their entire careers – and never progressing as much as they otherwise could have.
So what is this phenomenon?
It has been described by numerous people in different ways with different perspectives. But you can basically say it is the notion of true independent thought.
Independent thought means you are no longer reacting to a situation. Instead, you contemplate it, you ask yourself questions about that situation, you are then prompted to think more, you collect information, you try solutions or responses to better understand the situation – and not necessarily solve it. Basically, you “explore” the situation.
No matter the culture you come from, it was likely heavily influenced by someone (and others) like this. History has many such people who thought for themselves and then laid foundations for others to work with. Adam Smith. Confucius. Mohammad. Aristotle. Francis Bacon. Karl Marx. Buddha. Imhotep. Jesus. Deganawida. There are many more. There would also be others you know who also have independent thought – but they have just not been as influential.
You too want to be such a person so your engineering, while potentially being influenced by your background, is not controlled by it.
When you can think independently:

• There are fewer genuine issues raised with your ideas. Either in review or implementation. This is because you have been able to collect the information needed to create informed ideas.
• When issues do present, you can usually overcome them quickly – you are familiar enough with the context that you thought these issues were a possibility or you understand them in an instant.
• You can justify, to yourself or others, each aspect of any idea/solution you have developed.
• You likely took your time before launching into final-solution mode.

When you don’t think independently, and you tend to be reactive:

• You often find people raise issues with your proposed solutions and feel you are often criticised.
• You can be shocked when things don’t work out as you expected.
• There are numerous aspects of any solution you put that seem arbitrary.
• You probably jump straight into coming up with a solution, and, as you do, each step feels more like a reaction to the prior step than a well-thought-out step. You basically keep shooting from the hip.

Think about the above now – and determine what kind of thinking you currently engage in.
So how do you become the type of engineer who thinks independently?

• Before you take on any task, take the time to ensure you get it. Don’t just assume you get it.
• List questions you could ask about the respective situation – put dedicated time into this.
• Allocate time to review what you are thinking of implementing, be it a handful of concepts, your understanding of the problem to be solved, more refined ideas, etc. By having these breaks in your solution process, you can check if you have been reacting (shooting from the hip).
• Keep a list in sight (maybe on Post-it notes) of all the various aspects of the situation you have discovered – this is to remind you think about these various aspect, and stop the reactionary thinking.

Once these practices become the norm, you can better contemplate your own thinking. You can then work on becoming a global engineer – and that will now be much easier.
A note for managers – demanding a design log and regular reviews can have the desired effect upon any hip shooters in your team.

In this article I am going to talk about a fault many engineers are cursed with, but, by definition, should not be. It is also a fault that can be exacerbated in a global context so it is even more important for global engineers.
If you want to ensure you are not cursed with this fault, then read on.
The curse I talk of is using indicators as opposed to facts to make your engineering decisions.
Each word above makes sense to you, I am sure; and the sentence likely seems sensible enough as well. But I will use 4 examples I have experienced personally to make it clearer to you.

Caulking glue for precise location control
This was an interaction between two engineers who needed to find an adhesive to:

1. Mount objects that needed to stay in place as the adhesive cured.
2. Release minimal chemicals during curing so that it did not pollute other nearby systems.

One engineer did the sensible thing, reviewed test data on as many available adhesives and then tested samples of those showing most promise.
The winner was an adhesive used in domestic applications, was cheap and came in a big caulking tube like one you would see on construction sites.
The other engineer, upon seeing the winning adhesive expressed surprise and apprehension. They were expecting something that would come in small containers, like you would see in a laboratory, require mixing, and be expensive.
The other engineer, given the scientific rigour used to select the winning adhesive, should have checked their bias. But they did not, they actually let this bias continue to guide them.

Metal putty or metal augmented two-part epoxy matrix
When a company was looking for a way to adhere a part to an assembly for quick experimental assessment, one engineer used metal putty. If you do not know what this is, then it is basically a glue (a two-part glue) with a high concentration of metal whiskers added. These whiskers make it much stronger than ordinary two-part glue. And, once mixed, it is mouldable like a putty. So you can work it into any shape you like – ideal for experiments when you want to explore different geometries.
The experiment worked, but others had issues trusting the results.
Why?
Because of the word “putty”. It just sounded so agricultural or domestic to them. I know this is the case because they actually said this.
If it had been called “Metal Augmented Two-Part Epoxy Matrix” or “MAT-PEX”, then they probably would have been more accepting of the results.
Of course, you know, when you think about it, that the name should have no influence on the rigour of the experiment or the results at all.

Old textbooks
When new editions of a textbook are published, it usually involves a few extra sections based on feedback from lecturers, the use of different units, case studies that seem more recent, or maybe to leverage new learning technologies. The fundamentals will not change. Nevertheless, I have had cases where people thought they would not learn as well because they had an older textbook.
This was not because of the difficulty cross-referencing reading tasks allocated for their studies. It was simply because the book looked old.
Assuming they could read Latin, such people would look at an original copy of Newton’s Philosophiæ Naturalis Principia Mathematica and assume, because it is so old, that it had nothing useful on the laws of motion.

University education
Does it matter where you studied engineering? Do you think you are taught different fundamentals at different universities? Do some say “now, everyone, keep this quiet – the real formula is F = m a2!”?
The answers to the above in order are: no, no, no.
What is more important are things like: how you studied, and the specific educators and the assignments they set.
Nevertheless, people will, at times like when they are employing engineers, think the place of study will reflect someone’s engineering knowledge and engineering skill. This is at its worst when people assume foreign universities offer less applicable education – without even knowing anything about those universities.
I have mentioned in a prior issue the best way to select an engineer when employing – and it had nothing to do with the place of study.
​
The common theme and the lesson for the global engineer
You can likely induce from the above that the general issue at play is an emotional bias based on perceptions that are not questioned – as opposed to the use of facts and logic. The last example is likely the most applicable to the global engineer – for practical reasons – but, as you move from one place to another, the use of logic over instinct, bias and intuition becomes even more important.
So, do you tend to judge based on feelings or logic? When you read the above examples, can you imagine yourself making those same mistakes or would you look at the unadulterated facts? 

In this article I share why one of the simplest and easiest of things to use is also one of the best ways that lets any engineer deal with the big picture and the details.
One of the challenges for all engineers is to ensure they meet the big picture needs (typically the overall functional purpose of the system they are working on) and the detailed needs (typically things like reliability, serviceability, and other minor aspects that can have major effects if they go wrong).
This act of moving your attention from one to the other and back again to ensure that everything is resolved is given the name “Modal Shifting”.
Modal shifting is not something we naturally do. And when we do do it, it usually slows our progress.
What is needed is something you can use to ensure that you cover all of the issues – be they big picture issues or the detailed issues. Something you can come back to as you progress to ensure you have not forgotten anything. Something you can also refer to when you think you are done to ensure you actually are.
Ideally, this thing would be suitable for teams as well. And, if you are a global engineer, then a team of engineers (and others) of various backgrounds.
There is a system for exactly this. And it’s incredibly easy to use.
The issue is that it’s so simple many choose not to use it. Because it is so easy, it’s hard to truly believe that it will help.
And you probably have already worked out what it is.
It’s the checklist.
There is a reason why checklists are so effective. Because it takes on the job that is so easy your brain ignores it while you focus on more interesting and demanding things. It extracts all the things you can think of when you mind is considering the requirements, and then ensures they are not forgotten as you leap into the demanding and exciting work of developing your solution to the challenge – the time when you normally forget all the minutiae that remains vital.
That’s why they are used in aviation. To ensure pilots release the gust lock for example – look that one up to see how it relates to checklists.
Their power is far greater than would be expected given their simplicity and ubiquity. That, as I mentioned above, is why many do not use them even though they should.
Within the global engineering context, checklists are ideal because they also provide a document of absolute truth for shared situational awareness. Everyone, no matter how they naturally think or are inclined to focus on, knows exactly what needs to be done.
So next time you have an engineering task with various attributes – try a checklist. Collate all that needs to be achieved, before you start the engineering work, and ensure you do everything correctly first time around.
 

This is the first "culture check" article I will write that will specifically look at different backgrounds (in a fairly broad sense because there are so many of them) and how it could cause issues in your engineering. I am focusing on the negative aspects because engineers love having problems to solve.

What are the key attributes of western culture?
Western cultures are typified by a longer period of wealth and a stronger focus on individualism over the focus on the group. There are other aspects, but these are the ones that I will focus on in the context of engineering – because they are the ones that proved significant in my research.
​
And the effect on engineering?
If you are from a wealthy western country, then you are, most likely, from a post industrialised society. That means the majority of wealth comes from the services and knowledge industries – and it has also been like this for some time. And manufactured goods are frequently considered ultra-cheap; thus, the alternative name “The throw away society”.
In such a society, we become more interested in customised and bespoke products. Brands can hold some sway, but not because they are associated with wealth; because they are usually associated with an image or persona. You can’t as easily convince people you are successful by owning certain brands anymore – because the fact is many could afford something that is practically comparable. Status thus comes from uniqueness and thus exclusiveness.
An engineer from such a society will always have more of a tendency to try something new. But not because they know it will be a better solution – even though it might be. But for the sake of the novelty itself – and the perception that the cost is not that great, nor much of an issue.
Now couple this with the tendency to individualism.
Such an engineer would now be more motivated to pursue such an idea for their own glory. If it helps the company, then great. But if it becomes a success, then they would be more inclined to say “That was my idea” as opposed to saying “That helped to company enter a new market”, “That cut cost and boosted revenue”, that reduced down time” and so on.
Thus, with a tendency to gravitate to the novel without worrying as much about cost and with less thought given to the greater group, the western engineer is more likely to go rogue and be a maverick.
This might be what’s needed at times. But, let’s be honest, good engineering happens when the engineering team is implementing solutions that are aligned with each other and with the business goals.
 
And the practical implications are…?
Western managers are probably aware of this – even if they don’t know it – and can manage it. Acknowledging the great idea and engineering excellence and then noting that in a different context we could pursue it, but, for now, we need to focus on something more aligned with the broader goals. I know I have had to at times.
But if you are from another background, then this is something to be aware of should you ever be managing western engineers. And I mean based on cultural/economic/national background – don’t assume if they have a different ethnicity from what you expect, have some heritage similar to yours, or can speak your language, then they will think like you. These tendencies could still be there.
If you are a western engineer, then ask yourself now, and indeed then, and then then again, if you tend to pursue ideas for the sake of novelty and personal glory as opposed to doing it for the engineering team, the company, and societal, success.  

In this edition I am going to focus on what you can do to become the best engineer you can be.
Think about whomever you reckon is the best engineer of all time. It might be someone historical or someone you work with. It doesn't matter who it is, because I am going to explain how you can be just as good – if not better.
And it will not be just a lot of hype and motivational text. I am going to link this back to research so you know what I am talking about is rock solid.
 Let's start with what we know about the best engineers, then how skills in general can be developed, and finish off with developing the best strategy for you.

Engineering skill
The first thing to keep clear in your mind at all times is that there is no such thing as a natural engineer.
Some have certain aptitudes – an eye for proportion, a steady hand, or an interest in how things work – but none of that translates directly into engineering capability or skill. Engineering is built, not born.
But what are the skills the best have developed? They are framing, systemic thinking, and first principles. I have mentioned these in my book and how to improve them, but I will recap them here for reference.
Framing is about defining and redefining the problem before solving it. Many engineering errors originate from a poorly framed problem statement.
Systemic thinking is the recognition that every decision exists within a network of consequences. When you adjust one part, others respond – so be aware of them.
First principles thinking means returning to fundamentals. Rather than relying on established patterns or habits, ask why a rule exists and whether it still applies.

Getting good, then better, then excellent
In Pedagogics of Design Education, Vladimir Hubka and W. Ernst Eder proposed that it takes around 10 years to become an established design engineer, and be able to apply these attributes well.
This same number of years was noted by Anders Ericsson in his work on expertise, later discussed in Talent Is Overrated. Performance in any domain improves through what is called deliberate practice. This is not ordinary repetition. It is the systematic refinement of skill through focused challenges, constant feedback, and reflection. It’s demanding. It forces you to work at the edge of what you can currently do, to fail often, and to analyse why. Over time, the brain reorganises itself to perform at a higher level. And you need to do that for 10 years.
That’s a pro and a con. It might feel like a long time, but that also means you have plenty of time to get good – just don’t waste that time.
You can accelerate your development by being deliberate about what you do. Focus on developing each of those attributes (framing, systemic thinking and first principles).  
And when you are ready, add others like goal analysis, modal shifting, and team engagement. Each can be developed in the same way: by being conscious of when you are using it and when you are not.
​
So what’s the best plan for you?
First off, awareness converts routine work into practice. So simply being familiar with the attributes (re-read my book to remind yourself) will set you on the right path.
But if you want structured exercises, then take a look at my website: cjsteele.com/engineering-expertise. I have developed and shared exercises designed to help you integrate deliberate practice into your day-to-day work. You can also use the AI system Ingeny, which is in development so you can help with that development, to run an audit of your current skills and identify where to focus next.
And if you want to combine your development with your daily activities, then be intentional at work. Improvement in engineering is not automatic – so don’t assume you will just get better with experience – instead, focus and make work work for you. For each engineering action you take at work, ask yourself: which of the engineering attributes could I or should I use here; how can I best use them; have I used them incorrectly in the past; how can I avoid doing that again?
Think again of the engineer you admire most. Their skill did not appear overnight. It was built through years of structured effort. You can do the same. With ongoing, focused practice, you can reach the same level of mastery. Actually, you have more support than they did – The Global Engineer was not around for them – so you can surpass it.
Becoming a global engineer is the ultimate upgrade. It does not rely on talent or luck. It comes from the decision to practise with purpose, to learn continuously, and to treat every challenge as an opportunity to refine how you think and create.
Good luck with it and let me know if I can ever help.

You have likely heard of design for manufacturability, design for sustainability, design for servicing and design for recycling. You can also work out what each is about. You have likely also heard of “design for X”. Where you substitute X for whatever is important to you.
 
But have you heard of “design for design”?
 
It seems an odd concept, but you have probably already done it. Maybe it was for the best, and maybe not – but I will talk about that later.
 
In design for design, we make a design decision early on in the engineering process so that the rest of the design task is easier. For example:

• A team designing a race car on a limited budget (for both time and money) specifies that they will design a space frame instead of a monocoque. Thus, the analysis process and adjustments of the design to accommodate ongoing changes in other subsystems are easier. Making the overall design project easier.
• An engineer who needs to develop a seal between two existing parts decides on the use of silicone tooling and polyurethane so that a complicated shape can be made that works around those other two parts. The seal might be more expensive to produce and maybe more time consuming to install, but the design process is now faster and easier because there is only one part to be designed as opposed to three. This implies that time or design budget were limited.

 
You have likely noted in the above that there is some external reason that mandates the design be completed quickly. Therefore, the engineer makes decisions that will make the design process faster. You could also argue that this is actually part of the development of the design brief – and not design. But given things such as coevolution, there is actually no clear definition of when the brief development ends, and the design process starts. And one could argue that a design brief could also be designed – potentially another example of design for design that has been happening in engineering all along.
 
And this all seems reasonable – although not always ideal – it would be good to always have the time and resources to implement an optimal engineering solution.
 
However, what about times when design for design is not reasonable?
 
And have you been guilty of this?
 
Some other examples of design for design:

• An engineer dislikes sheet metal parts – such parts are not precise and this engineer has mild OCT – so all parts are designed for machining.
• An engineer enjoys designing with surfaces in CAD so creates parts with convoluted shapes that justify the use of surfaces. The official reason for the convoluted shapes is aesthetics and stress minimisation.
• An engineer in a design house contracted to develop a tool set for a market niche chooses to design new metal forgings (as opposed to just custom over-mouldings for existing forging) because they are excited by the notion of designing hand tools from scratch.

The above examples show that sometimes design for design is not about making the design process easier, but, instead, about making the design process more enjoyable.
 
By the way – I have witnessed all of the above examples firsthand.
 
So next time you are making some early decisions for how you will go about tackling an engineering challenge (and designing for design), ask yourself if you are doing it to make the process more efficient or just more enjoyable.