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.

​In this article I want to encourage a habit in you. The habit of staying up to date with the latest in your specific field.
But first, I wanted to take the time to share with you that this is now the second year of this newsletter. The last issue was issue 52 so this one marks the start of the second year – volume II if you will. I did not plan to publish once a week, but, after publishing the first edition, a colleague, Andrew Waterson, said “I hope to see you doing this once a week from now on.” He tells me he does not recall saying this, but that it sounds like something he would say. Regardless, the effect was that I was motivated to keep on writing. So thanks go to Andrew.
I still have more content to come and I hope that past (future) content has helped (will help) you in some way to become a better engineer.
And that brings me back to the focus for this article: how to keep your finger on the pulse of your engineering discipline to stay up to date – or even ahead of the curve.
Obviously, I would suggest you keep reading my newsletter. You can also join the Global Engineer Group to see other posts, and share questions, thoughts and ideas with others. This is a relatively new group, and members are approved so the quality of others there can be maintained into the future. In addition, you can follow The Global Engineer page to be reminded of past articles and other posts.
But that’s general – what about staying up to date with advances in your specific area of engineering?
This is where Google Scholar is one of the greatest developments in the past decades. I recall when it started back in 2004. At the time, when I was doing my PhD, I would not have used it – it simply did not have the coverage needed nor did it have the search functions in the established databases. However, today, it has almost everything and excellent search functions.
Add the alert function and it is even better – you get the occasional (depending upon the specificity of your search term) email letting you know about recent publications on your topic of interest.
My current alert is just one phrase “engineering cognition” – that’s because this is my current area of interest.
You would obviously choose one that aligns with your industry – or the industry you want to get into so you know what skills you need to demonstrate as you make the transition.
As you read the articles you are alerted to, you will come across ideas you can put to use and better understand your industry. You will also have excellent professional development activities to report if you are a registered professional engineer who needs to do this.
Try Google Scholar now. See what the latest papers on your area teach you.
You might need to have a few goes – sometimes the phrases used by authors are not the like the one you would use.
Once you have a search phrase that gives you articles you like, hit the “Create Alert” link. That way you get automated updates. You don’t even need to go to Google Scholar to get the information anymore. You just sit back and wait for it to come to you in your inbox. To be read when suits you.
But you want to make it even easier? Then combine it with ChatGPT (or other AI).
Type this into your AI system of choice:
I would like to know about recent advances in [your area of interest]. Review articles that are available on Google Scholar that have the phrase [the search phrase you found that worked] in them. Then, give me a summary of the major topics covered and the associated findings.
This will be an even easier read. And it will still give you links so you can read in more detail anything that is of more interest to you. But it will only happen when you choose to do it – the email updates are good because you get the reminder.
None of the above is a replacement for structured professional development courses that are curated and delivered by experts (assuming they keep themselves up to date), but it will still keep you better informed than others.
And stop you slipping behind!

In this article I am going to go over 3 case studies from different engineering fields to show:

1. How sometimes you need to resort to experimental methods.
2. And, when you do, how you might, or might not beat the competition.

Case study 1 – Materials Engineering
Are you familiar with the development of the vulcanisation of rubber?
If you are, then you know how remarkable and strange that story is. If not, then be prepared to be amazed or maybe even disappointed at how much randomness can be a major influence over engineering success.
Charles Goodyear had become obsessed with doing something with rubber.
He believed that he was directed by God to take rubber and turn it into something beneficial to humanity. This obsession drove him to bankruptcy numerous times (meaning his imprisonment for a period), and his family into poverty. To top it off, he almost killed himself a number of times experimenting.
Despite the consequences – his obsession drove him on. Some call him an eccentric, but mentally unbalanced could be a better description.
While he had shown technical insights as a child, he had not been given any advanced education.
He was more a tinkerer. And it was a tinkerer’s approach he used to improving rubber.
A number of experiments had shown some promise, but they ultimately failed. Then, either by accident or elimination of other options, sulphur was mixed with the rubber.
This cross linked the molecules in the rubber – making it tough and durable while keeping its compliance.
Some say he called in vulcanisation and some say it was a contemporary British inventor of the same process. Personally, given his religiosity – I think he would refrain from giving praise to any god but his own.
See below for the short video showing a perspective on Goodyear and how he made this discovery/invention.

Something to note. Charles Goodyear did not found the company Goodyear. The company was named after him by others who wanted to recognise his achievement.

Case Study 2 – Electronics Engineering
Are you familiar with the development of the blue LED? Watch the video below if not.

