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.

The last article I wrote for this newsletter elicited a lot of responses. It is the most read and commented upon article in the series thus far. That tells me that many of us have a deep interest in the education and training of engineers. It also revealed something else – many seemed to assume that if you do well on the exam, then you understand the respective theory.
I am going to explore that assumption more in this article: Do good exam marks really mean good understanding?
It’s all on the surface.
When I was an academic and involved in education research, I was introduced to a phenomenon called surface learning. It is where students study to pass the exam as opposed to studying for understanding. We all probably have some experience doing this, where we drilled questions (maybe even used Schaum’s) or we remembered things. Or we know a fellow student who would get good marks, but never seemed to actually understand anything. That’s all surface learning.
You can get away with this when the exam is set such to allow for this.
And many exams are like that.
They don’t assess understanding, just your ability to drill problems to pick up on the procedure and repeat it at speed.
As an example of how pervasive this is, take the time to watch the video below. It features Eric Mazur, a physics lecturer, talking about his students and how shocked he was when he assessed conceptual (read “actual”) understanding after the first year of physics.

Some key points from the video:

• He never asked himself how he would teach.
• He still got high satisfaction ratings.
• He thought the students did well.
• He thought he was a great teacher.
• Exams went well – based on marks.
• He used typical textbook problems.
• When he found that many students at other universities did not learn well, he was convinced his Harvard students were learning.
• He was wrong – it is impressive that he chose to be so scientific about this.
• There was a difference between how students think in daily life and how they think for exams.
• The students used what he called “recipes” (read “surface learning”).
• Once he came up with a better teaching method, one where students actually learned, he does not say anything about how his satisfaction ratings went.

You can infer from this, that his students were engaged in surface learning until he corrected both his teaching style and assessment method.
Surface learning isn’t just about the student it is encouraged by most exams in engineering courses around the world.
As I mentioned in the previous article: many exam questions will list only the variables needed to find the answer. In such a scenario, students only need to recognise the pattern (or the recipe).
This is why grades don’t always (and often don’t) reflect understanding. The exam format can encourage procedural fluency at the cost not conceptual understanding.
But what to do about it now?
If you would like to improve your conceptual understanding of first principles, and you should, then one of the best sites you can go to is Arbor Scientific. They offer numerous teaching resources that you can sign up for, but they also have a great conceptual questions page - https://www.arborsci.com/pages/next-time-questions. Go check them out and get the resources once you are done. I liked the double boiler question and the bikes and bee question.  See which ones get you thinking or reveal your lack of understanding so you can improve it.
Before I finish though, I’d like to ask: what conceptual understanding tools do you know of? I am always keen for more and others here can benefit from them too.

Do you ever think that your engineering degree didn’t fully prepare you to be an actual engineer? You probably should.
That’s because, on the whole, they were not actually trying to. No matter what they said or thought they were actually doing.
The good news. Once you understand where the system failed you, you can correct for it. You can become the engineer your degree should have produced.
​
Let me explain all this.

Why universities don’t actually create engineers
Engineering academics rarely feel responsible for turning you into an engineer.
Their incentives lie elsewhere:

• deliver the course content
• meet accreditation requirements – something else we should talk about some time
• achieve acceptable student satisfaction scores – often the most important thing for promotion
• prepare students for the exam – also something important for promotion

None of these incentives demand that they produce engineers. They only require that you, the student engineer, pass.
This is not malicious. I always subscribe to Hanlon’s Razor. It’s systemic.
Many academics have never worked as engineers. Their understanding of engineering is theoretical, not practical. They teach what they know: theory, proofs, derivations, and the clean version of a world where every variable is stated and every problem fits onto a page.
But real engineering isn’t like that.
And that’s the heart of the problem – the prevalent ignorance in academia when it comes to engineering practice.

