This article is another part of the retro-engineering series. Where we take a look at engineering efforts of the past to find insights into the generalities of good engineering practice. This then lets us become better global engineers. This time we will explore the time a group of General Motors (GM) engineers were engaged to develop what many consider to be the first true heart pump.

If you want to read more about this project, then take a look at this article in the New York Times.

In summary though, a team of engineers from GM developed a heart pump that, on July 3, 1952, was used in the first successful surgery where the patient survived while a mechanical heart maintained blood supply. This was a major step forward in open heart surgery.

The first thing that I note about this project was that it was an automotive company that was engaged. I understand that GM was and is a large company with many capabilities, but I would also think that a company that specialises in pumps would be better suited.

So why was GM the company of choice for this project?

It was because, in 1949, Charles E. Wilson, a GM president, was also the chairman of the newly formed Michigan Heart Association. And this was because Wilson had a major interest in heart disease. If he did not have such an interest, then he would not have been a member of the association and unlikely to have been approached. Who knows who would have then been engaged or if the project would have even progressed at all.

The lesson here for the global engineer, have other interests and network so that you can be a part of more opportunities.

So that explains the first step – finding out about the project and being invited to join – but what about the decision to actually get involved, and take on such a challenge?

This is an example of understanding the transferable nature of engineering fundamentals.

“We have pumped oil, gasoline, water and other fluids one way or another in our business,” wrote Edward V. Rippingille Sr., the leader of the team of engineers and researchers who developed the heart pump. He wrote further, “It seems only logical we should try to pump blood.”

There are indeed differences to how blood and Newtonian fluids behave, but, at the same time, lessons from pumping the latter can be applied to pumping the former. Rippingille showed the ideal global engineering perspective that one should not assume a new field is completely foreign and off limits to them. Instead, it was realised that there are fundamental commonalities, and that these can be used when moving from one field to a new one.

But still, it was different, and those involved were wise enough to understand this. The General Motors Research team started by reviewing almost everything that had been written anywhere on the subject. Further, Rippingille travelled extensively, examining various pumps that had already been made for such use but had failed for one reason or another. This shows an at least implicit understanding of the importance of systemic thinking and first principles. By studying the prior art, an engineer can quickly acquire the respective domain knowledge needed for systemic thinking and use of first principles. And that’s what would have been achieved by reading prior art and looking at what others had done.

But even then, with all that research done prior, it was not a linear product development process.

Over a period of 30 months, 6 to 10 concepts were built and tried – and 84 dogs were lost through testing. For this project to work there was funding from The Michigan Heart Association and GM had provided support as a public service. This commitment and support did not seem to waver after the first prototype. Thus, there was an implicit understanding of the need to implement solutions to better understand the challenge – many call this iteration, but, in contexts like this where the challenge is new, the global engineer knows it to be co-evolution. And initial failures are not just one more step to success, they are an essential part of defining both the challenge and the solution.

Despite the example of engineering expertise noted above, there was some hint of cognitive laziness or automatic association.

Sometime later, Dr. John W. Kirklin from the Mayo Clinic, who was conducting research into heart-lung machines, reviewed The Michigan Heart Pump and one that had been developed by IBM. He noted the former looked like a car engine and the latter looked like a large computer. This led to some thinking the engineers actually miniaturised a V12 for the job. In reality, this was more likely a case of fixation – where a designer has ideas in their head that they do not realise they have and that they and can’t shake. These are not always bad – and in this instance it might have allowed the engineers to focus more of their engineering efforts on the real challenge – moving blood.
​
In summary, the case of The Michigan Heart Pump is an excellent example of global engineering expertise: engineers networked, found new opportunities, understood the fundamentals, leveraged existing knowledge, understood what it really takes to tackle such a challenge, and let their fixation from prior experience reduce the cognitive effort. It is something that you and I can use as a reference for engineering best practice.

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. 

This is the first engineering product review article I have done for this series. It’s a bit like the retro engineering articles, where we look at a previous engineering system to find examples of engineering expertise, but this time we take a look at a current product.
In this article it is the Henson Razor.
Summary of the Henson Razor
The Henson razor is designed around the precision mounting of a standard flexible blade. Further, the head is designed to create an intuitive alignment to guide the user. By mounting the blade precisely and guiding the user with alignment, the razor will shave the hair away without excessively scraping the skin.
I have used this razor myself, after being impressed by their explanations of the design and demonstrations, and agree with others who have reviewed it highly – it is an excellent razor.
So how did they create such a razor?
When you read over their website and watch their videos, you see numerous examples of great engineering practice.
Outcome-Driven Innovation
They definitely showed a Jobs To Be Done perspective and started with the user. They were able to pick their design goals:

• Minimise cuts on the skin
• Minimise the length of hair left after a pass of the razor
• Minimise waste and cost – not like plastic razors
• Minimise build-up of lather and hair to minimise the need to clean the razor while shaving

First principles
To minimise cuts and minimise the length of hair left after a pass of the razor, the designers knew that a well-controlled blade gap (the space between the blade edge and the leading surface of the head) and well-controlled blade exposure (how much the blade protrudes from the surface of the head that contacts the face) were essential. Not just nominally, but along the length of the blade.
Good control of location of the blade means precise manufacturing methods like machining.
Further, a bent blade is more rigid than a flat one. Therefore, if the blade is bent, then it will have more inherent rigidity.
In addition, a 30° cutting angle has been found to be the most comfortable for use.
Skin is more compliant than metal so it can be expected that the skin being shaved can align, at least to some extent, with the shaver surface.
Framing
In this instance, the framing became apparent given the above: design well-controlled machined parts that securely connect, and control the blade location so that it is bent to 30° at the cutting edge.
This does not make for a stereotypically ideal product – it is not well aligned with mass production methods for low cost – but it is well aligned with reality. Both commercial (what users want) and physical (how razors perform).
Systemic thinking
The designers noted that standard razor blades are ubiquitous and well controlled in their dimensions. Thus, there is an opportunity to leverage these in the design and there is no need to design or produce the actual cutting edge.
The head of the razor was designed to mount the blade as well as let the hair and lather flow through – achieving two goals with the one part.
Goal analysis
The above shows the core attributes of the expert engineer (first principles, framing and systemic thinking) at play. However, as the product (including the commercial aspects) was developed, other opportunities presented:

1. There was the chance to augment the prestige of the product by noting it is made to the same standards as aeronautical parts.
2. Anodization allows for a range of colours, which suits a market that likes customisation.
3. While the razor is expensive, it will last longer and uses cheaper blades so the lower long-term cost is now a feature.
4. This also allows for the eco-friendly nature of the product to be a feature as well – less waste (especially plastic).

Things to note
While I would argue that the Outcome-Driven Innovation was the start of the journey here (even if the engineers themselves do not know this term), I would not argue that the first principles, framing, and systemic thinking occurred in the order I covered them. It is more likely that these actions coalesced – along with the goal analysis.
Because the process started with the needs of the user, it became very easy to sell the product based on its features. This is a lesson for all engineers. If you are clear on what needs to be done, then it is very easy to explain the benefits of your proposed solution.
I have covered this product because I think it is a great piece of engineering. I have no links to the company – apart from being a customer – and I received no income for writing this article. I would recommend the product, but I would first recommend that you take a look at their website yourself to see how they developed this razor.

The importance of politeness for a global engineer might seem apparent. In different cultures there are different types of etiquette and thus different definitions of being polite. However, you might be surprised by its importance in engineering in general and how it can be a double-edged sword.
In this edition, I am going to explain first of all why politeness is important for all engineers, how it can also be problematic, and how to manage both extremes within a global engineering context.

