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?

In 2016, during the Syrian Civil War, statistics about the conflict were everywhere. Thousands of people had been killed. The numbers were reported regularly. And yet, most people barely reacted.

Then a single photo changed everything.

It was the image of Omran Daqneesh, a young boy sitting dazed in an ambulance, face bloody and covered in dust. He wasn’t dead. He wasn’t even seriously injured. But because it was a child, and because it was visual, the world suddenly cared.

You might recall it. Can you also recall if it changed your thoughts about the war?

I remember being annoyed. People had been told about the deaths for months. They knew the scale of the suffering - including children. But they only seemed to care when the image hit their emotions.

This was not a new phenomenon. During the late 1800s, Belgian authorities were brutalising the people of the Congo. Reports were published. Descriptions were circulated. But global outrage only came when photographs appeared. One in particular, showing a father looking at the severed hands and feet of his child, triggered a wave of action. Words and statistics alone had not been enough.
The lesson is clear. If you want people to understand, sometimes you need imagery.

What this means for engineers
At first glance, this might feel like a very human failing that has little to do with engineering. But engineers face the same limitation. Numbers, tables, and percentages do not always trigger our full understanding. We often need to convert them into something more tangible to see their significance.
Good engineers learn to paint those pictures in their mind’s eye.

• What does it actually sound like when the SPL reaches that decibel level at that frequency?
• How would it smell if sewage of concentration x% entered the floodwaters?
• What tissue damage would be done if that voltage caused an electric shock to human skin?

In each case, data is only the starting point. Real understanding comes when you can translate the data into sensory and physical implications.

The challenge for the global engineer
We cannot always wait for the real image, the real sound, or the real smell. Our work depends on imagining those consequences before they occur. That’s how we prevent failure and design better systems.
So here is the challenge: next time you are presented with data, don’t just note the numbers. Take the extra step. Convert them into their physical impact. Hear it, smell it, feel it in your imagination.

If you do, you will have overcome one of the limitations of being human. And you will be closer to becoming a truly global engineer.

And you just might start to sense tragedy well before others.

Give thought now to how often you have only understood the seriousness of a situation after you experienced it in some way. And, based on that, think about if you need to put more conscious effort into using numbers to paint a picture in your mind's eye.  

“Growth is permanent everything else is temporary.” This is, for me at least, a very motivating quote. Thanks Dharmesh Kodwani for sharing that with me. It got me reflecting on the things we can do to improve our engineering capability as a global engineer. There is no substitute for a clear focus on improving how you work as an engineer. However, reflecting upon insights from others can sometimes be that little bit extra that separates the ordinary from the extraordinary. And reading the right books provides the best way to do this.

Therefore, I have collated a list of the books that I think are ideal for anyone who wants to be a global engineer.

These are also books that you don’t want to just read once. They are worth coming back to time and time again. Sometimes we forget the great insights we have read. We can recall some of the details and where we read it, but we forget the important stuff. So these are books you should also pick up from time to time to either re-read or flick through to keep yourself as amazing as possible.

Hitting the Brakes: Engineering Design and the Production of Knowledge  by Ann Johnson. This book is fascinating. It is written by an historian and uses the development of antilock braking to understand how engineering communities develop. It provides great insight into how knowledge in engineering is developed and shared. As you read this book you will notice how and why your understanding of different technologies you work on changes over time. Ideal for engineers involved in a rapidly changing industry/technology.

What Engineers Know and How They Know It: Analytical Studies from Aeronautical History by Walter G. Vincenti. This book was a bit slow to get started for me. However, it was fascinating to see how engineers tackled different problems throughout history. It uses the aeronautical industry as a case study, but much of the content is applicable to all engineering. At the end of this book, you will start to think about what kind of an engineer you are and if perhaps there are some things you could do a little differently.

The View from Here (Optimize Your Engineering Career from The Start) by Reece Lumsden. This is a book like one I have not come across before. It is the only book on engineering that starts at choosing a place to study engineering and then considers how to manage your engineering career. It does not talk much about the unique characteristics of engineering, the way other books do. Still, no matter the stage of your career, this book can likely help. This is a book that will make you reflect upon your past as an engineer and think more about what you should do next in your career.

Engineering Philosophy by Louis L. Bucciarelli. It talks about a thing called the object world (the world engineers work in), but it also goes into much more detail about the nature of engineering. It talks about the social nature of engineering; how we, as engineers, can sometimes think we know something and do not; and how engineers learn. At the end of it, you will probably think twice before ever reaching any engineering conclusions.

Engineering and the mind’s eye by Eugene Ferguson. This is one of the most visually rich books on engineering. Because the book essentially argues that visualisation is the key to engineering, this makes sense. The book argues convincingly that engineering requires mostly visualisation, but still a tactile understanding. It cites many other sources to support its contention and was the first book that I read that finally explained the link between art and engineering. If you want to gain a better understanding of how engineering has developed as practice, from beginning to what it is today, then this is an excellent book. After reading it you will probably start thinking about how you can improve your engineering ability through the senses you use when confronting a problem and how you choose to represent that problem.

The Origins of the Turbojet Revolution by Edward W. Constant II. This book focuses, as the title suggests, upon the development of the turbojet. It deals substantially with how ideas of a revolutionary nature often come from people outside of the respective industry. How revolutions can push some companies and their engineers to the sideline and raise others. These revolutions are rare, and a book about one, written by an historian, is a useful insight into the engineering tasks and attributes essential for such revolutions. What I found most interesting about the book was that it also covers the development of the antecedent technologies like the water turbine and supercharger.

How we Got to Now by Steven Johnson. This book tracks the development of 6 major inventions that significantly changed our world. This is done from the perspective of how they came to be – through interactions with other technologies and societal events. If you need to work on your ability to understand how and why the time can be right for a new idea, then read this book.