The shift away from real engineering
In my book, I went over the history of engineering education and how that has affected what and how engineers are taught – and how that would affect your engineering skill.
Engineering degrees once contained far more project-based learning.
Students sketched, built, tested, failed, iterated, and learned (although not specifically taught because it is hard to teach) how to think like engineers.
But during the space race, universities started adding enormous amounts of theory. There were genuine reasons for it—missiles and rockets needed deeper mathematics—but the long-term effect was that the identity of engineering shifted toward pure analysis.
Today, degrees still lean heavily toward theory. Project-based learning is expensive. It requires materials, workshops, technical staff, safety compliance, and academics who actually know how engineering is done. And the people making curriculum decisions often have little awareness of the engineering value of those projects – while also having budgets that they need to meet.
This leads to the situation we have now:
Engineering degrees that are perfectly aligned with academia… and poorly aligned with engineering.
In fact, it could be reasonably argued that engineering sits closer to  the trades, since engineering is ultimately about making the world better, while universities are designed to teach theology, philosophy, and science. From that, engineering degrees should be taught at more dedicated institutes. In his book The View from Here, Reece Lumsden noted that research into the career performance of engineers found that those who studied at more highly reputed universities did not enjoy the same career success.

An example that says it all
Think back to the typical exam questions you encountered.
You were probably given the exact variables you needed.
Not fewer.
Not more.
Just the right ones.
All you had to do then was find (or remember) the formula that used those variables and you could be 97.45 percent confident you’d found the “correct” approach.
Real engineering is never like that.
You never have all the information you want from the onset.
You often have extra information you don’t need.
Your first job is to work out which variables matter.
And often the fastest way to do that is to find the right model before you find the right formula.
That difference (between the tidy world of exams and the messy world of engineering) is why so graduates can feel lost when they first enter industry. And why some engineers might never become the engineer they could be – they were never shown how it should really be done.

What I saw as an academic
Most engineering academics today have little industry experience. They went straight from undergrad to postgrad to academia. If someone wanted to do engineering, then I think that they probably wouldn’t have stayed in academia. A science degree would have been a better option. So, there is probably also something about the kind of person who, today, chooses to be an engineering academic. They were maybe not really keen on the whole engineering thing in the first place – even though they did the degree.
When I taught engineering, I had the benefit of industry experience.
That meant two things.
First, I set design-and-build projects. Students then had to think like engineers. To apply judgement. To sift real data from irrelevant data. To design under constraint. To experience the outcome of the wrong decision.
Second, I deliberately included information that wasn’t needed in exam questions.
Some students hated this. I had more than my fair share of complaints.
But I still sometimes receive messages on LinkedIn from past students saying that my subject was the only one that actually prepared them for work.
There are exceptions. Germany, where industry–academia ties are deep and culturally valued, is a strong example of this. But these systems are unfortunately rare.

Good news, you can correct for the system’s failure
Let’s talk more about what you can do.
You might not have received the education you needed, but you can fill the gaps.
We now understand what project-based learning actually builds inside an engineer:

• the ability to frame a problem accurately
• the ability to think systemically about consequences
• the ability to reason from first principles

These three attributes – explained in The Global Engineer – are the foundation of engineering expertise. More good news. You can develop them deliberately, at any stage in your career.

Here’s how:
1. Notice when you’re framing
Every time you start a task, pause and check:
What exactly is the real problem here? What assumptions am I making?
Most engineering errors arise before the calculations even begin.
2. Map the system
Ask:
If I change this, what else changes? Who else is affected? What unintended consequences exist?
3. Use first principles routinely
Even though the way you were taught the theory probably does not help you apply it, put the extra effort in to finding the right theory and then applying it.
You can also practice these skills through:

• the exercises on my site
• analysing engineering decisions you see at work
• reviewing past decisions and identifying where framing or system thinking failed
• mentoring others, which reinforces your own skills
• studying great engineering achievements of the past

Once you know what to look for, everyday engineering becomes deliberate practice.

The bigger point: you aren’t the problem
If your degree didn’t make you feel like an engineer, it wasn’t because you lacked talent.
It was because the system wasn’t designed to produce engineers.
The good news is that the skills that matter most in engineering aren’t locked behind university doors. They’re learnable. Trainable. Practicable.
And you can begin strengthening them today.