First the good: So why is politeness important for engineering?
When we are polite, we ensure we act in a manner that keeps others engaged. Think about times when someone has been impolite to you. Even if they did not mean it. You felt less inclined to engage with that person. That in turn means you are less likely to share your ideas with them to gain input (preventing the identification of issues or the generation of new ideas). You are also less likely to contribute to anything they are working on (meaning they could encounter issues that would otherwise be noted earlier, or they will miss out on other ideas that could have been generated).
In short, politeness allows you to engage better with others so that you can improve your broader understanding of the engineering challenges you face. This is very important for concurrent engineering and shared situational awareness – both of which are related to systemic thinking. But it can also help with leveraging other people’s understanding of first principles and considering new frames.

Now the bad: And how can politeness be a problem in engineering?
As important as politeness is to good engineering practice, the success of any engineering system depends upon the fundamentals of reality.
The general goal of politeness and manners is to help us get along with each other so that everything is better ordered and more effective. That’s why we can feel that raising issues will disrupt the order of things.
But if you do not call out every issue you can, then there is a greater chance of an engineering system failure. Sometimes our politeness (sometimes in the guise of etiquette) will dissuade us from saying anything. It does not feel right to point out an issue in something with which everyone seems happy, or at least not too unhappy; even though we know the implications.

So what do we do about this in the global engineering context?
The most impolite thing you can do to someone is to not involve them. So get into the habit of thinking about who should be involved in the development and implementation of whatever engineering system upon which you are working. And then, of course, involve them.
How you involve them, however, can be very culturally dependent. Some cultures prefer you talk to the person’s manager to gain permission first. Some cultures have very clear “rules” on when you should and should not talk to someone – maybe you can talk to them during lunch or maybe you can’t. These are nuances you will need to manage on a case-by-case basis. However, it helps to err on the side of caution – you do not upset people by being too polite.
The next most impolite thing you can do is involve people who do not need to be involved. So also ask yourself if someone really needs to be involved or if you are insulting them because they have bigger issues to deal with. The CEO wants to know that welds are being properly checked, but they likely don’t want to spend their time reviewing the top 5 non-destructive testing machine technologies you have selected.
A system that can help with this is RACI. You might have heard of this – it is fairly common – but don’t worry if you have not – it is a simple system that is ideal for formalising this type of politeness. RACI is where you determine and document: who should be Responsible, who should be Accountable, who should be Consulted, and who should be Informed. Once you take this step, this system will compel you to think more deeply about how to best work with your colleagues and compel you to keep everyone informed. No-one feels left out, and no-one is bogged down in insulting minutiae.
Also, if you do this right (so take your time with it), then those who might otherwise feel they can’t speak out will be actively consulted. By having the RACI documented and shared, people know that they are expected to give their thoughts – and maybe even be accountable if they do not. This helps give them the confidence to speak up without feeling impolite.

Many engineers hope that they will come up with an invention that will be the foundation of a successful business. A business that will lead to wealth and their own legacy. However, this does not happen that often. And I know engineers who have tried taking this path, but failed, despite their excellent engineering ability.
What went wrong for them?
They had a good idea. A clever idea. One that only few could come up with. But it was not something that was needed – it was not the foundation of a business.
In this article, I am going to explain the difference between a clever idea and something that is a worthy invention. And from that, the mindset you need to ensure any idea you pursue will have a much greater chance of success.
The first problem is that people can get caught up in their invention. They like it, and they assume (or hope) that others will like it too. All they need to do is explain it to everyone – then everyone will want it.
But that’s not how it works. No matter how clever the idea is, others will not care about it unless it makes their life easier.
So the question is not:
Is this a good idea?
The question to ask is:
Who and how does this help?
And then, even more importantly:
How much does it help them?
If you can’t provide a solid answer to the last two questions, then your invention is just a clever idea – not something that will be the foundation of a business.
Don’t start with the clever idea. Don’t think that if you just keep on thinking, you will eventually come up with a great idea for an invention that everyone will want.
Instead, start watching the world around you and asking:

• What are people struggling with?
• What do people keep complaining about?
• What takes too long?
• What costs too much?
• What needs too many people?
• Where are resources wasted?
• What breaks too often?
• What is done badly because everyone has simply accepted that this is the way it is done?
• What makes people worry?

With this focus, you will have a genuine issue that you can focus on.
If you have read my earlier articles, then you will note how this is similar to outcome driven innovation, as developed by Anthony Ulwick. You don’t start by asking what product you can invent. You start by understanding what people are trying to get done. Then you understand where they are struggling to get it done.
That is much more powerful.
Because then the invention has a job.
It is not just a clever thing looking for somewhere to belong.
Have you ever seen the movie Robots? It’s a good movie so check it out when you get the chance. There is a successful inventor character called Bigweld who has the phrase:
See a need, fill a need.
That saying practically summarises this whole article in one sentence.
This mindset also changes how you should think about patents. Another trap for the engineering looking to invent.
A patent can be very useful. I am not dismissing them. If you have something valuable, and someone else could copy it, then protecting it can matter.
But a patent does not create value.
And it is not evidence that you have a good idea.
I know people who have made this mistake. They had an idea. They thought it was a clever idea. They took it to an investor. The investor said that they would not consider it unless it has a patent.
So they got a patent. They spent money. A lot of money.
And then it all failed – the investor was not interested once they heard about it.
Because it did not solve a problem.
If someone asks you for a patent first, then do not consider them a suitable investor. Instead look for someone who asks:

• What problem does this solve?
• Who has this problem?
• How often do they have it?
• What does it cost them?
• What are they doing now to deal with it?
• Why is the current approach not good enough?

And then asks:

• How does your invention make that better?
• Does it save time?
• Does it save money?
• Does it save resources?
• Does it reduce risk?
• Does it remove effort?
• Does it make something easier?

That last one is probably the simplest way to think about it. Most inventions that matter make something easier in some way. Not always easier for everyone. But easier for someone who cares enough.
And that is where a business can start.
There is another useful point here. If you really do have a good idea, you should be able to get interest from people who fund ideas.
I have heard this from multiple people on the financing side of inventions. If the value is really there, funding can be found. If the idea clearly solves a valuable problem, then people with money will be interested.
Investors will not always be right, but they see a lot of ideas. They see a lot of people who are convinced they have something. They are trained, or at least experienced, in looking past the excitement and asking whether there is a commercial reason for the thing to exist.
That means their response can tell you something.
If a professional investor can quickly understand the value, that is a good sign.
If several of them cannot, that is also a sign. Either this is not going to succeed, or you have not explained how your invention saves people time, money, resources, etc.
And you need to be open to either possibility.
Do you need to refine your presentation, or, do you need to move on to another idea?
This is difficult because your invention can become personal. You have spent time on it. You have thought deeply about it. You might have imagined the business it will spawn. You might have imagined the success. You might have imagined the legacy. And you think nothing need change – the path to success is clear and obvious.
But it’s not going to be like that.
So you need to change something. Maybe the way you explain it. Maybe the whole idea.
Either way, be like Bigweld – looking for problems first -– see a need fill a need.

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.