The Saturn V F-1 Engine: Powering Apollo into History by Anthony Young. This traces the history of the titular engine and the mission to the moon. Along with coverage of the technology and its development, there is also much in here about engineering behaviour and management for success. Ideal if you want to know what it takes to pull off a large engineering project (or even a smaller one).

Six Thinking Hats by Edward de Bono. This is certainly no longer a new book. However, it is an excellent book that helps you consciously look at problems from multiple perspectives, and be more certain that you understand it. This will also help you outside of engineering as well.

Talent is Overrated: What Really Separates World-Class Performers from Everybody Else by Geoffrey Colvin. If you thought engineers were born and not trained, then this book will make you think otherwise. If you need more convincing that you can improve your engineering, then this is the book you want. It’s also ideal for anything else you want to improve.

How to measure anything by Douglas W. Hubbard. This is almost an engineering book, but it’s also a business book. The reason why I put it in the list is because of how unique it is. There are few books out there that help you deal with uncertainty the way this book does. Given how many things can seem uncertain at the start of an engineering project, this ability is an ideal for all engineers to have. By being able to put a measure to those things you do not yet fully understand, you can better assess ideas in their nascent stages.

Thinking, Fast and Slow by Daniel Kahneman. This book provides great insights into how our initial thoughts can often be wrong. Essential for good engineering – especially when you are working with something new. It also provides insights into when you can rely upon your intuition – something that can bring an engineer undone if not done right.

The Global Engineer by Clint Steele (yes – me). I am obviously bias, but if you are going to read only one of these books, then I would recommend this one. Why, well, as I noted, I am biased, however, I did pull the essence out of each of the other books above to write this one. So it will provide you with most of the good stuff. Still, if you read the other books, then you could find something you need that did not influence what I wrote. Regardless – get this book!
​
I am always looking for more to read and learn. If you have anything you think should be added to the list, then please let me know in the comments.

In chapter 18 of “The Prince” by Nicollò Machiavelli, he notes that for a prince to achieve great things he must appear pious and to keep faith, but at times he must rely on force to achieve greatness. He goes on to note that writers of antiquity told stories of how Achilles and other great princes of Greek Mythology were given to a centaur (half man half horse) to be raised. This taught them how to act like men, and keep faith, but also how to be ruthless at times and use force, like a beast. But which beast? Sometimes he should be cunning like a fox to sense traps. Sometimes he needs to be powerful and forceful like a lion to defend himself against the wolves.
This is an example of the “And” winning over the “Or”. You will often fail if you always think you need to choose one option over the other. Instead, to succeed, you need to work out the best way to leverage each option at the right time.
So can this concept apply to engineering?
Beasts never engineer, at least not in the sense we are talking about. So does that not mean that as an engineer we should always be using the erudite and human approach? And that in turn means that there is no “And” in this case.
In the engineering context, the equivalent of the way of the beast is intuition.
We should, most of the time, be relying on the core of engineering expertise:

• Framing the problem so that it becomes one we can solve.
• Using first principles to designate the values of variables.
• Thinking systemically – getting as much information as possible from others and the broader system.

These are essential for the Global Engineer – it will prevent issues from differences in practices arising.
However, are there times when you can use your intuition?
Intuition works when you have been working on the respective system repeatedly for some time. So much so that you have trained a part of your brain on that topic – like AI, but the original.
So that’s when you can – but in cases like this you are not really being an engineer – you are not doing anything ingenious.
Are there times when you should use your intuition?
If you have limited resources and there are other aspects of the respective challenge that require proper engineering, then those aspects that are familiar to you, and allow for intuition, then that would be a time you should. But still don’t expect it to be an optimum solution you develop.
Think now about times when you used intuition correctly and incorrectly in engineering. Was the reason for failure that you had not yet had enough time to develop it?

The best of the best
Who is the greatest engineer in history? You might suggest one of the following:

• Imhotep – The world’s first recorded engineer and architect, who designed Egypt’s Step Pyramid of Djoser nearly 4,700 years ago.
• Leonardo da Vinci – Renaissance genius whose visionary sketches of machines, bridges, and flying devices anticipated modern engineering by centuries.
• Nikola Tesla – Pioneered alternating current and wireless power, reshaping how electricity flows through our modern world.
• Isambard Kingdom Brunel – Bold British engineer who transformed transport with his tunnels, railways, and pioneering steamships.
• Eli Whitney – Inventor of the cotton gin and a champion of interchangeable parts, laying the groundwork for mass production.
• Thomas Edison – Prolific inventor who brought practical electric lighting to the world and built entire systems around it.
• Archimedes – Ancient Greek engineer and mathematician who devised ingenious machines, from war engines to the screw pump, and laid down principles of mechanics still used today.
• Li Bing (3rd century BCE) – The Chinese engineer and administrator who designed the Dujiangyan Irrigation System, one of the world’s oldest large-scale water management projects, still in use today.

Who would you add to the list? Who do you think deserves the title of the greatest engineer? There is no shortage to choose from.
But the more important question is: how do I get to be that good?
First off, let’s note one thing: some of these engineers, while having great skill, experienced some serendipity. If Imhotep had been born some years earlier than he actually was, then there likely would have been no Egyptian empire to provide the resources needed to execute his vision. That means that there are possibly thousands of engineers who were just as great (when it comes to engineering skills and expertise), but they did not get to work on projects that would make them as well known.
I hope you do – for one thing it would mean that there are still great engineering projects for me to read about and talk about – but I also write these articles so I can help you become the best engineer you can.
So now let’s talk about the three attributes these engineers had – although, each probably had each attribute to varying degrees, and could have still benefited from further improvement.
Framing
Don’t always take the problem as given. Think about other ways you can bring about the desired outcome. In my book I talk about how a Formula 1 engineer took what all thought was an aerodynamics problem (where the gap under the car was too large for ground effects) and turned it into a suspension design problem (where the challenge became designing a suspension system that would lower under lighter aerodynamic loads, and return to the specified height for scrutineering).
The key to framing is twofold:

1. As I said, don’t take the problem as given – be willing to change it.
2. Take your time. Framing does not always happen in an instant so be ready to ponder on it for a while. Wrestle with the problem so you see if from all angles and then find the one that allows you to attack it.

Systemic thinking
We often get into trouble because of the things we don’t think of. When we implement our solution, we realise that it will cause another issue with a related system. So we want to prevent this.
But, there’s more. We can sometimes use those related systems to help solve our challenge. So we also want to look more broadly at any challenge we have to find opportunities, as well as potential issues.
To do this, think bigger. Don’t focus on only your own little challenge. Talk to others. Ask them what they have experienced. Go and see the location of the challenge (if you can). As you do all of these things, you will automatically spot potential issues and think of opportunities to explore further.
First principles
You have learned all that theory for a reason.
When you choose to use it – either through hand calculations, simulations, experimentation, guiding principles and so on – you can make specific changes to your proposed solution to:

1. Prevent failure.
2. Optimise the outcome.

Failures are clearly bad so you want to avoid those. And if you can provide and optimised solution, then you are indeed working like a great engineer.
So always think about the theory applicable to each challenge you face. And don’t be afraid to learn about more if you can or need to.
Over to you
You now know that the greats did – they framed, they thought systemically, and they used first principles – so you can work on doing that too.
If you want to learn more about each, then take a read of my book – I go over each (and other attributes of great engineers) in more detail.
Which attribute do think will be the hardest for you, and what will you do now to start working on it?
 

​Usually, we want to know how to be a global engineer – one who has mastered the attributes of engineering expertise and understands how context can affect both the development and application of those attributes. That way we can become an engineer of excellence who can work anywhere.
But there’s also value in knowing what not to do. And that’s the focus of this article.
I’ll take three cases of engineers saying stupid things throughout history. Then I’ll take a shot at why they blundered. From that, we can learn how not to fall into the same traps.
So let’s get started.
 
Julius Sextus Frontinus (Roman engineer and Superintendent of Aqueducts)
“Inventions reached their limit long ago, and I see no hope for further development.”
1st Century CE
From the haughty position of the 21st century, we can certainly say Julius was spectacularly wrong. Not only have inventions continued, but our understanding of science has advanced enormously since his time.
What’s more, he seemed blind to the fact that other parts of the world – China, India, the Andean civilizations of South America, to name a few – were also developing unique technologies.
Julius simply couldn’t imagine that better worlds or better systems could exist.
The lesson? Don’t ever become content. Always assume the world is full of problems waiting for solutions.
 
Boeing Engineers
“Mass production methods from the automotive industry are not applicable to aircraft.” (paraphrased)
World War II
During WWII, the United States needed to outproduce Germany and Japan in aircraft – especially bombers. At the time, it took around 200 times as many people to build an aircraft as it did a car, and the cost (per weight) was about 35 times higher. So it made sense to look at automotive-style production for planes.
But many aeronautical engineers dismissed the idea. Aircraft, they said, required tighter tolerances, exotic materials, and more “finesse.” Even German engineers thought this kind of mass production was impossible.
Of course, history proved them wrong.
And yet, even today, I hear similar resistance when Lean, Agile, or other well-established methods are suggested in industries that see themselves as “too complicated” to used these new methods.
What’s the real reason for this. I would say it is usually ego and laziness: we don’t want to admit gaps in our knowledge, and we don’t want to put in the effort to learn by trying something new.
The lesson? Stay motivated to try new ideas and see if they make things better.
(Side note: Charles E. Sorensen from Ford thought mass-producing aircraft would be easier than it was. He was overly optimistic. But if we made a list of engineers who underestimated how hard something would be, it would include you, me, and pretty much every engineer who has ever lived. Denialistic optimism might even be an essential engineering trait.)
 
Richard Gerstenberg (then Chairman of General Motors)
“Well, I have looked into this design [Compound Vortex Controlled Combustion], and while it might work on some little toy motorcycle engine, I see no potential for it on one of our GM car engines.”
1973
This was about Honda’s CVCC engine, developed to reduce pollution. When Honda tried to convince U.S. automakers to adopt the technology, Gerstenberg gave this response. Others in the U.S. also claimed it would reduce performance due to differences in cylinder size and geometry.
In response, Honda acquired a Chevy Impala, fitted it with CVCC, and sent it back for testing. The poplar story goes that it outperformed the unmodified Impala across the board. In truth, the results were more mixed – but the system clearly had promise and should never have been dismissed so lightly.
Why was it dismissed? Some argue it was because Honda was such a small player at the time. Which I think is related to the “not invented here” syndrome. We tend to disregard ideas from others – and more so when they are smaller or less reputable.
The lesson? Apply first principles thinking before mouthing off.
 
Closing
I hope this has helped you think more about how to be a better engineer – even if it’s through the lens of what not to do.
A global engineer avoids arrogance, embraces learning, and tests ideas no matter where they come from. That’s how we make sure we don’t end up as the next bad quote in history books.
And if you know other examples of “stupid things engineers have said,” then please share them.

Let’s talk about what it takes for a successful business. Because engineers (and maybe you) think about running their own business. Also, as an engineer, you are likely to be asked to join a start-up, and it would be good to know if that’s a good risk to take.
I’ve run my own business, been involved in a number of start-ups, formally studied the theory of starting a business in a Master of Entrepreneurship and Innovation, published in business journals on analysing start-up risk prediction, and kept up to date with the topic ever since.
Having done all that, I’ve come to realise the core needs (and common mistakes) when starting a business. And that’s what I will share with you here – in case you have indeed been thinking about your own business.
​
The Big Mistake
Confusing technical expertise with the essentials for commercial success.
In The E-Myth and The E-Myth Revisited, Michael Gerber explains how people who are good at something are often told they should start a business. He shares the case of a woman who opened a pie shop after everyone praised her baking skills. But there’s a lot more to running a profitable business than simply making a great product.
You need to understand how the whole system will work, and from that ensure it’s efficient enough to actually make a profit. Many never master this second step. That’s why so many businesses fail, and why people who work for themselves, on average, earn less than those who work for others.
So what makes for a profitable business? A demographer has the answer.