The key points are:

• Shuji Nakamura was obsessed by the development of the blue LED.
• He focused on growing the perfect crystal – to then make the LED.
• He really only ever had hunches.
• He went against the mainstream, and chose to explore gallium nitride over zinc selenide.
• He defied his boss after being asked to stop working on the blue LED due to a lack of success after decades of effort.
• He replaced the use of an electron beam with simple heating to generate light – this was another hunch – and then understood why the electron beam method worked.
• He at times used brute force approaches that were then later refined through adjustments.
• He continues to work on smaller LEDs after winning a Nobel Prize and developing the blue LED.
• No-one else had been able to create a blue LED.

 
Case Study 3 – Marine engineering
Everyone today assumes boat propellers are short. They are screw propellers, but they are not long like other screws. We know this because that’s how propellers have been for over a century. However, as you might infer from drawings by Leonardo Da Vinci, people first assumed screw propellers would be long – like the screw drill bits used to drill holes in wood or screw presses or water screws used to lift water. It just seemed obvious that screw propellers would also be long.
Around the 1830s there were many people exploring improved screw propellers.
One of them was Francis Pettit Smith. He had been fascinated with boats as a boy and later in life reached the conclusion that screw propellers were superior to paddles.
As did many others.
There was thus a competition on to find and patent the best screw propeller.
Most were doing the sensible thing of trying different configurations: pitch, speed diameter, length. They would build a propeller of one combination, note its performance, build another, note the change in performance, and then work out what to try next.
Our man Francis though ended up doing things a bit differently.
He was not known as being the most precise and methodical of his contemporaries. That probably would have been John Ericsson, and if not for what I am about to mention, John Ericsson, while being noted as a contributor to the screw propeller, would have likely been noted as the sole contributor. Thus, Francis was a bit more random than would normally be considered ideal for an engineer.
Despite this lack of method, Francis had the good fortune to have struck a log while testing a propeller on a boat.
This collision knocked the majority of the propeller off – leaving only a fraction connected to the shaft.
Wisdom of the time would have expected the boat to founder. However, instead, the boat surged forward.
Francis Pettit Smith had discovered/invented a far superior screw propeller. The one that was then adopted by later ship builders.
 
What do we take from this?
The above examples show how sometimes we need to use experimental approaches. Our understanding of the natural laws is insufficient. When we do, there is always the chance that someone else will try that near perfect permutation before we do.
Or maybe we will be the ones who try it first.
Regardless, the lesson to take from this is the same. This was not a matter of genius. Effort and commitments certainly played a role – but luck was the decider once those involved committed.
So don’t beat yourself up if you did not win in those circumstances, do not think you are amazing if you did win, do not lionise those who do win, and certainly do not think less of those who did not. Because, in such cases, all you can do is commit and hope.

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

Did you, like me and 35 million other people, watch the last season of Stranger Things?
If so, then did you get annoyed by the scene where an oxygen bottle was used to blow up the Demogorgons/dogs in the hospital? I certainly was – not only did the makers of the show assume oxygen burns, but they even added a “FLAMMABLE” label to the bottle.
It is a common thing in TV and movies where people think oxygen burns.
Unfortunately, even engineers can sometimes make such a mistake.
I recall being involved in a risk assessment at a previous employer that included an inspection of the compressed gas storage cage. There were two parts to the cage – one for combustible gases and one for others. One of the members of the risk assessment group then asked why the oxygen was not in the flammable section. This was not a token member of the team either – like someone from accounts – this was an engineer.
You could argue that we all make mistakes. But when I pointed out that oxygen is not flammable so it should not be in the flammables cage, he looked at me like I was saying something odd.
Then I was seriously unimpressed.
The truth is, we probably did not need separate cages – the storage tanks themselves were very sturdy, and we just needed to ensure they did not fall over or get damaged by other items hitting them – but an engineer in a team dedicated to the safety of the workplace should understand these kinds of things.
This is high school chemistry – combustion needs a fuel and an oxidant (usually OXYGEN!).
I am unsure if this engineer never really learned when studying or if he had been corrupted by mistakes made in movies and TV – as opposed to pointing out the flaws and laughing at those who made it with a haughty disdain like a real engineer should.
Regardless, it shows how important it is for an engineer to have a solid understanding of first principles. So always be brushing up on everything you have learned as well as always learning more.
You could kill people with your incompetence or look a total fool. 