Ever since I came across it, I have been amazed by the utility and power of dimensional analysis. While many engineers vaguely recall if from their degrees as “some fluid mechanics thing”, I have used it to assess noise generated by spa pumps; optimise machine elements; augment the Design Of Experiments (DOE); review the potential to change a pressure sensor design; recall a formula in an exam that did not have a formula sheet, but did list key constants and their units; and assess the potential of a universe with different fundamental laws.
Because it can do so much more for engineers than would “some fluid mechanics thing”, it is a tool that any global engineer should master so that they can quickly adapt to new challenges. And that’s why dimensional analysis is the topic of this article.
The Universe Does Not Know What a Kilogram Is
The first thing to understand is that dimensional analysis is not really about units.
That might sound wrong because it is often taught as though it is about units. You check that metres are on both sides of an equation. You make sure seconds cancel out. You confirm that you haven’t added a force to a velocity and hoped nobody would notice.
That’s useful. But it is not the main power of the technique.
The real power is that dimensional analysis gets underneath the units.
The universe does not know what a metre is. It does not know what a mile is. It does not know what a second is or what a kilogram is. These are human inventions. They are labels we use so we can communicate consistently with one another.
But the universe does understand relationships.
It understands ratios.
If a pendulum behaves a certain way, it does not behave that way because we measured its length in metres instead of feet. If a structure vibrates at a certain frequency, it does not care if the mass was recorded in kilograms or pounds. If a fluid produces drag, it does not care if the engineer prefers SI units or imperial units.
The phenomenon is the phenomenon.
Our units are just our way of describing it.
Dimensional analysis works because it forces us to describe physical systems in a way that is independent of our arbitrary measuring sticks. It asks: what are the fundamental types of things involved here? Length. Time. Mass. Temperature. Charge. Maybe a few others depending on the problem.
Then it asks: what combinations of these things can actually matter?
That question is far more powerful than it first appears.
It is so powerful that even if the universe were to reform with different laws, dimensional analysis would still work. The laws might be different, but once there are quantities that interact, those quantities would still need to relate to each other in dimensionally consistent ways.
This is why it feels like cheating.
You can sometimes know something must be true before you know why it is true.
Rayleigh Knew This
This is not a new trick.
Lord Rayleigh used dimensional reasoning in the development of what is now often called Rayleigh’s method of dimensional analysis. He used it to explain why the sky is blue. His method is one of the classic approaches taught alongside the Buckingham Pi theorem, and Rayleigh’s method is commonly described as an early method of dimensional analysis.
In simple terms, Rayleigh’s method assumes that the dependent variable in a physical problem can be expressed as a product of the relevant independent variables, each raised to some power. You then solve for those powers by requiring the dimensions on both sides to match.
That sounds like a mathematical trick.
And in one sense it is.
But it is also more than that. It is a way of letting the structure of reality constrain your thinking before you do any testing. It tells you what forms of relationships are possible and what forms are impossible.
That is the part many engineers miss.
They think dimensional analysis is just something you use when you cannot remember the formula.
But it is really something you use when no formula exists.
Why People Think It Is Only a Fluid Mechanics Thing
The reason many engineers think of dimensional analysis as “some fluid mechanics thing” is understandable.
It is used heavily in fluid mechanics because fluid mechanics is hard. In fact, turbulence is so difficult that even with modern mathematics and computing power, we still cannot simply solve many turbulent flow problems from first principles in the nice clean way we might like to.
So fluid mechanics needed dimensional analysis.
Engineers needed Reynolds number, Mach number, Froude number, Nusselt number, Prandtl number and many others because we needed a way to understand and compare systems that were too complex to solve directly.
This is where dimensional analysis became famous.
But this also created a problem.
Because people saw the technique being used in fluid mechanics, they assumed the technique belonged to fluid mechanics.
That is like seeing a spanner used on a car and deciding spanners are only for cars.
The tool was useful there because the problems were hard there. That does not mean the tool is limited to that domain.
Dimensional analysis can apply anywhere physical variables interact.
Machines. Structures. Heat transfer. Acoustics. Electromagnetics. Manufacturing systems. Biological systems. Economic systems even, if you are careful with what you mean by dimensions.
And that should get your attention.
Because global engineers are constantly being thrown into systems they have not seen before.
Why Scientists Often Do Not Seem to Use It
There is something else interesting about dimensional analysis.
It gives insight without always explaining the mechanism.
That makes it extremely useful for engineers, but perhaps less satisfying for scientists.
A scientist often wants to know why.
Why does the system behave this way? What is the underlying mechanism? What is the causal structure? What is the theory beneath it?
And that is appropriate. That is science.
But engineers often need something slightly different.
An engineer needs to know what to do next.
Can I scale this? Can I reduce this? Can I make this quieter? Can I make this cheaper? Can I make this more reliable? Can I change this variable and get enough benefit to justify the cost?
Of course, the engineer would also like to know why. But if the bridge needs to stand up, the pump needs to be quieter, or the machine element needs to survive another duty cycle, then insight that supports a decision is already valuable.
This might be why dimensional analysis seems underused in scientific research.
I have only seen one paper where dimensional analysis was used in a way that really stood out to me, and I have only heard one physicist talk directly about using it as a research tool. That does not mean scientists do not use it. Clearly some do. But it does mean it does not seem to be emphasised as much as its power would suggest.
Engineers should not make the same mistake.
We do not need to wait until we can fully explain the phenomenon before using the insight.
How Engineers Can Use It
So how should an engineer actually use dimensional analysis?
The first use is to partially solve the relationship between variables.
Suppose you think a result depends on five or six variables. Without dimensional analysis, you might feel you need to test all combinations. That quickly becomes impossible. If each variable has several levels, your experiment count explodes.
But dimensional analysis can reduce the number of variables by combining them into dimensionless groups.
This does not usually solve the whole problem.
You may still need experiments. You may still need simulation. You may still need judgement.
But you need far fewer experiments than you would have needed otherwise.
This is where it works beautifully with Design of Experiments. Instead of designing experiments around raw variables, you can design experiments around dimensionless groups. You are then testing the structure of the phenomenon more directly.
It also works well with simulation.
If physical testing is expensive, slow, or difficult, then simulations can be used to explore the reduced relationship. You can use dimensional analysis to define the form of the problem and then use simulation to fill in the missing functional relationship.
That gives you something very close to a formula for optimisation.
Not a perfect formula necessarily.
But a useful one.
And useful is often what engineering needs.
Finding the Levers That Matter
Dimensional analysis can also tell you which dimensions you can change to get the effect you want.
This is one of the most valuable engineering uses.
Some variables give you much more bang for the buck than others.
If a quantity depends on one variable squared, another variable to the half power, and another variable inversely, then you now know something important. You know where the leverage is likely to be.
This helps prevent wasted effort.
Engineers can spend a lot of time changing things that are easy to change, rather than changing the things that matter. Dimensional analysis helps you see the structure of the problem before you fall into that trap.
It can tell you:

• This variable probably matters a lot.
• This variable probably matters, but weakly.
• This variable might not matter at all.
• This combination of variables is what you should really be thinking about.

That is powerful.
Especially when you are looking at a system you have never seen before.
The Global Engineer Advantage
This is why dimensional analysis belongs in the toolkit of the global engineer.
A global engineer cannot rely only on familiar systems.
You might find yourself working on a manufacturing problem in one country, a maintenance problem in another, a product issue somewhere else, and then a forensic investigation in a completely different industry.
You will not always have the right formula.
You will not always have the right standard.
You will not always have someone nearby who has seen the problem before.
So what do you do?
You start from first principles.
But first principles can be slow if you try to derive everything from scratch. Dimensional analysis gives you a shortcut. It lets you frame the problem quickly. It helps you identify the variables. It helps you reduce the complexity. It helps you see where  experimentation or simulation should be focused.
Dimensional analysis does not make you clever by itself. But it gives a clever engineer a way to move faster through unfamiliar territory.
And that is exactly what global engineering demands.
How to Master It
I cannot explain dimensional analysis fully here.
If I tried, this article would become a textbook chapter, and probably not a very good one.
But I do hope I have motivated you to take it seriously.
Not as something you vaguely remember from fluid mechanics.
Not as a unit-checking exercise.
Not as an academic trick.
But as one of the most powerful first-principles tools available to engineers.
If you do want to master it, then I strongly recommend having Applied Dimensional Analysis and Modeling by Thomas Szirtes in your book collection. The book provides mathematical background, procedures, and a wide range of engineering and applied science applications for dimensional analysis and dimensional modelling.
Dimensional analysis is one of those tools that can change how you see engineering problems. Once you get used to thinking dimensionally, you start seeing hidden structure everywhere.
And it might be one of the easiest ways to start using first principles properly.

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!