The Two Laws of Business Success
Let’s talk about Bernard Salt – the demographer.
Because he’s a demographer, he hasn’t simply run a few businesses and drawn conclusions from his own experience. He has looked at the data across all businesses, providing insights that are far more objective and complete than you will get from anyone else.
And what does Bernard say?
The laws of business do not care how smart you are or how hard you work (this is a shock to many). Instead, Bernard tells us that they only care about two things:

1. Your business model
2. Your location

Note how this follows on from what Michael Gerber says. It’s not about the skill; it’s about the way your business is set up.
So how do you know how to set up your business? You have to ask the right questions of your customer.

Finding the Right Business Model
That brings us to Tony Ulwick’s Outcome-Driven Innovation (ODI), summarised in his book What Customers Want. ODI focuses on the tasks people want done. By doing this, you create a business around the things that make life easier for people — helping them achieve their goals with less cost, whether that’s time, effort, or money.
Once you understand this, you can fine-tune (or maybe redesign if needed) your offering (product or service) and how you present it to potential customers.
It also helps you innovate.
Consider the anecdote — which is untrue, by the way — that Henry Ford once said: “If I asked customers what they wanted, they would have said faster horses.”
This is often used to argue that customers don’t know what they want. That’s not the case. It’s more that we often don’t ask in the right way. When you understand what people need done, and then find a way to make that easier for them, you’ve taken a big step toward having the ideal business model (and, the right location) that is the foundation for success.

The Takeaway
I do want to see you succeed regardless of the path you take, so I hope the above helps you to:

1. Avoid leaving your day job for a venture that’s unlikely to succeed.
2. Guide you toward success in any venture you do start.

What are you thinking now? Are you now less certain about starting your own business? Are you thinking about tasks you can help people with? Are you thinking twice about that start-up your friend asked you to join?
I am always keen to learn more about innovation. If you’ve started your own business or come across great insight from others, then tell me in the comment what you’ve learned?

Embed Expertise into the Everyday
One of the simplest ways to embed engineering expertise into your team is to ensure it’s visible in every document your engineers create. Whether it’s a design review, a proposal, a stage gate summary, or a root cause analysis, every document should reflect expert engineering thinking.
The easiest way to do this? Templates.
Every document template should have sections for:

• Framing — How are we solving the problem put? Why are we doing it this way?
• First Principles — What theory, facts, or fundamentals are informing this decision?
• Systemic Thinking — Who else is impacted? What are the downstream effects?

Framing might only need to be stated upfront in early documents and then referred to in later documents as a reminder. Still, this is an important step that should be given focused attention.

First principles could take the form of hand calculations, simulations, physical experiments, or thought experiments. The key is that every engineering decision is traceable back to theory and fact. This does two things: it reinforces good engineering practice, and it gives management confidence. You’re not just getting opinions; you’re getting objective, optimised decisions—decisions that can be checked, challenged, and improved upon.

One of the most effective ways to encourage systemic awareness is by creating a registry of engagement with other departments. This is a living document that tracks issues, opportunities, and touchpoints between your team and the broader organisation. Each time there’s a review, ensure this registry is updated. This practice guarantees that your engineers are actively considering systemic factors, and it drastically reduces the chances of an unforeseen issue blindsiding the project.

Build Shared Situational Awareness
A high-performing engineering team isn’t a collection of individuals—it’s like a singular mega-engineer thanks to shared situational awareness. Regular updates, reports, and team briefings help build this situational awareness, but it starts with you.

Do you take the time to keep your team informed? Do you allocate space for your team members to communicate what they’re working on?

If you set the example, your team will follow. Shared situational awareness becomes part of your engineering culture. And that’s when teams start to move together.

Support, Don’t Smother
One of the fastest ways to erode your team’s effectiveness is to offer “unhelpful help.”

You’ve seen it before (I know I have many times): An engineer is struggling, or maybe it’s just not clear what they’re working on. The manager swoops in, starts making suggestions, imposes new reporting forms, or dictates solutions.

None of this helps.

A better approach is simple:

• Ask what support they need. Trust that they are the expert—not you.
• Engage in a conversation. Understand the issues they face, then figure out how you can assist.
• Request a one-page update. Let them choose the format instead of making them to fill out more forms. Give them the space to highlight what matters. If you're worried about inconsistent formats, then remember: AI can fix formatting. What you can't fix is the missed insight from an engineer who wasn’t given the chance to express their perspective.

Your job isn’t to micromanage. It’s to create an environment where your engineers can excel.

The Takeaway
Great engineering managers don’t just manage tasks; they manage environments. By embedding expertise into everyday practices, fostering systemic awareness, promoting shared understanding, and offering genuine support, you build a team that consistently delivers excellence.

Ask yourself: What environment am I creating for my team today?

And if you want to see how an AI coach can help develop your engineers into global experts, try Ingeny here.

Or you can read the book on being a global engineer here.

This might not come through in my articles, but I have a real thing for paradoxes (tragedy too, but that’s not important right now). The reason why I have a thing for paradoxes is that if you put the effort into resolving them, then you usually gain a much better understanding.

And in this article I am going to talk about the paradox of why autarchy is important in engineering.

First off, what is autarky?
Autarchy is an ancient word that basically means self-sufficiency and independence. It can be applied to the state or to an individual. In ancient Greece, it influenced other philosophies that dealt with the ideal human state. Some reaching the conclusion that people should be free of clothes and shelter so that they did not need to rely on anyone else. But most reaching the conclusion that a person should invest in themselves and their ability.