You might have seen the bit by Don McMillan (the engineer who became a comedian) about what it takes to be an engineer.
Take a look if you have not seen it. It’s only a minute and it is funny.

​There is, however, something that this video raises that is noteworthy.
The notion of engineering being quick and dirty.
I think Don McMillan is right when he compares engineering to science. Especially the type that leads to a Nobel Prize – we just can’t wait that long, most of the time, for engineering solutions.
It’s worth noting that we had steam engines powering the industrial revolution before we understood how they worked. If we always waited for the science to be complete, then engineering would not have pushed society along as fast as it has done.
Still, some engineers, I have found, push the quick and dirty aspect more than is ideal.
You can certainly progress a solution to an engineering problem without obsessing over some of the academic questions. And you do sometimes need to start solving a problem to sufficiently understand it.
Nevertheless, your solution should still be sufficient. Sometimes that can mean near enough is good enough. But sometimes the engineering solution is the optimised one. Especially when you are in a competitive industry – due to commercial factors, the nature of the challenge, or maybe regulatory needs. And in this case, while you are not pushing for a Nobel Prize, you need to ensure you have been thorough.
So always be mindful of how refined your solution needs to be given the nature of the challenge and its context.

The article is the second culture check article. The first was about a western background. This one is focused on a Sino background - China and influenced countries/cultures. It might seem extreme to consider one country after considering an entire hemisphere last time. However, China is a big country with a long history – and thus justifies such attention. And, as implied above, the article could also have elements applicable to other countries that have a strong Chinese influence – either through cultural exchange or migration. It is for the reader to decide if this is applicable – either to themselves or those they work with/manage.

Perspective on Knowledge – framing and first principles
There is a cliché about Chinese not being as creative as those from other cultures. However, I can say from my own personal experience working in China that this is not the case. But there is something that can explain why people have this perspective.
It is the perspective on knowledge.

Some view knowledge as something that is external to humans – something to be acquired through exploration. Others view knowledge as something that comes from within humans – those who have something innate and special.

In China, there is a greater tendency to view knowledge as something that comes from within.

This is a result of two broad influences on Chinese culture: Buddhism and Confucianism.

The first brings with it notions of karma – this idea can mean that success is more a function of the character of the person than the laws of nature being understood and used correctly. Being a good person alone would mean that things will eventually work out. The second, often (you will see below why I use the word “often”), extols the value of obeying those in authority for the sake of social (if not cosmic) harmony – that can convey the notion that along with authority comes expertise.

The above can mean that people will be more greatly influenced by ideas that come from those viewed as experts. Therefore, an engineer with a Sino background could be less inclined to consider reframing a problem (or previously presented solution to a problem).

It can also create an environment that is dismissive of first principles. And an engineer might still choose to pursue an idea that is clearly, due to first principles, unviable; solely because someone senior said to. This was something I encountered when doing my research into how cultural background can affect engineering practice.

This tendency for Chinese to view knowledge in such a manner is sufficiently common that a solution, applicable in all disciplines, has already been developed by others.
Folklore precedence matching.

In this process, one looks for an example from Chinese history (or folklore) that is aligned with the approach desired.

Folklore precedence matching for engineering
You could choose to look for something similar to the exact approach desired. But a better approach, I think, is to showcase examples from Chinese history that showcase the approaches aligned with engineering expertise more broadly. These examples can be part of induction, education, training, or regular reminders. Use them anyway you see fit.  

Examples from Sun Tzu.
“The general who advances without coveting fame and retreats without fearing disgrace, whose only thought is to protect his country and do good service for his sovereign, is the jewel of the kingdom.”
The Art of War, Chapter 10 (Terrain)
This shows that the good of the country (company and those who work there) to do service for the sovereign (manager, owner, shareholders etc.) should be what guides actions. That means considering new ideas (framing) and adhering to the laws of nature (first principles); not simply doing as you are told to in hopes of getting approval from others (coveting fame or fearing disgrace).

“There are occasions when the commands of the sovereign need not be obeyed.”
The Art of War, Chapter 8 (Variation in Tactics)
This clearly states that the manager is not all knowing. And an engineer should be free to do as they know is best – using first principles and framing as needed (not to mention systemic thinking, which will come in more detail later).