The degree gave you the theory – even it was abstract.
Experience will give you the engineering – but not as much as you could have.
Deliberate practice will give you engineering expertise – if you choose to.

​Why was it that the Europeans (and even the Soviets sort of) had supersonic flight, but Americans did not? Did it perhaps all come down to the engineers and their ability? In this article I will consider such questions in more detail so we can better understand how various factors affect your engineering and your chances of success when taking on big challenges.

Some background
Depending upon the newspaper you read, you might have seen this recent article in The Telegraph about the history of the Boeing 2707: https://www.telegraph.co.uk/travel/comment/boeing-2707-america-lost-concorde. The Boeing 2707 is described in the article as “America’s lost Concorde”. Interesting words; how was it lost; circumstance; incompetence; tragedy; or is it about the loss of an engineering race? It leaves the reader wondering just how it is that America never had its own commercial supersonic aircraft.

The article argues that the Boeing 2707 did not succeed because of the following:

1. The Europeans got a headstart
2. The American design was too ambition carrying more passengers and being optimised for slower flight as well with swing-wings
3. Fickle political support
4. Potential for public backlash because of noise
5. Market realities – like those that saw the end of the Concorde

A global engineering lens
Would we reach the same conclusions if we look at this as global engineers? And, could we learn lessons from this consideration?

In my book, I cite another book (The Origins of Turbojet Revolution by Professor Edward Constant II) that compares the efforts to progress aeronautics in both Europe and America. Professor Constant noted that a lot of engineering in the U.S. was guided by commercial realities associated with longer flights (think New York to Los Angeles) carrying more people. This means larger planes with more comfort. In Europe, the focus was purer, and on fast efficient flights.

This offers potential insights into why the American design was too ambitious. There was still the notion of carrying a large number of people, which is congruent with large scale commercial operations. The swing-wing would increase efficiency during the slower portions of a flight – the beginning and the end. This is only significant for shorter flights such as domestic ones (that’s why they worried about people complaining about noise). Thus, it seems Boeing was making the 2707 a domestic and international plane – and thus increasing the potential for sales.

The Concorde on the other hand would get out of one country and stay at top speed until it reached its destination far away – disturbing no-one in between – a purest approach for a very specific (and small) market. Not very capitalistic at all.

Based on the above, we could argue that points 2 and 4 were ultimately more about culture overriding engineering decisions.

Points 1 and 3 can be combined. Indeed, the Europeans had a headstart, but so did the Soviets in the Space Race. The U.S. could have caught up and surpassed if they really wanted to. But there was no perceived national security threat as there was in the Space Race. So political support, being both delayed and then reduced, likely played a role.

And considering point 5, the U.S. government was probably overly spooked to support commercial supersonic flight in the first place, and wise to reduce support later on. Assuming it was all about direct commercial gain and there was no interest in the value of spin off technologies.

Lessons for engineers
Culture can cause you to create an engineering design brief that is not well aligned with the laws of physics. This can sometimes be through your commercial attitudes. Make sure you are realistic about your commercial goals and that they are aligned with engineering realities.
​
And if they are not aligned, then accept that you will need something like government support to succeed. Failure is not a result of engineering skill – or lack thereof. Although it might be a result of engineers not challenging culture with sound engineering principles. You need, at times, to combine engineering and commercial reasoning to find the right direction forward – which might mean ceasing efforts.

So will America have a supersonic commercial airliner?
The Boom Overture, scheduled for release in 2029, has tried scale models already. It shows similarities with the Concorde – delta wings and fewer passengers. And the company seems to be focused on offering a speedier alternative to business class flights along long flights – showing a combination of commercial thinking with engineering thinking.

So yes, I do think there is a good chance that the U.S. will indeed have a supersonic commercial airliner.

But what do you think?

Or When fear and shame override logicWelcome to the next “What would an Engineer Do?” article.
As a reminder, these articles take current issues that sit outside engineering and look at them through an engineering lens.
The goal is twofold:

1. To help you better understand the core attributes of engineering expertise by seeing how they apply elsewhere. Sometimes the different context makes things easier to understand.
2. To show how those same attributes can be applied outside of engineering. This allows you to leverage your engineering skills even more globally.

In this article I am going to apply good global engineering principles to shaken baby syndrome.

Why shaken baby syndrome?
Depending on the country you are in, you might have seen debate about the validity of evidence used in shaken baby syndrome convictions.
You might also be in a country where courts now require an independent witness. The physical evidence alone is no longer considered sufficient.
At the very least, you may remember a time when that physical evidence was accepted as proof.
It is in a state of flux so it is a timely topic, which makes for greater interest. It is also well outside of what many would assume is the domain of engineering.

Some background
You can read more about the science and controversy around shaken baby syndrome here, but the key points to note are:

• It isn’t ethically possible to run proper double-blind experiments in this context.
• It hasn’t been proved that no other mechanisms can produce the same symptoms: subdural haemorrhage, retinal haemorrhage, and encephalopathy.
• Other medical conditions are known to sometimes cause similar effects.
• Reviews that claimed to support the shaken baby hypothesis often relied on circular reasoning: the cases examined had already been classified as abuse victims based on the assumed evidence.

If you think like an engineer, and especially like a global engineer, you know that logic and first principles must guide your thinking. You also know that first principles are found through the application of the scientific method. And in this case, there are no first principles that justify concluding that “shaken baby syndrome” has occurred.
And that means something more concerning.  Because the evidence that was used as first principles cannot be treated as first principles, around the world people have been convicted of a crime they did not commit. And a terrible crime at that – so terrible they would never have committed it.
And yet still, when courts are confronted with reports challenging the status quo based on the above, some judges have responded by saying words to the effects of:

• The argument that the scientific evidence is not actually scientific is radical.
• It seeks to set aside decades of study.
• It stands against other respectable scientific opinion.

For any engineer, that kind of reasoning is known to be flawed. It reveals a misunderstanding of how science works. And when it comes to the scientific method, an engineer should think like any other scientist.
You likely recall Albert Einstein’s response to the book titled 100 Authors Against Einstein. He said “Why one hundred? If I were wrong, one would have been enough.” This shows that science works on facts and logic – not popularity – and a single piece of evidence that contradicts a theory disproves that theory.
Science is not based on consensus or longevity of an idea. It rests on evidence and logic. And in this instance, it seems the logic has been lost.

How are we in this situation? More use of engineering expertise principles
Did the judges not understand science? Or, was there something else going on, something that would be familiar to the global engineer?
Imagine if you were a judge who just had it suggested to them that a key piece of evidence that the legal profession relies has come under question. For context, the legal profession relied on this so much that some defendants said that their own lawyers did not believe them.  You would start thinking that maybe many innocent people have been wrongly convicted. That is not a pleasant thought, you would be attached to the original idea that the evidence is strong and your profession has done nothing wrong. You would be fixated on it – this would make it hard to accept contradictory evidence.
Ideally, this attachment would not result in a fixation that would override the proper application of first principles.
As an engineer, you know that once contradictory evidence emerges, previous conclusions must be revisited.
So, we would hope and expect, that an engineer would, when in such a situation, understand the weakness of the theory, and acknowledge that all prior decisions made (under the assumption the theory was a strong one) are not justified.
First principles should override fixation and attachment. But this is not what seemed to happen with these judges.

The takeaway for the global engineer
This case highlights a deeper professional lesson.
Are you willing to hold yourself to the same standard; detaching from your own preferred theories, your past assumptions, and maybe even your professional pride when the evidence shifts?
That can be the challenge of genuine first-principles thinking.
Think back to a time when you were attached to an idea that clouded your judgement. Or when you saw a colleague resist evidence that contradicted their preferred model. Anyone can do it. The key is to notice it and then to do your best to let go of it – no matter how serious the issue at hand.
 