How would autarky relate to engineering?
To be a good engineer (a global engineer) you need to invest in yourself. Skills like framing, systemic thinking, goal analysis, creativity, prototyping. And knowledge, first principles, domain knowledge, recent advances in technology. And correcting for any gaps in your engineering expertise that you have identified and were caused by your background.

As you continue to invest in your engineering ability, you become a self-sufficient engineer (you demonstrate autarky).

Why is this a paradox?
As I noted in my book, there is no longer any such thing as the singular engineer who does everything. There are no more hero engineers. That’s because technology and engineering have become so sophisticated that no one person can be across everything. 

That’s why engineers need to work in teams. And this is where the paradox presents.

• Why should you be part of an engineering team?
• What do you offer that the team needs?

The needs of an engineering team vary from team to team and with time as new challenges faced by any given team present. That means, if you have a small set of skills, then the chances you can help a team (one you are on or one you wish to be on) are limited.

And that’s where the paradox presents: you invest in yourself to be a self-sufficient engineer so you are of value to the engineering team.

You might not use all of the skills you have when you are part of a team, but the more skills you do have (and the more of a self-sufficient engineer you are), the more you are able to support your team. 

“He who is unable to live in society, or who has no need because he is sufficient for himself, must be either a beast or a god.” – Aristotle

So think now about which skill you are going to work on next. How will you exhibit autarky and be either a beast of an engineer or an engineering god?

If you are not 100% sure where to start or want another perspective on your engineering expertise, then try Ingeny, the AI engineering coach I developed, here. I have recently added an auditing feature, that you might find useful.

When we talk about engineering, your mind probably leaps to blueprints, CAD drawings, graphs: visuals. Most engineers naturally rely on sight. But what if you could be a better and happier engineer by spreading your focus to all your senses?
To be a truly global or expert engineer, you need all your senses—not just your sight (literal or imagined).
Synectics: Engineering Through Your Body
In Synectics—an inventive design technique—engineers don’t just think; they become part of the system. You might physically mime the motion of a piston, feel the inertia of a valve, or walk through your proposed layout in the car park. This “sensual embodiment” sharpens your intuition about friction, resonance, and balance in ways a CAD model cannot.
When you feel the problem, you bypass the limitations of abstract thought—and you often find on solutions faster.
Beyond the Visual: A Full Sensory Approach
It is worth noting that, with age, you will likely develop subtle multi-sensory awareness: hearing the hum of a motor, feeling the vibration in a bridge truss. But why waiting for that to emerge passively? Instead, you can (should) train your senses deliberately:

• Listen to how systems vibrate or resonate.
• Touch materials to sense texture or stress effects.
• Smell overheated bearings to understand they are being worked too hard.

These can be your engineering superpowers; if you cultivate them.
A Lesson from Homer via Samuel Florman
Engineering isn’t new to sensory thinking. Samuel Florman recounts in The Existential Pleasures of Engineering how Homer’s Odyssey immerses us not just in sight, but in sound, touch, and even smell as Odysseus and Calypso fashion a raft. Florman writes that Homer’s detail brings us deeper into the world of engineering, in an almost romantic sense, by noting how all our senses can be stimulated by the process.
Why This Matters
We now live in an era reliant upon digital twins and simulations – and the chance of some engineers being replaced by AI. You risk losing the grounding connection to what it feels like, sounds like, smells like. And those are potent feedback channels. By intentionally engaging all your senses, you deepen your connection with the challenge ad your intuition for it. This makes a more effective engineer and you also get more out of the experience: making it more satisfying for you.
Take This Forward

• Next time you’re sketching solutions or creating them in CAD, stand up and mime the situation (or just use your hands if the office is crowded and you don’t want the attention).
• During testing, close your eyes—what do you hear, feel, or smell?

Becoming a sensual engineer I about reclaiming the full spectrum of what makes engineering more human and leveraging the power that offers.
Learn more about being a better engineer here.

​In my book I have a section dedicated to willpower and food for when you want to change (and improve) your engineering practise. I have found that some (likely many) don’t really let this set in.
So let’s now talk more about the Hungry Engineer – and the fuel needed for change.
Let me be clear: I’m not talking about motivation in the vague, spiritual sense. I’m talking about literal energy. Glucose. Calories. Food. Fuel.
If you’re trying to change how you work as an engineer — to become the kind of thoughtful, principle-led, systems-aware, globally competent engineer that I would argue is the real engineer — you’re going to encounter resistance. And resisting change takes far less energy than driving it.
I’ve experienced this firsthand. When you start asking for others to consider broader systemic issues, for shared understanding, for time to frame problems properly or apply first principles, people get uncomfortable. You’re challenging assumptions about what good engineering is, breaking habits, and that can feel threatening to those around you. You’ll hear things like, “We’ve never needed to do that before” or “That sounds like you’re overcomplicating it.”
So what happens? Every step forward becomes a battle. You’re not just doing engineering; you’re doing change management. You’re having to explain yourself, justify your approach, and sometimes go it alone until the results start speaking for themselves. That takes effort. More than most people expect.
By the way, it is not any easier when you’re leading. Because while you can decide the process, you still need to keep everyone on the new track.
And if you’re already tired, then you’re going to feel it. And you are probably going to have to compromise, which, in this case, means lower standards.
It’s not some abstract challenge of "willpower." It’s a literal problem of energy management. You’re running your body and brain on low reserves and expecting yourself to do the hardest work there is: change. And when you think about it like an engineer, that makes perfect sense. Willpower is a type of power. And like any other kind of power, it needs a power source.
That’s why one of the simplest but most powerful things you can do as an engineer committed to improvement is to make sure you’re well-fueled.
I’ve even changed my own eating habits in response to this. I fast regularly for health reasons, but I’ve sometimes had to end a fast early because I knew a big meeting was coming up where I’d need to be sharp and resilient. I needed the energy.
It’s easy to scoff at the idea that eating a good lunch could make the difference in whether you bring improvement to yourself or your company. But the evidence from the research shows that it absolutely can. Engineering change is hard. Don’t make it harder by running on empty.
So if you're serious about becoming a better engineer—more globally competent, more systemically minded, more committed to best practice—then start with the basics. Eat. Rest. Fuel up.
Change takes energy. Make sure you've got enough of it.