Example from the Battle of Red Cliffs.
One of my favourite Chinese movies is John Woo’s Red Cliff. And one of my favourite parts is where Zhuge Liang is charged with acquiring 100,000 arrows.
And he needs them fast.
Everyone assumes he plans on finding some way to make them quickly – and they assume he is going to fail. However, Zhuge Liang makes no visible preparations to produce arrows and offers no explanation to his peers or superiors.
Instead, he waits for specific environmental conditions (heavy morning fog) and prepares boats covered with straw. He rows these boats toward the enemy camp, beating drums and shouting at the same time to simulate an attack. Unable to see clearly and assuming an assault, the enemy responds with volleys of arrows. The arrows embed themselves in the straw coverings. Zhuge Liang then withdraws with the needed arrows – collected from his enemy and ready to be returned.
This is an example of the value of the independent expert(s) to get the job done.

An example from Confucius.
Then there is of course Confucius. Confucius is often thought of as someone who encourages people to defer to those in authority – as mentioned above. Also, he is often implicitly viewed as an example of someone who has innate knowledge. Still, he also said:
“In serving one’s lord, one should remonstrate with him when he does wrong.”
Analects 14:22
This implicitly states that there is an objective truth (first principles) and that these should be adhered to.
The above examples provide a way one can leverage Chinese folklore precedence matching to establish a culture and environment aligned with good engineering practice. And this can change the perspective of people at any level within the engineering team. Remind them of these principles and, from that, emphasize the importance of engineers:

1. Relying on first principles to guide their decisions, and
2. framing problems differently when there is value in doing so.

An idea can come from anyone – not just those in authority.

Organisational maturity – systemic thinking
China has progressed economically at an amazing rate over the past decades. There have, along with that, been improvements in regulation, research and development, education, and business management. However, there are still significant areas of China heavily influenced by earlier practices – including those of the communist era.

One practice that is significant in the context of engineering expertise is the division of labour.

When it comes to production, there is no substitute for the division of labour. Early estimates by the economist Adam Smith noted an improvement in productivity of 206 times when using the division of labour.

And it is tempting for managers who have seen the power of the division of labour in production to then erroneously use it in engineering practice. Putting each engineer in their own Dilbert-esque desk and having them focus on one specific task in the engineering process. Because of the large number of managers in China who have come from production, there is a greater tendency for this practice to occur in China.

There are many issues with this approach regarding good engineering practice and outcomes. However, for the engineers in this situation, their ability to think systemically, given they need to focus on a single task all the time, atrophies.

This, based on the experience of a colleague working in China, can be addressed by simply steadily expanding the scope of engineering works. Something that has atrophied from neglect can be strengthened from exercise.

Thus, if you are an engineer with such a background or managing such engineers and you want an increase in systemic thinking, then all that’s needed is a steady increase in the number of systemic issues that are to be factored into any task.

Closing
In the above I have shown how a Sino cultural background, particularly as expressed in China, can influence engineering practice in subtle yet important ways. But it could be useful for Taiwan, Singapore, Malaysia – any part of the world influenced by Chinese migration – or any other culture that shares similar philosophies. By examining perspectives on knowledge, authority, and organisational structure, it shows how framing, first principles, and systemic thinking can be weakened when expertise is overly associated with hierarchy or when production practices are misapplied to engineering work. Importantly, it also demonstrates how Chinese philosophical and historical examples can be used to reinforce good engineering practice, offering practical ways for engineers and managers to align cultural context with engineering excellence.

In this article we are going to talk about how engineers can make huge mistakes when they do not exhibit the attributes of good engineering. And, we will also see how people without engineering training can make better engineers (better than you even with your training) when they do exhibit these attributes.
Thus, this article is both a cautionary tale for engineers and a lesson in how you can always be the best engineer.
So let’s talk about robots – specifically, humanoid robots.
To start this conversation, take a look at the video below to see how this journalist with little science training takes apart supposed engineering and robot experts like Elon Musk. It goes for about 20 minutes, but it is very interesting, it will help inform what I will say next, and does provide a good engineering case study in its own right.

What’s your take on it?
For me, the following were the significant takeaways:

• People like Elon Musk and Bernt Børnich do seem to be victims of attachment – they want the humanoid robot.
• It is not unusual for people to want a human robot servant – the series of times people seemed to want to believe such technology was possible or close to being possible is congruent with such a desire.
• There was at least an attempt by Elon Musk to make it sound like he was being logical – the world is made for humans so robots should be too.
• But I think that is a case of the core psychological principle that all in sales and marketing understand and use – people make decisions based on emotions and then justify those decisions with logic later on.
• The journalist actually sounded more like the expert engineer:
  • Showing no attachment to the idea of humanoid robots.
  • Using systemic thinking by expanding the scope to having multiple robots dedicated to specific tasks.
  • Using first principles to understand the difficulty of bipedalism.
  • Using first principles to understand how much data would be needed for training and why the established datasets are not sufficient.
  • Noting the framing of the designers who conceived and developed robot vacuums.
  • Bringing all of the above together through logic to reach the conclusion, which would also help establish a frame, that robots should be designed for the job that they do – and thus avoid the unnecessary complexity that comes with the humanoid robot.