If you want to become a great engineer (particularly a great global engineer), then there is one capability that matters more than most people realise.
It is not domain knowledge. It is not even intelligence. Most people think of those.
It is your relationship with time.
This idea is explored in The Time Paradox, by Philip Zimbardo and John Boyd. I also noted this in my book. The Time Paradox examines how people orient themselves toward the past, present, and future; and how those orientations shape behaviour, achievement, and satisfaction.
The important orientation I am talking about here is the future focus – because of its link to successful people.
The key to the future focus is the attitude that what you do now will pay off in the future.
You don’t try to frame problems, or apply first principles, or think systemically, see no immediate change in outcome, and then think: well, that didn’t work; what a waste of time!
You work on these skills now, and tomorrow and the day after that. Knowing that each time you do, you get a bit better at it.
If you go to the gym each day and lift weights, then you’re going to get muscles. If you keep on working deliberately on developing core engineering skills, then you’re going to become an excellent engineer – and keep getting better.
You probably already have a strong future focus – but there is likely room for improvement.
Because you are an engineer, you had to get through your degree. You gave up a significant number of years to invest in your engineering knowledge for a better outcome.
Still, you might have just taken it one step at a time or simply responded to each task put in front of you during your studies – viewing this time as a student as simply what you do and making the most of the present.
Think now about how you viewed this when you studied. Were you thinking about how each action was going to make for a better future or were you just doing what you did and making the most out of your situation at the time? This will help you work out your future focus tendency.
Does it work?
Have you ever noticed some people who are not that bright, but have still been successful?
You have likely come across people where you have thought “How did they get to that level?”
They simply do not seem to have that much going on upstairs and yet they have a senior role.
They might have been lucky, but the likely had a strong future focus. So they were able to keep on working on mastering key skills that were needed to get the role they wanted – and they are probably still working on getting the next role.
That can be you!
But what could be stopping you from having this perspective.
Have you ever met someone who just seems to react to everything? They don’t plan, they never seem organised, and they never seem to just pull it together.
These are people who have no future perspective. The things that rob people of a future perspective are:

• Culture – some cultures are more hedonistic, and they focus more on enjoying the present.
• Stability – if you come from a place or time that was economically or politically unstable, then you learn that there is no benefit in long-term plans. You simply focus on surviving each threat and stay ready for the next.
• Bad luck – some people have just had plan after plan invalidated by circumstance. Probability says it will happen to someone – even in a stable place and time. So that someone has misfortune, and then they lose their future focus.

Ask yourself now if your background discourages a future focus. If it does, then you know you need to start thinking more about how your actions now will pay off in the future. Especially when it comes to improving your engineering skills.
If your background does encourage a future focus, then you can probably still improve it further.
You have likely heard about the idea that you need ten thousand hours (or ten years) of practice to become skilled at something. So you likely know, logically, that time is needed. But is it having a strong future focus that allows you actually to put that time in – and keep at it after that.
So think now about maintaining a future focus so you can stay on the journey to engineering excellence and all that will come from it – be it material or personal gratification. 

As an engineer, you probably don’t like the documentation side of things. You should at least see its value, but, in my experience, engineers are usually not fans.
We know that it protects the organisation, supports future work, and helps others understand what we have done. And yet, under time pressure, documentation is often the first thing to be condensed, deferred, or quietly abandoned.
This is not new.
But there is going to be a new pressure to create even more documentation.
Not because management suddenly cares more. Not because standards have become dramatically stricter.
But because the value of documentation has fundamentally changed. And it’s because of AI.
How AI Will Make Documentation More Valuable
Historically, documentation has been hard to use well.
It was often written because it needed to be and then just left. People might refer to meeting minutes to double-check their deliverables. But usually, it would be left until there was an audit or something official like that.
And that meant it was written in a way that was only useful for such things. Which in turn meant that it was hard to use for other things. Things like:

• Understanding why an engineering system was set up the way it is. Ideal for new members of an engineering team.
• Knowing if options had been considered or tried – and if they would work or not.
• Explaining how the system works – to engineers and non-engineers.

This was, and is, a great loss. People could easily make the same mistakes or not understand the system well enough to think of improvements.
AI changes that completely.
With comprehensive documentation of an engineering project (design decisions, options considered, trade studies, constraints, assumptions, experiments tried, and outcomes), it is possible to interrogate all of it quickly.
Not by reading everything line by line, but by asking the question you want answered.
Interrogating Engineering History
Imagine you are looking at an existing engineering system and considering a change.
If you have good documentation, you can now ask an AI system questions like:

• Was this kind of change considered previously?
• What alternatives were explored at the time?
• Was something similar attempted and found to fail?
• What constraints drove the original decision?
• What assumptions were critical—and are they still valid?

The AI does not invent the answers. It mines your own engineering record.
This documentation becomes your operational knowledge.
You won’t repeat the same mistakes and you can better assess new ideas with the knowledge you now have. It’s like you have become the old guy in the company who has seen it all!
Documentation Will Be Demanded More – Because It’s Easier
There is definitely a certain irony here.
The same technology that makes documentation more valuable also makes it easier to produce. Engineers can now:

• Dictate notes instead of typing them
• Generate concise summaries from long discussions and disjointed meetings
• Convert rough thoughts into structured explanations
• Maintain logs with minimal friction

As I mentioned in the previous article on one-pagers, AI can help you turn raw notes into something readable and useful. That capability will remove many of the traditional excuses for under-documentation.
And once that happens, the expectation will shift.
If documentation is easy and highly valuable, it becomes harder to justify not doing it.
For the Global Engineer (and Company)
This matters even more in a global engineering context.
When documentation exists, AI allows it to be repurposed for different audiences.
Language barriers are reduced. Differences in writing style, cultural expectations, and technical depth can be adapted on demand.
That means documentation no longer has to be perfect for everyone. It just has to exist. Making it easier again for an engineer to work anywhere in the world.
It also means an engineering company can be more robust.
Engineering teams change – sometimes when you least expect it.
People get reassigned. Projects ramp down. An entire engineering team gets taken out by food poisoning at a corporate barbecue.
When a new team comes in, good documentation plus AI dramatically reduces the recovery time. New engineers can interrogate the history of the project instead of starting with fragments and assumptions.
Think about all the lunar exploration knowledge that needs to be relearned with the recent efforts to return to the Moon.
Knowledge that can be reused, transferred, explained, and interrogated is far more valuable than knowledge locked inside a few people’s heads. When all past experience within a company is documented and easy to use, it increases the value of the company’s intellectual property by orders of magnitude.
And an engineering firm would be foolish not to demand all knowledge now be documented.
The Shift That’s Coming
Engineers are probably going to be asked to document more than they ever have before.
You might not like it. You might resist. But, as the above shows, the payoff will be real.
The best you can do now is start using AI to make this documentation easier to generate and then be mindful to use AI to access that documentation (and others) in the future.