References used
https://en.wikipedia.org/wiki/Norman_Guthkelch
https://www.theage.com.au/national/australian-court-ruling-in-shaken-baby-case-was-ignorant-and-embarrassing-20251013-p5n25z.html
https://www.theage.com.au/interactive/2025/diagnosing-murder
https://www.brisbanetimes.com.au/national/this-man-spent-six-years-in-jail-but-experts-say-his-case-has-question-marks-all-over-it-20251029-p5n6c9.html

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

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

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

In this article I will talk about cultural shocks and how to handle them. But I am going to talk more about one that few expect. After reading it, you will be better able to manage transitions between roles and, if you are a manager, help other better manage the transition.
First of all, let’s consider some of the different things that can affect engineering practice and culture. The main ones are:

You can probably understand from the above how you could experience significant differences in how engineers go about engineering as you move from one country to another. Especially when those two countries have very different cultures.
However, when the differences are that large, we are often fore warned (and thus prepared) about those differences.
It is the cases where you expect there to be fewer differences that you are more likely to suffer. The cultural consultant and author The Culture Map, Erin Meyer noted that the case where there is the greatest failure in professional transfer is between the U.S. and the U.K. People assume that the cultures are sufficiently similar enough that they do not need to mind those differences – this complacency then causes issues.
In my experience and from my research though, there is an even greater (and less noticed) factor that can cause issues for engineers: typical budget sizes.
This can have a tremendous effect upon how engineers go about their jobs.

• Do you take larger risks on each step of a program so that you spend less on each step?
• Do you have the time and other resources to optimise every aspect?
• Should you be leveraging of the shelf components and system or using custom designs and services?
• Do you conduct hand calculations or do you utilise a dedicated simulation team?
• Do you rework parts or just scrap them and move on?
• Do you try to make it work with run of the mill materials or can you start trying exotic materials from the onset?
• Are independent test laboratories given the final system so only one test needs to be done, or do you send them a full system after you come up with each new feature?

These are just a handful of examples of the things that can be dependent upon how well funded your engineering project is. But, the list still shows how you could tend to take certain courses of action if you have become accustomed to a certain budget size in the engineering roles you have had in the past.
An example from some of my research.
This was some time ago when I spoke with engineers in the automotive industry. It was noticed that Australian and Chinese engineers were better able to work with each other than either could with American engineers. Why was this, given the greater cultural similarities between Australian and Americans? At that time, the Chinese automotive industry was not the juggernaut that it is today – few had heard of BYD, and Great Wall was only just starting to be associated with cars. Instead, it was an industry that ran on much tighter developmental budgets. Much like the Australian industry also was at that time. Today, while the Chinese industry has grown, the Australian industry is essentially dead – so obviously the trends were in opposite directions while at that time there was an intersection.
What does this mean for you?

1. If you are an engineer changing companies, then really focus on how this aspect of the new company is different (if at all) from what you are used to. Then, each time you are thinking about your strategy for an engineering endeavour, double check if you have made any erroneous assumptions based unconsciously on what you think the budget would be.
2. If you are a manager who has new people coming in, then a good way to help them become accustomed to the new company is to talk to them about how they progressed such projects in the past. Do this within the context of budgets so you can be explicit with them if things are different from what they are used to.
3. If you work across global teams, make budget assumptions explicit early. It prevents mismatched expectations and helps align design philosophy from day one.

Budgets can be more of an issue than cultural differences (or even a cause of those differences). Noting the above will help you be more of a global engineer and let better managing this rarely considered issue. ​

The first thing to note is that this is about replacing missile defence with laser defence. The reason? Drones!
Drones are so cheap to build, while still being able to wreak havoc and destruction, that missile defence is simply too expensive. It is noted that a Patriot missile costs one million dollars while a drone would cost about one thousand dollars. That means you need to be one thousand times more productive if you want to keep using missile defence.

From the above, as global engineers, we can note that the problem is framed as a challenge of attrition. The engineering goal is to design a solution that is more cost effective than the enemy’s. That means you can produce your defence longer than they can produce their offence.

Now that the frame is clear, we would like to understand how we got to this situation and the lessons that offers us (or, at least, the phenomena that is demonstrated).

This change has come about because advancing drone technology has provided a more cost-effective form of attack. This is not a surprise to those in the know – in 1997 (literally last century) a book by the title of Robot Warriors predicted things like this.