In this article, we're going to delve into the design of "clickers," or old TV remote controls from the 1950s. This marks the first installment in our retro-engineering series, where we examine past engineering designs to gain insight into the methodologies engineers employed. With the benefit of hindsight, we can discern which designs succeeded and which did not. By reverse-engineering the processes behind successful designs, we can glean valuable lessons in sound engineering practice.

Let's begin by exploring how these clickers functioned.

You might be aware—or perhaps not—that these clickers operated using sound. Inside each clicker were several metal bars. When tapped, these bars resonated at specific frequencies, each corresponding to a particular television function: changing channels, adjusting volume, powering the TV on or off, and so forth.

Pressing a button on the clicker activated a spring-loaded toggle mechanism, causing a small hammer to strike the appropriate bar. This produced a clear ringing sound at an ultrasonic frequency, inaudible to the human ear. From the user's perspective, the experience was akin to using modern remote controls.

Understanding the mechanics of these clickers allows us to critically assess the development process behind them.

Firstly, it's noteworthy that the designers accurately identified user needs. From an outcome-driven innovation perspective, this was spot on. Users preferred the convenience of controlling the television without the need to physically approach it – it made the job to be done much easier.
This necessity raised the question: how to transmit the user's command to the television?

This framing led to two critical considerations: the nature of the signal and the medium through which it would travel.

Potential options at the time included:

• Infrared signals, akin to those used in many modern remotes.
• Radio waves, similar to those employed in remote-controlled toys.
• Wired connections, as seen in some early remote controls.

However, each of these options had drawbacks. Infrared and radio wave technologies were prohibitively expensive due to the cost of components (recall Moore’s Law where electronics have been regularly halving in size and cost while doubling in power for decades now) and the limitations of battery technology at the time. Wired connections, while feasible, were cumbersome and detracted from user convenience.

Consequently, engineers had to explore alternative solutions. Sound, particularly ultrasonic frequencies, emerged as a viable option. By applying fundamental principles, they realized that the natural frequencies of metal bars could be harnessed to generate distinct signals.

This realization reframed the design challenge: creating a handheld ultrasonic transmitter.

Because TVs were already established, along with the internal technoilogy, it was possible to create a circuit to process the signal from the microphone using vacuum tubes. They were not transistor type electronic devices that are the subject of Moore's law. Therefore, it likely would have seemed quite obvious that the microphone should be attached to a circuit to activate the respective switch depending upon the frequency of the signal reaching the microphone and being converted into the electrical signal. I don't want to be dismissive of this though, it still would have been a design challenge and an engineering challenge, it's just that it probably would have flowed a lot more after the previous frame, designing an ultrasonic generator that can be held in one’s hand, was formed.

For a more detailed history of TV remote controls, you can refer to Zenith's heritage page: Zenith Remote Background.

Now here’s a question for you: would you have conceived the same solution under similar constraints? Contemplating this can provide deeper insight into your own engineering skills and how to further develop them.
​
Additionally, if you have alternative ideas for creating a remote control using 1950s technology, feel free to share them in the comments. Personally, I pondered the use of inductors and capacitors to filter the microphone's signal into the respective circuits as an alternative to vacuum tubes. That’s because I recall making a filter for a speaker box I made some time back, and I have a fixation on such filters. So also think about what made you come up with the your idea.