Let’s talk about how you can use an old and well-established technique to bring your team of engineers (no matter where on the globe they hail from) into alignment of understanding. And without the need for time-consuming meetings that no one seems to be mentally present at anyway.
Recently there have been stories about how Jensen Huang reads a huge number of emails each morning. The story is likely exaggerated – a calculation of the implication of the claims indicates that he would not really be reading the emails. However, there are details about the nature of the emails – written so that the key points can be extracted quickly – and how this allows for a much flatter company structure - Jensen Huang can quickly distil key information for situational awareness without the need for middle management or excessive and wasteful meetings.
He has been described by some as revolutionising management.
But is this really anything new?
Not really – it is a variation on the theme of the established one-pager.
The one-pager you say?
The one-pager has been a tool of business and management for so long it is hard to establish the origin. That’s an indicator of how powerful it can be. Yet many still do not understand the power, and do not use this remarkable tool.
Why is the one-pager so powerful?
It comes down to two things: the speed of talking and the speed of reading.
People can speak about 150 words a minute. They can read up to 300 words a minute.
You can see the power already.
If, instead of asking people to present in a meeting, you ask them to write a one-pager for others to read, then you have just halved the time demands on each person involved.
But there is even more benefit.
Each person can read at a time that suits – allowing them to better manage their time in general. They also focus when they read – instead of sitting in a meeting looking like they are paying attention when they are not (especially if the meeting is an online one when everyone is working on other things anyway).
And not the disadvantages you might assume.
You might assume the use of the one-pager is a one-way thing: no chance to ask questions. But, after reading a series of one-pagers, you, and others, can follow up if needed. Maybe even call a meeting – but this time you know that meeting will be focused, and of greater value.
Excellent record keeping.
If you have a repository of one-pagers for any engineering project or activities, then you have a great record of efforts. This can be excellent to review why certain things have been done, find how to resolve issues solved prior, and to prepare for stage gate presentations or audits.
Nuances in the global context.
If you do choose to try the one-pager in a global context, then you will find that different cultures will write them differently. And none of them will be ideal.
Western-style. Tell ‘em what you are going to tell ‘em, tell ‘em, and then tell ‘em what you told ‘em. The use of this tricolon method does help to drill the point. But it does also mean space has been wasted – you do have only one page after all.
Confucian style. Spiral to the point. Cover the various aspects of concern as you slowly get to your point – like exploring the whole landscape so nothing is missed. It is a good way to ensure coverage, but, as we will learn, it is good to be upfront with the point.
Arabic style. The zigzagging of iteration. The traditional Arabic approach is start each section with a summary of the last and how it links to the new one. It is indeed good to note interconnectedness, but there is limited space so best to be concise.
The ideal style of the one-pager.
Start with the main points to be conveyed. That helps the reader determine if they need to read more – thus saving people even more time. This section should include any thoughts on how others could be affected – so you can be more sure people will know if they need to read on. It should also include what support, if any, is needed from others – you won’t get help if you don’t ask.
Next, provide the detailed information to support the above. There should be no new information here – just details to better explain what has been said. And it could include images, but do not use up too much space.
You can of course stipulate any format you wish. But be careful. When you are too prescriptive other engineers lose their initiative, you can waste space on things that are not important, and you might not get all the details that are actually relevant.
A truly ideal application for AI in global engineering.
“I apologize for such a long letter - I didn't have time to write a short one.” ― Mark Twain
It does take time to write a concise one-pager. Not much more than it should take to prepare for a presentation in a meeting, but time, nonetheless. So anything that can help with that is ideal.
And AI is excellent at taking a list of thoughts, ideas, questions and so on, and then turning them into a polished concise document. I use it frequently in meetings to take people’s individual comments and then turn them into topic-based meeting minutes in an instant.
Not to mention auto-reviewing.
I mentioned above how a collection of one-pagers can make a great record of an engineering project or be used for audits. Well, you can use AI for these things too. If all the one-pagers are fed into an AI system, then you can:

1. ask it about ongoing issues that present,
2. report on the status of specific issues,
3. ask how you might solve a challenge you currently have, and
4. get it to generate larger summaries of the state of a design of a project – ideal for management and induction of new engineers.

Take the time now to think about the kinds of things you could get AI to generate if you had a large collection of one-pagers for the engineering project(s) you are working on now.
And it can translate too!
So anyone in your team can write in any language they like, then have it translated into the language the team uses. It can then also be translated into the reader’s language to help further again to enhance understanding.
You can see now the power of the one-pager as an alternative to having someone(s) present in a meeting – especially as a global engineer.
So if you have ongoing meetings where people update their efforts and you think are not doing their job well, or, people seem to waste time calling a meeting each time they have an issue, then try the one-pager method.
Suggest a layout and encourage people to use AI to help.

This newsletter is all about how you can be the sort of engineer who can work, and be valuable, in any company in any part of the world.
Obviously, to do this, you need to be a good engineer.
But is that all?
This edition is about how being a good engineer can actually limit your ability to be a global engineer.
How is this so?
An interesting piece of research that I note in my book – The Global Engineer – found that people who are competent often fail when deployed in new cultures and places whereas those who are less competent show higher levels of success.
Why is this?
The research found that competent people were unaccustomed to finding things difficult. Because of their competence, life had, on the whole, been easy. Then, in a new environment, where they had less experience, they encountered challenges. This made them feel less adequate – a new feeling for them and one that is unpleasant. They simply could not handle this – and they quit.
Less competent people, who had numerous struggles in life, were, on the other hand, robust. They were familiar with these experiences and the associated feelings. Because of this familiarity, they knew how to push through and carry on. Thus, they were more successful.
The lesson for the global engineer?
Yes, you should always work on your engineering skills. You might even be lucky enough to have had them all the time – or at least for long enough that you can’t recall being incompetent. But, if you do wish to ply those skills in a new context, then be ready for a period of discomfort and displeasure – the type that makes you feel less than you used to feel about yourself and question if you were ever truly a good engineer in the first place.
Ask yourself now these two questions:

1. When was the last time you felt discomfort because your competence seemed lacking?
2. Would you be able to endure a period of such “incompetence” as you moved from one role to another (and it might be because of things outside of the role – say a new country or culture) in your efforts to be a global engineer?

They will help you determine if you have or if you need to develop this toughness to be a global engineer.
For all your engineering ability, it might be this mental toughness, needed to get through such periods, that actually makes you a global engineer.

How do you have the best engineering team?
You might, depending upon your age (or your children’s age) know the song We’re all fruit salad by The Wiggles.
The lyrics note that you can’t make the perfect fruit salad with only one fruit. You need a lot of different types of fruit.
Also, in the lyrics, it is noted that the fruit bowl is the world. Meaning the world is a better place with diversity.

A recent paper published in The Review of Financial Economics  has found that engineers make better CEO. I am sure this is a good boost to your ego right about now, but I thought it would be good to explore this more. This will help better understand what it is to be an engineer and what career options you can consier moving forward.
Fist, the details about the article.
The article, Engineering leadership: A human capital, cognitive‑fit, and innovation diffusion perspective on CEO financial performance, was written by Ehsan Danesh and published earlier this year.  In it, the author examines Fortune 500 firms (2019–2024) and reports that companies led by engineering‑educated CEOs outperform peers on ROA, ROE and net‑income growth, with stronger effects when the CEO has deeper technical education from a second degree.
Why might that be?
In The Global Engineer I argue that three capabilities sit beneath good engineering: first‑principles reasoning, systems thinking, and framing. These aren’t confined to heat‑transfer, structures, or circuits; they transfer to organisation management just as well. They help you strip away noise, see interactions and constraints, and define the real problem before allocating effort. The kind of stuff senior leaders should do when planning what to do next.
It’s also a useful reminder of what a CEO is actually expected to do: set direction under uncertainty, allocate capital across competing options, manage risk explicitly rather than implicitly, and maintain the ability to course‑correct when the system pushes back. Engineers practice this every day: quantify assumptions, evaluate trade‑offs, and take deliberate risk where it is justified. This consistent with what the research found: the performance differences appear where disciplined analysis and adoption of better ways of working compound.
So, if you’re an engineer, take leadership seriously as a future path. You’ll still need to learn finance, governance, incentive design, and stakeholder work, but the underlying structure of your thinking already matches the job. For what it’s worth, I also have a business master’s; it taught me a lot, yet I frequently found my engineering skills providing an excellent base to process and use that knowledge.
Finally, for investors, leadership background is one sensible signal to evaluate a company. When a company appoints an engineer as CEO it’s reasonable to anticipate a different and better approach to problem framing, innovation adoption, and capital allocation. The study suggests those differences can show up in the numbers. So it’s a good indicator of when to buy.
 