It was a result of peripheral technologies – mostly electronics, electric motors, and electric batteries – improving. As shown in book like How We Got To Now: Six Innovations That Made the Modern World and Hitting the Brakes: Engineering Design and the Production of Knowledge:

• These peripheral technologies made new technologies (drones) viable.
• These new technologies then put pressure on existing technologies (missiles).
• These new technologies also provide opportunities to advance other technologies (lasers).
• These new technologies potentially also benefitted from improvement in the same peripheral technologies.

This again shows, as I have argued in my book, that often engineering innovation is the product of the needs generated by other innovations. And sometimes, as engineers, we can think of ourselves as the tools that are guided by the innovation path as opposed to being the ones that need to set the path.

This can sometimes provide a freeing sense for engineers and it can also help guide you in your career.
But before we go into talking about career advice, a side note about military history and how it can help you be a better engineer. I want to note that I am not a person obsessed with the military and war. It is simply that because military history is so well documented, it is often possible for us engineers to learn about the way technologies have developed within the contest of evolving need as a result of tother technological developments. Thus, it provides a useful reference. So even if you are not a fan of war (and who really is?), then you can learn a lot from it to help you be a better engineer.

Now back to what we can learn from lasers replacing missiles and how that might guide us in our careers.
I should note that I am speculating here, but I am doing my best to leverage my expertise to provide something accurate.

Because it has become a war of attrition, and the costs are now much lower (on a per unit basis), there will be an ongoing effort to make this laser technology able to fire farther and more frequently through more unfavourable weather conditions. Thus, allowing a single unit to take out more drones as they become ever cheaper and more numerous.

As laser technology advances, it will then eventually be able to destroy missiles (travelling at hypersonic speed) before they become a threat. Even as missiles likely increase their armour against lasers (and then lower their payloads). In such a world, missiles will become redundant – unless they are carrying a payload that has sufficient energy density to justify it (I am talking nuclear).

Therefore, if I were to be an engineer working in missile defence (or considering it), then I would be looking for alternate careers. Maybe drones or lasers. Unless I felt confident that I would secure work in this space as one of the soon to be rarer missile specialists.

This is indeed an excellent chance for you and other engineers (those with the global perspective) to watch how the situation progresses. Predicting what will happen and comparing that with what actually happens is a great way to tune this type of engineering intuition.

I have certainly made my predictions clear.

What about you: What do you think will happen? Do you think I am wrong? Would you stay with a missile manufacturer as an engineer? Do you think someone will develop a shotgun missile that will split and take out a thousand drones in one go? Would you argue mass production techniques will be applies to missiles to get their costs down? Is there something else? Have I underestimated the effects of improving laser technology?
​
Impress me with your ideas and predictions on what will happen.

When you think about engineering projects, they often look neat on paper. There are tasks to complete, resources to allocate, milestones to hit, and a path that seems clear from start to finish. The sort of thing they teach you about in your degree and in things like the project body of knowledge. This is one kind of project. It is the idealised project where the uncertainty is limited, the risks can be calculated, and the outcomes can be predicted with reasonable confidence. Build a standard bridge over a short span, design a stationary gearbox to transmit a set amount of power, or create an electrical filter to cut out unwanted frequencies. These kinds of projects are about precision, planning, and execution. Tools like Gantt charts and resource allocation models work perfectly here. A well run project of this kind moves like a finely tuned machine, and can finish on time and under budget.

The other kind of project is very different. This is where uncertainty dominates, not just in terms of probability but also in terms of what the risks even are. You cannot easily predict the path because the terrain ahead is unknown. Think about developing a new type of bridge to cover a much larger span before you even know what kind of foundations the soil can handle. Or designing a gearbox that needs to be lightweight but still work with a motor and duty cycle that have yet to be defined. Or an electrical filter circuit that must limit radiation exposure to other circuits that are themselves still evolving. In these projects the list of tasks changes as quickly as your understanding of the challenge. Engineers in these projects often complain that documenting takes time away from the work itself, because doing the work is how they discover what needs to be done next. This is coevolution, where your grasp of the problem grows alongside your grasp of the solution. Sometimes all you can do is have a list of tasks - as I mentioned in my book The Global Engineer.