In engineering, we often need to find the compromise of two competing requirements. This can include the way we work – and not only the solutions we develop. Engineers need to be able to work autonomously while also ensuring collaboration. We want deep work for optimisation, but we can’t work in isolation. We want agility for speedy solution implementation, but the work still needs documentation. I refer to this in the book Global Engineering as modal shifting – where engineers often need to move from one mode of work to another as the nature of the challenge changes. In the post COVID world (been a while since I used that term) working from home (and hybrid working has become more common. This has added a new nuance to engineering colocation – in the past it was about things like international teams across timelines and siloed organisation structures.
I should note that engineers should be co-located.
Hybrid work is here to stay. Some of your best work probably happens when nobody talks to you for three hours. But colocation—being in the same space, at the same time, working toward the same goal—is essential for engineering excellence.
And this has been known for a long time.
The Case for Co-Location: Obeya, Agile, and Actual Progress
If you’ve studied Lean, you’ve likely heard of Obeya—the Japanese term for “big room.” It’s not just a room full of desks. It’s a space where multidisciplinary teams come together to share plans, data, goals, and progress. The aim is shared situational awareness. The result is faster decisions, better alignment, and a sense of shared purpose.
This should sound familiar. And agile agrees.
The Agile Manifesto explicitly states: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Agile emerged from the trenches of software development, but its principles align perfectly with the needs of modern engineering: tight feedback loops, quick course corrections, and collaborative problem-solving.
None of that happens over email, text or online chats.
But Engineers Also Need Time to Think
And yet… engineers also need solitude.
There are moments when progress means going deep, not wide. When an engineer needs to put on noise-cancelling headphones, stare at a whiteboard, and lose themselves in a technical knot. That’s not just nice to have—it’s essential so you can leverage the power of your unconscious.
So how do we reconcile the need for co-location with the need for deep work?
The Maverick Middle Ground
One answer comes from Ricardo Semler’s Maverick. In his iconic book about transforming traditional management, he describes a system where employees aren’t told when to work, but rather when to be available.
Imagine a framework where engineers are expected to be onsite between 10 a.m. and 2 p.m.—a shared block that ensures collaboration, alignment, and quick decision-making. The rest of the day? That’s for solo work, whether it’s at the office, at home, or in a quiet corner of a café.
Or consider a structure where engineers are co-located Tuesday through Thursday, with the remaining days left flexible. The result? A blend of spontaneous conversation and uninterrupted focus. Team synergy and personal autonomy.
Co-Location Isn’t Just Old School Thinking.
This isn’t about going back to the old way of working. It’s about acknowledging what has always worked—and updating it for today. Engineering teams thrive when they have shared goals, shared knowledge, and shared space.
So yes, engineers should be co-located. But it need not be all the time. And not at the cost of deep work.
Instead, we can be intentional: design our workweeks to make the most of face-to-face time, while respecting the individual cognitive demands of engineering.
That’s not just efficient—it’s engineering.
If you have come across methods to find a balance between solo work and colocation that you think worked well, then let me know in the comments.

The Mars Climate Orbiter was destroyed when one team used metric units and another used imperial. The Mars Polar Lander likely failed because its software misinterpreted the deployment of landing gear as touchdown, cutting the engines too early.

Not long after these events, I was lucky enough to attend a presentation by Chris Johnson, who had been asked to investigate the disasters. He specialised in safety — how to prevent incidents, basically. His job was not to understand the technical causes (they were known); his job was to explore the organisational aspects that allowed the causes to exist in the first place.

His presentation included a number of interesting elements. For example, he was told by some government departments that they had evidence the lander was on the surface — but they could not tell him what their evidence was (that was classified). Another example was that he studied the code in the system and found that the power management software kept resetting the emergency beacon — so even if the lander had survived, it would never have been able to let anyone know.

There were many examples within his investigation that would help demonstrate key principles of engineering expertise — or, at least, what can happen when they are not applied.

However, the one element I found most interesting in his presentation was Tier Analysis.

Tier Analysis is a tool used to find the root cause of failures from the perspective of the organisation. It checks that each level of the organisation has done what it should to prevent the respective failure. In his presentation, Chris Johnson said it was basically like this:

• Blame the person lowest on the hierarchy involved in the respective project.
• Then ask: is it fair to blame them? Were they sufficiently informed and supported?
• If the answer is “no,” then blame their boss.
• Then ask if that is fair.
• Keep on repeating this process until eventually the answer is “yes, it is fair to blame this person; they should have done more.”

In the presentation, Chris Johnson noted that Tier Analysis had proven popular with many organisations. However, as they used it, they found that often there was a lot of blame placed on middle and senior managers. Those managers didn’t really care for being blamed — so they decided to stop using Tier Analysis.

And that is why I can say: it probably is the boss’ fault.

What does this mean for Global Engineers?
You can probably see how the application of Tier Analysis — and managers choosing not to use it — demonstrates the importance of well-functioning engineering teams. Shared situational awareness efforts, dedicated to ensuring all team members understand what is trying to be done and how, would mean more people could spot gaps in plans and point them out before it’s too late.

So if you are the boss, be mindful of ensuring those under you have all the information they need. If you are not the boss, then consider taking on the role of documenting everything and sharing it with others (including your bosses), so that potential issues can be spotted before they become disasters.

What would you do differently?
Have you ever been in a project where things went wrong — but the real problem was further up the chain?

Would a better flow of information, or clearer expectations, have helped?
​
Drop your experiences or thoughts in the comments — I’d love to hear how you’ve seen this play out in your own engineering career.

​You’ve likely seen this in action: people arguing about who was responsible for what, conflicting versions of the same plan, parts that don’t fit together, or teams who only discover they’re on different timelines after it’s too late. The best outcome when things like this happens is that you end up behind schedule. The worst thing is that the engineering goal is never achieved – or only partially achieved after blowing out the budget and the schedule.
This happens when engineering teams do not have shared situational awareness. Situational awareness is one of the core attributes of any successful team. And if you don’t have it, then, no matter how skilled the engineers in the team are, they will not be succeed.
This issue of lacking shared situational awareness is even more prevalent when you are members of your team are from different backgrounds. This is because each member will contextualise differently based on their background.
Therefore, as a global engineer, it is vital that you know how to create shared situational awareness.
Here are three simple but powerful ways engineers and engineering teams can build and maintain shared situational awareness – whether you’re working on software, spacecraft, or subways.

1. Get in the Same Room
It sounds simple, because it is. The first and most powerful step is to get everyone physically in the same location. In the Agile Manifesto, one of the key principles is: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
This idea has roots far older than Agile. In the Toyota Production System, it was formalized as Obeya (literally "big room"). The Obeya is a space where all the key stakeholders on a project – engineers, managers, planners – work together in close proximity. The room is visual, physical, and intentional. Everyone can see what’s happening. Everyone hears what’s being decided. No one is out of the loop.
Whether you set up a formal Obeya or simply commit to spending regular time together in the same place, you’ll notice an almost immediate increase in coordination, clarity, and energy. This will come from people talking to each other about what they are doing, and incidentally identifying differences in understanding to be corrected.

2. Use a Document of Absolute Truth
This isn’t some mythical or complicated concept – it’s a simple principle: everyone knows that no work is considered done until it’s recorded in one place.
This document – or digital repository – becomes the single source of truth for the team. It might be a master CAD model, a shared file tree, a wiki, or a visual project board. What matters is that everyone knows where it is, how to use it, and what it means.
When everyone refers to the same source, two things happen:

• Everyone has the same understanding of what the project needs to achieve.
• Everyone can see how their work affects, and is affected by, others.

These two things together make a core of shared situational awareness.

3. Schedule Regular Updates
Even with a shared room and a document of absolute truth, teams can still drift. People get absorbed in their own tasks. Decisions then get made in isolation. Then, eventually, you have conflicts within the team.
That’s why you need structured, regular updates. These aren’t just check-ins for the sake of it. They’re touchpoints that give everyone:

• A consistent, shared message
• A chance to ask clarifying questions
• A reset button on assumptions

It’s not enough to assume shared awareness will persist once achieved. It must be maintained. And that’s what the updates are for.

Final Thought: do you already do this or do you need it
Think now if you are someone who needs to put extra effort into ensuring shared situational awareness. Or maybe even needs someone else to do that for you because you always charge off working on your own tasks without thinking about others. Talk to my AI engineering coach Ingeny if you would like some ideas on how to deal with this.
Also, think about “documents of absolute truth” that you have come across. You might not have realised it at the time, but thinking back now, you can understand how they kept everyone on the same page. If you think of one, then share it in the comments – I like learning about techniques that people use.

I know I am not the first person to take on the topic of AI of late. But the conversation on how it could affect engineering in the broadest sense has not, as far as I have witnessed, been explored as much as it could be. In this post, I am going to go over some recent experiences I have had with AI in engineering, and then, from that, talk about what we could expect.

Can AI do engineering?
Recently I have been developing an AI agent to help people like you think of ways they can be better engineers. I have trained it on the knowledge I have documented on best engineering practice and given examples of how to reply in certain cases. 

The agent is called Ingeny. Try it out here.

This is the first version, and it is still evolving. So if you take the time to explore it to see how it can help you with things like your engineering skill development, career progression and working with other engineers, then you will help make it better. I would appreciate you taking the time to help evolve it. By the way, the plan is to keep it free so engineers can always use it as they wish and need.

In the process of training Ingeny, I needed to train it to respond differently depending upon whether questions are about improving engineering expertise or about actually doing engineering. In the former it does not need to provide a warning that it is not a qualified engineer. In the latter, it should let you know that while it has offered as much insight as it can, into say a design for EMC, it is still up to you to do the engineering work. 

This proved to be demanding. AI is not good with that kind of nuance: is it an engineering question or a question about engineering?

If AI can’t easily deal with the subtle difference between doing engineering and talking about engineering, then it’s probably not going to do well with the subtle differences within engineering problems that can have huge effects upon the nature of the optimum outcome. It is also going to have difficulty assessing all the systemic issues present, the best way to apply first principles, or the best way to frame. This is because the AI that seems to reason is, at this time, based on Large Language Models - words - and engineering, as I have noted before, is very visual (it’s often in the “mind’s eye”).

Does this mean engineers are safe?

For now, I can’t see AI understanding the challenges of something like reviewing the landscape to determine (or create) the best approach to building a bridge to cross an expanse of deep water. However, I understand that AI is only getting better. It is therefore only a matter of time until AI can do such things. 

I remain unsure how long that will be.

Until then, it will be the same for engineers as what has been said for writers, medical practitioners and others. The question of whether it will be engineers or AI is the wrong question. The premise is that it will be engineers and AI, so the question then becomes: how will engineers use AI?

And it’s probably going to be pretty good.
Be the engineer you wanted to be
Anecdote time. 
When I was in academia, I would sometimes ask my students who of them wanted to be the type of engineer who understands the fundamentals of theory and first principles, but wants to be more an ideas person who then gets other engineers to make the ideas happen. Everyone would put their hand up. I did this to show my students that the chances of them getting such a job, given the popularity of such a job, is minimal. That means they were all going to have to make the ideas happen as well as coming up with the ideas.
However, AI has probably proved me wrong.
While I think it will be some time until AI can truly do engineering work, I can see it, fairly soon, doing a lot of the grunt work so that we can be the ideas engineer.
How would this work?
Software engineers are showing us how this could play out. They have felt the brunt of AI more than others, because, out of all the engineering disciplines, software engineering is the most language based. And a Large Language Model is ideal for that kind of work.
But while software engineers have been hit the hardest, they have also shown that they are valuable when it comes to the initial idea and providing the right prompt.
That’s what could very well be the case for the rest of us engineers. Consider the following:

• Providing the description for the part you want, and AI then generating the CAD features to produce that part. You can then take a look at the first iteration and describe the changes you want made - then, they would be executed with the speed of AI. If you have been a CAD monkey like me, then you know how much time this could save and the ideas you could generate when you only need to consider the final outcome as opposed to how to generate it.
• Asking AI to generate a circuit board design based on the inputs, outputs, and the available space. Once again, you can review the initial iteration and make suggested changes.
• Using AI to take your initial free body diagram - maybe hand drawn - generate all the force and moment balance equations, solve them for the key parameters you have identified and then optimise for the one parameter you are interested in. You could draw up a number of ideas and have them all analysed near instantly.
• Importing the bill of materials of a product you need to make to an AI system and then asking it to generate the layout of a production line that could make the product. You could then use it to develop details for each work station, estimate the time to complete work, then step back out to see how that affects the overall work flow, iterate, and then do other work stations. With AI to execute your instructions, you could design an optimised production line at an incredible speed.
• ​Have all the parameters set up instantly and to best practice for a CFD simulation. So you need to only focus on analysisng the results, assessing them for validity and then contemplating what changes to implement next.

You can see in the above, that you are automatically like the chief engineer getting other engineers to execute the detailed work for you to review. Imagine also that you can likely talk to the AI system and use peripheral devices to augment your instructions - like when you sketch and use hand gestures to work with colleagues. This is the type of work that many engineers I know would love to do.
The major challenge I see is that we will need to establish how we will train engineers to get to the level where they can be the ones providing the initial instructions. Maybe that is a post for another time.

What will come after this?
There is a chance that one day AI can do our work. I am not one of those people who naively says “AI can never do my job.” But I am not saying I know it can either. So the best thing is to be ready for what could come.

And if AI can one day do all the engineering, including the ingenious stuff, then it has probably also become smarter than us. And If it is that smart, then, like other smart entities (us), it will likely have pets. So work on being adorable to AI so it wants to keep you as a pet and make you happy - not a bad life really.
What are your concerns?
Do you have any thoughts about AI in engineering or any concerns? Share them with me in the comments. And also let me know how you go with Ingeny.
Note
And so you know, while I do get AI to help check my articles, I do write them. Usually on a Sunday night. But I will use AI to often generate my images - if I can’t find a suitable one online - and I sometimes dictate the article content to be cleaned up and written (this one was typed though).