From one perspective, all engineers sit somewhere on a particular spectrum. At one end are those who chase the parts of engineering they personally enjoy – often the stereotypical ones. At the other are those who understand the value, satisfaction, and deep quiet pleasure that comes from embracing the entirety of the craft.

The child engineer thrives on the simple. They enjoy the burst of creativity when ideas flow, the thrill of possibility, and the fun of imagining solutions. They love the start of the adventure. But once the idea is “basically there”? They can’t imagine what comes next or the importance of it, for they are children, and their interest fades. They want to move on to the next idea, the next spark, the next moment of juvenile novelty.

The adult engineer, however, has, some time ago, discovered the joy in a broader landscape. They still enjoy ideation. And they also appreciate the deeper, richer pleasures (those that come from seeing an idea all the way through to a proper solution). They take satisfaction in shaping a concept into something real: optimising it so it is efficient to implement, verifying that it is safe when built, ensuring it meets every peripheral need that others down the chain rely on. They document it properly, not because they “have to,” but because this is part of creating something fully formed. They understand that professionalism, like adulthood, carries pleasures that are less obvious to the inexperienced, but far more substantial.

This reminds me of a quote from a man called John Edmondson. He was an advocate of antioxidants and physical challenges – at 47 years of age he managed 5,000 push-ups in 3hrs 18mins. He once said, “winning is boys; killing is for men.” By “killing” he meant killing the challenge in front of you – such as 5,000 push-up or the hill you plan to run up. It could also mean the engineering challenge in front of you. The child engineer will win by coming up with an idea. The adult engineer will kill the challenge – and implement a total solution.

Other contrasts between the child engineer and the adult engineerThe child engineer will complain loudly about tasks they dislike. They will avoid procedures because “they’re annoying,” or try to work around company standards simply because they’d rather not deal with them. The adult engineer sees these procedures differently. They recognise that standard process is what allows whole organisations to collaborate without chaos. They follow the procedure because doing so supports others. And when they know the procedure is flawed, they challenge it properly, lobby for improvement, and strengthen the system for everyone.

A child engineer has a narrow view of what engineering is: they see themselves as someone who “works on the thing and invents things.” The adult engineer sees engineering as a profession. They think about framing problems correctly, applying first principles, checking assumptions, engaging the right stakeholders, and understanding how their decision today affects manufacturing, construction, quality, service, regulations and safety tomorrow. They experience engineering in its full, interconnected richness—and they enjoy that broader horizon. It is the difference between juvenile pleasures and adult pleasures: both are real, but only one offers lasting depth.

And then there is how they engage others. The child engineer expects others to package information for them in an easy-to-digest way. They share their own information however they like and assume everyone else will interpret it correctly. The adult engineer takes the time to understand what other teams need, adjusts their communication accordingly, and gives people what they require to progress. They also push back when others try to offload their responsibilities onto them—not out of defiance, but because professionalism is reciprocal.

This notion of the adult engineer is universal. These are the engineers who thrive in global environments, where assumptions differ, cultures vary, and clarity, discipline, and respect for process matter even more. The comparative mythologist, Joseph Campbell, spent his life studying patterns that show up everywhere in human experience: archetypal behaviours that transcend local context. The transition from childlike enthusiasm to adult responsibility is one of them – it happens everywhere. And it is exactly this adult mode of operating that allows an engineer to be effective anywhere in the world.

If you are an engineering managerThe distinctions in this article are an excellent reference for your team. Many engineers simply haven’t had someone frame the difference for them. They may not even realise how often they operate as child engineers. Not because of immaturity, but because no one has ever shown them the deeper pleasures of the full craft. Sharing this with them invites growth.

If you want to grow as an engineerTake a moment now to reflect on where you sit on this spectrum. Think through the last few weeks of your work. Did you lean toward the tasks you enjoy, or the tasks that were needed? Did you shape the entire engineering journey, or just the parts that felt good? Did you help the organisation function, or make it bend around you?

Also, consider your environment. Some managers prefer their engineers to remain childlike. This can be a result of culture as well – those that are more authoritarian. Children don’t push back, they don’t question weak processes, and they don’t challenge assumptions – making it easier for a manager to maintain authority. This can feel comfortable for a manager, but it limits you. If your environment rewards you for staying a child engineer rather than growing into an adult one, you may need to consider whether your development requires moving on.

There is far more pleasure in embracing engineering in its complete form. The breadth. The responsibility. The discipline. The craft. The influence. The impact.

So where do you sit on the spectrum?
​
Do you know some child engineers?

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.

I would like to first share the anecdote of what led to me writing this article.
Some time back, I started following a newsletter on LinkedIn that was written by a software engineer. We had a number of interactions within the comments section of a few posts – so I sent a connection request. After his acceptance and after reading some more of my content his message to me was “You seem to have a background in real engineering.”

He was wondering if my content was equally applicable to software engineering.

I had always assumed two things:

1. Software engineers are real engineers.
2. They benefit equally well from what I share about being a global engineer.

However, based on the anecdote above, I realise that some engineers might not make the same assumptions.

I therefore had planned, since then, to write this article – explain that yes software engineers are indeed real engineers and how they too can benefit from things like framing, systemic thinking, and first principles.

