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.