In truth, most projects sit somewhere between these two extremes. Which is why, if you are managing a project, one of the first things you should do is place it along this spectrum. Is it closer to the predictable side where documentation and resource planning make sense, or is it closer to the exploratory side where constant adaptation is needed? If you get this wrong, you risk either over-controlling work that requires flexibility or under-managing work that needs tight coordination. You might even find that different aspects of the one project sit in different points on the spectrum, and need different approaches.

For the global engineer this becomes even more important. What seems routine in one place can be uncertain in another. An engineering team that has solved a problem many times before might treat it as predictable, while in a different environment the same problem requires exploration and discovery. Your role is to see where the project really sits, not just from your perspective but from the perspective of the team you are working with. Only then can you match the way you manage to the kind of project you actually face.

What techniques have you learned when managing projects; have you ever felt let down by the standard tools of project management and not known why?

Meetings can be powerful. When they are run well, they create shared situational awareness, bring every concern to the surface, build an action plan, and leave the team aligned and moving forward together.
When they are not, the best they can do is make a few people feel important while everyone else leaves frustrated, convinced they have wasted time and slipped further behind.

The Manager’s Tool
A well-run meeting is one of the best tools available to any engineering manager, global or not. It creates shared awareness. It builds trust. It keeps everyone moving together.
If you want to explore this further, you may also want to read my earlier article on what makes a great engineering manager.
Because if you want to lead engineers well, you need to master the meeting.

So what makes the difference?

Lessons From Student Politics - of all places
I was lucky to be involved in student politics during my engineering studies. Meetings there followed strict rules and procedures. Everyone had a chance to contribute. Everyone left knowing exactly what had been agreed and who was responsible for what.
To this day, I have never seen a business meeting run as well as the ones I attended as a student. I have seen some better than others, but not that good.

The Global Engineer’s Challenge
In the global engineering context, meetings come with added complexity. Teams bring different cultures, different expectations, and different habits to the table.
Erin Meyer, in her book The Culture Map, describes how cultures approach meetings differently. My take on this is that there are three broad types:

• Romantic meetings – common in parts of Western Europe, rooted in the Roman tradition. They focus on ideas and concepts. Creative, yes, but often without a clear outcome.
• Pragmatic meetings – common in Anglo-Saxon cultures. These aim to produce concrete decisions and action plans.
• Bureaucratic meetings – more common in Asian contexts. Here, the meeting is often the place where decisions are officially signed off, rather than debated.

Each has its place. The job of the global engineer is to recognise which type is best suited to the moment, and to make sure everyone else in the room knows what kind of meeting they are walking into.

How to Get It Right Every Time
No matter how diverse your team is, there is a process you can follow to get the most out of your meetings:

1. Decide on the type of meeting you want. Is it about generating ideas? Aligning on the current situation and next steps? Officially signing off?
2. Write an agenda. Be clear and specific.
3. Send invitations with purpose. Tell people why they are needed and what you expect from them. Include any pre-reading.
4. Remind participants beforehand. Make sure they come prepared.
5. Nominate someone to take minutes. With today’s tools, these can be done live so everyone can agree on the record as it develops.
6. End with agreement. Confirm together what was decided: the ideas generated, the tasks assigned, or the decisions signed off.

And remember: in many contexts, much of what is said in the meeting has already been agreed beforehand. That can be a strength. Use it when it helps you reach clarity faster.

Why Expectations Matter
The quality of meetings varies not only across countries but also across companies. Never assume your team’s prior experiences will align with yours.
Some people may think you are wasting their time if they do not understand the purpose. Others may feel insulted if they expected one type of meeting and you delivered another.
That is why you need to set expectations clearly before the meeting begins. Tell people what kind of meeting it will be, what you need from them, and what success will look like.

Do you have any experience running meetings that other engineers can learn from?