• While I would not be investing in 1X, I just can’t see their Neo robot going anywhere, I do think that the challenge of producing such a robot could produce some remarkable and valuable spin-off technologies.

​What do we take away from this?

First thing, it shows how easily we can ignore what we know about good engineering practice when there is something that appeals to our emotions.

In a global context, this can be even more significant; different cultures would, because they have different aesthetics and values, likely be emotionally aroused by different things.

If you are in a mixed team, then you might experience your colleagues getting excited by an idea, and then losing all engineering judgement and expertise, that leaves you feeling very uninspired. That means you can bring them back to good engineering practice.

The second thing to note is how powerful these principles of expert engineering – framing, systemic thinking, and first principles – can be. If they allow a journalist with no engineering training outperform Elon Musk, then think what they can do for you as a trained engineer.

So on the other hand, if you are in a mixed team, you might find your colleagues can bring you back when you are excited by something that appeals to you, and only you, due to your background. And that can help you be a better engineer.

Ideally, we can all do this ourselves, but there is no harm in having colleagues who help. And this is more likely in a mixed team.

If you want to know more about mastering these attributes, and you have not acquired a copy yet, then check out my book on the topic.

Think back now about times your attachment to an idea made you forget good engineering principles. Can you stop this happening again; do you wish there had been someone there to point it out to you?

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

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

In this article I will to talk to you about a 3 step process that will ensure you are the type of engineer that gets stuff done – even when relying on other people. And then I will talk a bit more about how this can play out in a global context. Given that there is always an increasing demand for speedier delivery and the world is getting smaller, this can be essential for many engineers.

The driver
Have you ever worked with people who seem relentless and just get things moving? Maybe you are one of these people – in which case, skip to the next section. But it is more likely that you want to be one of these people.

You possibly think they are just demanding or pushy or focused. Certainly you would say that they are driven.

But is it actually a very simple process that they follow to make things happen. And here it is:

1. You want or need someone to do something, so you send them an email and wait a set period (you decide what that is) for a reply to confirm or clarify.
2. If you do not get a reply within that period, then you make a call to clarify and confirm action will be taken – or maybe resolve some issues – before noting the new deadline. You might of course need to leave a message
3. If that deadline is reached or they do not call back, then you go to see them physically (at their desk or office) to talk more about the thing you need done. You then resolve and confirm action to be taken. You probably also summarise in an email so you can ensure there is a shared document of what was agreed, and you can go back to step 1.

As you take in the above 3 steps you can understand how following these will ensure your task (when reliant upon others) will get done faster. You also might be thinking that you would use a messenger service instead an email or you might do a video call instead of seeing them. That’s fine, the point is that you have a process of following up and escalating to ensure tasks are done.

So now you know how to be a driver engineer.

The global context
If you want to be a global engineer, then you need to understand how the above process could play out in other cultures (ethnic, national, company and so on).

Not all cultures have the same take on time. What you consider a deadline others will consider a guide. So consider, when you approach someone at a deadline, if you should be talking like something was missed or like you are just following up to see how things are progressing. Also, the other might happen – the person you are talking to will get annoyed if you don’t give them a deadline that will allow them to prioritise their work.

Cultures will vary in how specific their communication is. You might feel that you have been perfectly clear, but people in other cultures could think you are vague or overly specific (to the point of insulting their intelligence). I think this is less likely in engineering because we can often establish, through physical reality, what details are indeed important. But still, it could be an issue to be mindful of.

Hierarchy is another one. Across different cultures who can rightly ask someone to do something (based on the position of the two people) varies. Therefore, from the onset, ensure that you in a position that is suitable to make the respective request of that person – you might be OK to talk directly to them or you might need to speak to their manager or you might need to speak to your manager who will then speak to their manager who will then speak to them.

Finally, consensus. Make sure you can just ask the other person to do something. It might be that you are expected to engage first to ensure everyone involved agrees before any action is take. The three steps above assume that, if required, you have already done this.

Happy driving
I hope that you now find your tasks, when reliant others, are completed in a more timely manner. Whether you be in a different culture or not.