However, now seems a more opportune time to talk about this nuance of engineering identity. This is because of the mass layoffs we are seeing in the software space due to AI. This trend and how it affects people in the space – people like software engineers – was reported in the L.A. Times (https://www.latimes.com/business/story/2026-03-06/tech-layoffs-pile-up-as-sllicon-valley-shakeout-continues-into-2026). There is certainly some cynicism about this – the term “A.I. washing” is used, but it is also clear that more and more jobs in the space have been automated.

Does this automation mean that software engineers were never really engineers in the first place?
I recall when CAD became a thing. Many drafters lost their jobs – some of these people were engineers. Some engineers were then expected to do their own drafting or do their own drafting faster – so fewer engineers were needed.

I also recall the introduction of simulation software. Engineers did not need to calculate or experiment as much. Again, more could be expected of fewer engineers, and a company did not need as many engineers.
However, something else also happened. A company could now consider investing in engineers (or more engineers) because there could now be greater returns. Putting 50% more into your engineers could now see 200% more gains in product improvement – and market share or profit margins.

A.I., in the software space, I think, will have the same effect. Applications that once seemed marginal, due to the effort required to develop them, now would seem profitable – because fewer software engineers would be needed to develop the application. Also, larger applications, with even greater returns, can now be considered.

Therefore, the recent events in the software space – while deeply troubling for those who have lost their employment (and I do hope that if you are one of these people, then you find something else soon) – is an indication that software engineers are indeed real engineers. They are going through what the rest of us went through some time back.
​
But we can also look more deeply at what software engineers do and compare it to engineering expertise.

Do software engineers ever frame?
Only all the time. It is often the case that the assumed strategy to create a desired function in an application hit a stumbling block, and a new approach is needed. Also, once the feature is tried with real life users, it is found that the way people actually want to use the application is different from what is assumed. This demands a new approach or frame.

Do software engineers need to think systemically?
Do I even need to answer this? Applications need to run on something – often a diversity of machines – so this needs to be factored in. Some applications have numerous subroutines – these can interact with each other and cause numerous issues if not managed at the systems level. Most applications also run on machines that are running other applications – and you need to ensure they are compatible.

Do software engineers need to use first principles?
I recall talking with a software engineer who was writing code for a simulation package. He needed to understand the differential equations – so he needed to understand first principles. However, once the program ran, he did not know if the results were reasonable or not. So he needed to improve his first principles. First principles also helps a software engineer optimise the efficiency of the methods used to process information. This is all congruent with software engineers needing and using first principles.

After reading the above, and seeing how the experiences and attributes are so similar, it should be clear to you that software engineers are indeed “real engineers”. I would not be surprised if they are sometimes separated from other engineers, and would benefit more from interactions with other engineers, but it still remains clear that they are engineers and they can be global engineers.

There are two types of people in this world – yes, only two.
Those who have their ideas while sitting on the toilet and those who have their ideas in the shower.
It is in one of these times of solitude and contemplation that they ponder things in their life and insights that have grown deep inside the unconscious psyche burst into the conscious mind.
It is painfully rare for anyone to be in the shower or on the toilet during any kind of review or brainstorming session. And even if they were, these sessions are group activities so there is no solitude – is it more the solitude than the place that is important.
For this reason, you are not likely to get all possible insights from an engineering team in any kind of group session. Be it a design review, a scoping activity, a brainstorming session, a risk analysis activity, basically, any activity where you want as many insights as possible to ensure long-term success.
If you are like me, then you have likely had that annoying experience where you think you have considered all issues and perspectives, documented them, assessed them, and then determined a path forward, only to have one or two people come to you with more ideas, issues, or perspectives.
You appreciate that they are sharing these, but it is still annoying that they come to you after you have done all this work.
You feel like you are going in circles and making no progress as you get dragged back each time. You might even decide to ignore them simply so you can progress – even if it is not the most optimised path you are taking.
The other thing that might occur to you is that while these are the extra ideas that are shared, there could well be other ideas that were had by people who don’t want to bother anyone – given the work that has been done.
It really would have been good to have these ideas presented earlier.
So what to do?
Factor this into the related activities.
Don’t ever assume any brainstorming session, design review, scoping party, gemba walk, risk assessment, or anything else like that will be done in a single sitting. Book one session, run it, give people a break – long enough to have been in the shower or on the toilet – say a couple of days – then have another session.
That way, you can be more sure you have conducted an exhaustive, yet not exhausting, consideration.
Don’t have time for such an approach?
Then simply accept you will not cover everything, and proceed at risk.
Best to factor these extra steps into your plans though.

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? 

This is the next article in the culture check series. The previous ones looked at Western and Sino backgrounds. This time, I am focusing on an Indian background.
As before, this about recognising tendencies that can arise from a cultural, philosophical, and economic environments. You might recognise yourself in parts of this – I have a Bangladeshi colleague who describes his home country as an Islamic nation with a Hindu culture. You might recognise colleagues – depending upon where you work. Or you might see none of it at all. The point is awareness so that we can grow as engineers.
And, as with the other articles, I am focusing on potential limitations. Engineers like problems to solve.
There are three aspects I will consider: the perennial caste system, fatalism, and economics.

Caste and the idea of “the right way” and staying in your lane
The caste system, while officially dismantled and certainly less rigid than in centuries past, has had a long and deep influence on Indian society. It organised life around inherited roles. If you were born into a particular group, there were expectations about what you would do for the rest of your life to make an income.
It is wise to note that there were reasons such systems existed. One benefit often overlooked is environmental continuity. If your family and descendants were going to fish the same waters for generations, you had every incentive not to overfish and protect those waters from others. Long-term role continuity can create long-term stewardship – there is a reason this land was able to support so many people. I am not defending the system; I do not care for it, personally, but it did not arise without logic.
But there were not just expectations about what you would do within your caste. There would often be implicit understandings about how it would be done. This would be handed down from one generation to the next because it was established that it would maintain the balance of things. It could also dictate what you should not do – to make it clear which caste you are in.
Often, discussions about the caste systems focus on organisational and social mobility. That is not my focus here. There is plenty written elsewhere about promotion, opportunity, and structural reform. What I am interested in is something more subtle.
When a society has long embedded the idea that roles come with prescribed practices, it can create a strong psychological tendency toward standard procedure.
In engineering, this can show up as a preference for:

• Established standards
• Accepted methods
• Approved processes
• “The way it is done”

Now, standards are not the enemy of engineering. In fact, they are often essential. They encapsulate accumulated knowledge. They protect safety. They provide consistency.
But engineering excellence is not the same as procedural compliance.
If your background encourages the belief that there is a correct, inherited way of doing things, you may be less inclined to reframe a problem. You may ask, “What is the standard process here?” before asking, “Is this the right problem?” That is a subtle but important difference.
Framing is about questioning the boundaries and assumptions. It is about asking whether the standard process even applies in this context. A cultural leaning toward prescribed practice can sometimes make that reframing instinct weaker.
Still, when translated into engineering, the “there is a way” mindset can become a constraint.
Then there is the issue of being a sensual engineer. I have spoken before about the benefits of experiencing the physical aspects of a problem. Touching the thing that is of consideration, listening to it, taking it apart yourself and putting it back together. In the caste system, for many who become engineers, this physically and be an anathema to one’s caste. Thus, the caste system can sometimes limit the experience and perception an engineer will have of an engineering challenge.

Karma, fatalism, and first principles
Another influence often associated with Indian culture is the idea of karma. Whether one believes in it literally or not, when you grow up in an environment where ideas of fate, destiny, and moral causation are frequently discussed, it can subtly shape perspective.
One possible tendency is fatalism.
If something does not work, it may be interpreted as “not meant to be.” If a project fails, there can be a sense that forces beyond control were at play. Even without conscious belief, this ambient perspective can influence how problems are approached.
In engineering, this can weaken first principles thinking.
First principles require you to assume that outcomes are governed by natural laws. If something failed, it failed because of identifiable causes. If something works, it works because of physical relationships. There is no moral dimension. There is no destiny. There is only cause and effect.
A fatalistic undercurrent can reduce the instinct to dig back to fundamentals. It can encourage trial and acceptance rather than analysis and derivation.
Further, it can result in acceptance of how things are – for oneself and others. This is not what engineers are meant to do. They should always be thinking of ways to make thing better for all.
There is, however, another side to this.
Karma can also be interpreted as personal responsibility and perseverance. If you are being tested, you might iterate relentlessly. You might refine and adjust repeatedly to prove worth. In that sense, the same philosophical environment can produce extraordinary persistence.

Developing economy and the power of jugaad
India has developed rapidly, but it remains shaped by decades of operating under resource constraints. From that environment has emerged something widely recognised and even celebrated: jugaad.
As described in Jugaad Innovation by Navi Radjou and his co-authors, jugaad refers to frugal, improvised innovation. It is the art of making things work under severe constraints.
The classic example is the missed call. You ring someone a predetermined number of times and hang up before the call connects. They see the missed call from you with the set number of rings, and they know to meet you at the station. No cost incurred. Communication achieved.
That is ingenuity.
From an engineering perspective, growing up in an environment where cost sensitivity is constant can create a powerful instinct to optimise for affordability. You become highly alert to waste. You find alternative paths. You adapt quickly.
This is an advantage.
However, constant adaptation can also create inconsistency. Engineering systems often rely on repeatability, traceability, and disciplined configuration control. If ad hoc cost-saving improvisation becomes habitual, systemic robustness can suffer.
Systemic thinking requires you to ask not just, “Does this work now?” but, “What are the long-term interactions across the whole system?” Jugaad can sometimes prioritise immediate functionality over systemic integrity.
​
What does this mean for you?
If you are from an Indian cultural background, then ask yourself:

• Do I default to standard procedure before reframing the problem?
• Do I ever attribute outcomes to circumstance before returning to first principles?
• Do I optimise for cost at the expense of systemic robustness?
• Do I avoid physical aspects of engineering because they I think they are beneath me?

If you work with Indian engineers, or are moving to India, ask similar questions from the other side:

• Am I misinterpreting procedural preferences as lack of creativity?
• Am I undervaluing frugal innovation because it looks informal?
• Am I failing to recognise when persistence is strength rather than stubbornness?
• Do I need to communicate more the value of trying something new and being prepared to be a bit more physical?

As I have said before, your background is not your destiny. But by noting how it affects you, you can improve yourself further.
That is what makes someone not just a local engineer, but a global one.

When going for a job, engineers know they can do that exact job. They know they do it well. They would not have applied otherwise. But when it comes to explaining why they can do the job (be it in their resume, their cover letter or the interview), the message does not always get across.
So the job goes to someone else – likely someone who previously had a job that was almost the same (that’s the go-to-move used by many employers).
You have probably experienced the above yourself.
In the previous article, The Need for Willpower, I talked about how frustrating it can be to have strong global engineering skills while working for people who are certain they know better.
I also said I would explain how you can use these to better explain yourself when going for a job.
So let’s talk about that now.
​
For graduates: proving you understand engineering, not just exams
Graduate engineers often look identical on paper.
Same degree. Same subjects. Same grades.
What interviewers are really trying to determine is whether you understand engineering, or whether you simply learned how to pass engineering exams.
This is where noting framing, first principles, and systemic thinking can give you the edge.
Point to any example you can and explain:

• how you framed the problem,
• where you relied on first principles, and
• how you considered the system beyond your immediate task,

you will then immediately distinguish yourself from the majority of graduates.
Design projects or any work experience during study are best here. They are often the closest thing students experience to real engineering practice: incomplete information, competing constraints, trade-offs, and uncertainty. If you have access to design projects — especially open-ended ones — leverage them heavily.
For example:
“At first I thought this was a materials problem, but after reframing it as a thermal–mechanical interaction, the constraints became obvious…”
or:
“Rather than relying on testing, which would be time consuming, I went back to first principles to inform my decision. I found that…”
and:
“I didn’t want to simply assume what was presented. I considered the broader system for opportunities or risk and found that I could…”
Statements like this tell an interviewer something very important: you weren’t just executing procedures — you were thinking like an engineer.

Experienced engineers: making expertise transferable
For experienced and senior engineers, the challenge changes.
At this level, employers aren’t just evaluating what you’ve done. They’re trying to work out whether your capability is locked to a specific industry, organisation, or economic environment — or whether it travels.
This is where global engineering fundamentals really matter.
Instead of listing achievements, you explain how you think:

• how you’ve reframed problems when projects stalled,
• how you’ve used first principles when standards, precedent, or organisational habit were misleading,
• how you’ve thought systemically to uncover risks or opportunities others missed.

Crucially, you make explicit that these are generalised attributes:
“It should be noted that I was not following standard procedure. They’re engineering fundamentals applicable to all industries. Industries like [INDUSTRY YOU ARE APPLYING TO]. That’s why they apply even when the context changes.”
This is especially important if you’re moving between industries, organisations at different levels of maturity, or regions with very different economic backgrounds. Engineering does not exist in a vacuum — constraints, incentives, and decision-making are shaped by economic reality just as much as by culture or structure.
Being able to articulate that awareness signals depth.

Engineering managers: scaling judgment across people and contexts
For engineering managers — engineering leads, heads of R&D, CTOs — the emphasis shifts again.
At this level, you’re no longer just applying framing, first principles, and systemic thinking yourself. You’re developing them in others.
Strong candidates for these roles can clearly explain:

• what good engineering judgment looks like,
• how they encourage it in their teams,
• and how those attributes need to be interpreted differently across industries, cultures, organisations, and economic environments.

This is where global engineering truly becomes a leadership skill.
A manager who understands that framing, systems, and first principles manifest differently depending on context is far better equipped to guide teams. Not by imposing answers, but by shaping how problems are understood in the first place.
What’s more, the fact that you know what the attributes are of the expert engineer will likely separate you from other would-be managers. You show that you are indeed an expert engineer – as expected of a manager – as well as having the required leadership attributes. A powerful combination you should articulate.

Why this works: labels make thinking visible
A lot of engineers already do these things. But they just don’t label them – making it hard for other to understand or see your ability.
When you say:

• “I reframed the problem…”
• “I went back to first principles…”
• “I broadened the system boundary…”

you’re giving the listener a framework they can link your past actions to – making it easier to appreciate and recall.
I’ve used this approach myself repeatedly when applying for roles. I link all the actions I mentioned to an attribute of engineering expertise. And without fail, people switch on. They understand what I did and how significant it was because I gave it a name and explained the meaning.
If you’ve read my book, you’ll know there are many other attributes worth developing — fixation, attachment, goal analysis, and more — particularly for leadership roles. But framing, first principles, and systemic thinking are the core.
They are the fastest way to make your engineering capability legible.
And once it’s legible, it becomes employable.
Also, if your application involves moving countries, working across cultures, or managing international teams, one book I strongly recommend is The Culture Map. It provides a practical framework for understanding how communication, authority, and decision-making vary globally — all of which directly affect engineering work.
Start mentioning these things in your next application. And all the best with that application too – along with all the others that follow. I hope your engineering career continues to be onward and upward – offering you all you wanted from it.
 

I have mentioned in a prior post about the need for willpower (and how you need fuel) when you are working on improving your engineering skill.
In that case, I was talking about how people find it easier to resist change. And how that in turn can make them feel like weights dragging you down or holding you back.
This metaphorical drag on your progress would sap your energy – and you would seriously need to fuel yourself with quality food so you could push on.
But it can sometimes be even worse than that.
Not only will people resist the change. They will sometimes tell you that you are wrong, that their way is better.
In cases like this, you sometimes need to endure working in a manner that you know is suboptimal until your time comes.
But this has likely raised questions like:

• But how does this come about?
• How is it that people can think they have a better way?
• Do they know something more?
• Should they too have learned about the importance of things like framing, systemic thinking and first principles?

The answers to these questions are:

• Luck
• Unfounded confidence
• No
• Yes

Let’s start with the first aspect, Luck – because it explains the next and so on.
I have also noted in a prior post – on starting your own engineering business – the two important elements of business success: the business model and location. These were noted by the demographer Bernard Salt. He also went on to claim that intelligence and hard work were something the laws of business did not care for – they could never overcome a bad business model or poor location. The reason why I agree with this is not only because it aligns with personal experience, but, because, being a demographer, Bernard Salt bases this assertion on the data on all businesses – not his personal experience with a handful of businesses. Thus, his assertion is objective and universal.
Those engineers who think they know the real core of engineering have been lucky enough to have worked for companies that have been successful. They assume their engineering excellence played a major role – thinking it’s all about intelligence and hard work; having no idea about the importance of the business model and location.
Being so certain company success was a result of their excellence, they can’t help but be confident.
The kind of confidence that means they have not bothered learning more – so they do not know something more.
Even though they should take the time to learn more.
It’s near impossible to argue with such people. They will have stories of how their way saved the company and how that proves they know what’s best.
As you become more informed and a global engineer, you will start to see how it was external factors that allowed for these engineers’ success.
But you will not be believed if you try to explain it. And then the frustration can set in. And all you can do is endure.
This sounds rather bleak – I know. And it is – I have lived it before.
But I have always been glad to know what I know. And I have learned to choose my battles.
And you should too. Value your knowledge and pace yourself as you apply it so you do not fatigue or become bitter. Sometimes the only thing worse than someone with unfounded confidence is a cynic who is always annoyingly right about what’s going wrong.
So next time, let’s talk about how your global engineering skills can get you a better job.