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).

A Review of The Culture Map by Erin Meyer
If you're an engineer who’s worked in, moved to, or collaborated with people from a different country — or if you're about to — then, The Culture Map by Erin Meyer is a book you should buy now. It’s written for anyone navigating the often-unspoken expectations that govern professional interactions across borders.
And it’s especially pleasing (as well as interesting) for engineers, not because we’re immune to cultural friction, but because it reveals how we have a unique approach that helps us overcome cultural differences -- and shows why engineering is an ideal job if you want to travel the world.
Hopefully this has your interest, so let me explain more.
One of the most striking elements in The Culture Map is how it breaks down workplace behaviours across eight cultural dimensions — from how decisions are made, to how feedback is given, to how trust is built. It's not just stereotypes; it's data-informed insights that can help prevent the kind of miscommunications that quietly derail international teams.
What’s fascinating is that the patterns aren’t always what you’d expect. A memorable example in the book highlights how, in China, the Germans and Japanese seemed to work well together — and so did the French and Chinese — but not the Germans and French, or Japanese and Chinese. That might surprise people who assume cultural compatibility comes down to geography and shared history. But engineers will recognise that these kinds of relationships often stem from unspoken assumptions around hierarchy, risk, and workflow — and that’s exactly what Meyer helps unpack.
Now here’s where it gets interesting for engineers. While The Culture Map lays out how professionals from different cultures might clash or confuse one another — for example, over how to run a meeting, make a decision, or teach a concept — engineering practice already gives us a head start.

Meetings: Clarity of Purpose
In some cultures, a meeting is a space for brainstorming. In others, it's where decisions are made. Elsewhere, it’s a rubber stamp for decisions made beforehand. But as any good engineer knows, meetings are tools — and every tool needs a purpose. We specify why a meeting is happening and what we’re trying to achieve, whether that’s exploring options, aligning teams, or confirming next steps. It’s a discipline that cuts through cultural ambiguity — and it’s one I emphasise in my own book as well.

Decision-Making: Inputs and Iteration
Another key difference across cultures is how decisions are made. Some rely on hierarchical authority; others favour consensus. But again, engineers are used to getting input from across levels of an organisation — because that’s where insight comes from. The book gives an insightful example of Japan: a highly hierarchical society that still makes enormous efforts to gather input from across the organisation. This approach — exemplified in the Japanese Ringi system — will make a lot of sense to engineers, who already understand that hierarchy and consensus aren’t necessarily in conflict.

Learning Styles: Why and How
One of cultural differences the book highlights is how people teach. Some do so by diving into theory (the why). Others teach through practical demonstration (the how). Engineers don’t get to pick. If you’re going to master a system or innovate within one, you need both the underlying principles and the procedural steps. So again, where cultural differences might trip others up, the engineering mindset already pushes toward integration.

Respect, Authority, and Curiosity
But perhaps the biggest cultural challenge for engineers abroad is this: in some cultures, the behaviours that earn respect may run counter to the behaviours that make you a better engineer.
In my own work and writing, I’ve emphasised the importance of being physical as well as theoretical, asking questions, seeking input from others, and being willing to be wrong. But in certain contexts, asking questions of a subordinate might be seen as weakness. Or challenging a superior might be seen as disrespectful. Getting your hands dirty could be an issue as well. As Meyer points out, these norms matter. She encourages readers to lean into local culture — a sensible and respectful approach — but I’d offer a slight caveat for engineers: don’t lean so far in that you lose the technical behaviours that make you effective. The risks we’re trying to prevent — design flaws, safety issues, implementation gaps — don’t respect cultural boundaries.

A Recommendation (and a Tool)
Even if you're not deeply interested in culture, if you’re just an engineer working across borders, then culture should be an interest. The Culture Map is a fantastic entry point — readable, grounded, and full of insights that will help you interpret the subtle dynamics around you. And there’s a bonus: Erin Meyer’s website includes tools that let you compare cultures across the eight dimensions, and even evaluate your own tendencies. I recommend checking it out if you’ve ever thought, “Am I the weird one here?” or “Why does this keep happening in meetings?”
Because sometimes you are. And sometimes they are. And sometimes, it’s just culture.

Let me know if you’ve read the book — or if you’ve got your own experiences to share from working across cultures as an engineer. I’d love to hear your stories, and maybe even build a list of engineering tools and mindsets that help us thrive, no matter the country or context.

​After the interest in the last post I wrote on SpaceX and the general interest in SpaceX, I decided that at some time I would come back to the topic - once I thought of an ideal way for readers like you to get as much out of this as possible.

And now is that time now.
​
In the video below, you will see an interview with Elon Musk by the host of Everyday Astronaut: Tim Dodd. If you are not familiar with Everyday Astronaut, then you should put it on one of your subscription lists - it is an excellent ongoing series that provides you with examples of engineering practice that you can use to hone your own engineering understanding and skills.

In the above video, a number of key concepts are discussed. By contemplating these, you can dig into the underlying principles of engineering practice. From doing this, you become better at understanding these principles, and you can then better apply them.

Below are some things I noted - I am sure that they will help you. But I am also keen to know what you noticed. After reading what I have, please share, in the comments, some of your observations on engineering practice examples - good or bad - from the interview. I always enjoy talking about such things, and would enjoy talking with you about them too.

Use of first principles to inform the goals
At 14:20 they note from theory that they can’t get more efficiency so now effort can be directed elsewhere. Why do I find this interesting? Because it shows how, as technology and engineering projects evolve, engineers need to and can change mode. Without this use of theory, there could have been an ongoing fixation with combustion efficiency - even though that’s not what’s really needed by the end user.

Framing the mixing challenge
There is a detailed explanation of the mixing process at the 16:00 minute mark. The conversation revealed that the approach was to premix prior, so that the combustion chamber does not need to do as much mixing - only the last 10%. I like this because it shows how as you progress from the bigger picture to the details you can still be framing.

Strategic design thinking informed by engineering attributes
It is noted at the 18:00 point that they are still using hydraulics as opposed to full electrics for the actuators. The reason is that they have had to focus on other things at that time and the actuators can be separated enough from other systems - so it is something they can look into later. This is a good use of systemic thinking to help optimsie the design strategy which is a great example of modal shifting. There is also a good use of systemic thinking and first principles when they explain how a hydraulic system is still a good idea in other contexts - so they are not designing by heuristics! 

Framing the design strategy
“If you’re not adding back at least 10% of things you’re deleting, you’re not deleting enough."
This is clearly a design strategy suited for the case where weight and complexity need to be reduced. This would not make sense in other cases - say a civilian nuclear reactor - but it is well aligned in this case. And it is an ideal tool to help all engineers keep the mindset suited the challenge - especially if they have tendencies toward different mindsets because of their background (very Global Engineer). There is also at this time the reference to focusing on production and then automation - this shows it is very much a commercial venture. Finally, there is the acknowledgement of the need to iterate - because the limits of first principles use are being reached. I like that last notion because itis informed iteration, and not random trial and error.

Systemic thinking and opportunism
It is noted, around the 23:00 mark, how adjusting the system to protect items from heat and aero load can eliminate the need for the shields. I like this because it shows the synergistic value from combining the attributes of an expert engineer - and not just treating them separately.

Trouble with theory
I was surprised by what appeared to be difficulty with explaining cavitation at the 28:00 mark. The two seem to think they are just bubbles and maybe affected by the chemical environment. It did not seem to be understood that they are supersonic shocks that literally break up solids. It shows that we all keep on learning first principles.

More trouble with theory
Correct me I am wrong, but it seems to me that at the 37:00 mark they provide the exact definition of Isp as an alternative to the Isp. Another example that we can all keep learning.

Now it's your turn
What did you notice in the video? What principles or mistakes stood out to you? Were there other moments that highlighted good systemic thinking, clever framing, or design trade-offs? Drop a comment below—I’d genuinely love to hear your perspective, so I will respond.

​If you're not sure where to start, just share one moment that made you stop and think. These conversations are how we all get better. You can also recap some engineering basics here to better spot examples in the video.

Or, let’s apply boundary analysis to The Holy Land
In the realm of engineering, we often tackle complex systems by identifying their fundamental principles, understanding systemic behaviours, and reframing the challenge. As you would know from my prior writing – these are the three core attributes of the global engineer.
Also, by exploring how these three attributes can be used to solve non-engineering problems, we can sometimes better understand their application – analogies are good like that.
This will be the first article where we do this. And I thought I might as well go all in with something both timely and controversial. So let's apply global engineering expertise to a longstanding and deeply entrenched geopolitical issue: the Israel–Palestine conflict.
First Principles: Understanding Human Behaviour
One of the first principles to acknowledge is the inherent human tendency towards in-group preference and out-group suspicion. Evolutionary psychology suggests that such behaviours may have been advantageous for early human survival, leading to a natural predisposition towards xenophobia. This predisposition can manifest in societies as a persistent undercurrent of tension between different groups.
Moreover, history has shown that leaders can exploit these tendencies, amplifying fear and hostility towards 'the other' to consolidate power and unify their base. This manipulation often leads to increased conflict, as fear becomes a tool for political gain.
Systemic Thinking: The Dynamics of Conflict
From a systems perspective, the Israel–Palestine conflict is not merely a series of isolated incidents but a complex interplay of historical grievances, cultural differences, and political interests. Within any large population, there will always be individuals or factions inclined towards aggression or retaliation. This reality creates a feedback loop where acts of violence beget further violence, perpetuating the cycle of conflict.
Additionally, the international community, particularly the United States, provides substantial financial and military support to Israel and Palestinians. This support is often justified as a means to promote stability and peace in the region. However, without mechanisms to ensure that this aid contributes to reducing conflict, it can inadvertently sustain the status quo.
Reframing the Problem: Shifting Focus from Sides to Systems
Traditional approaches to the conflict often involve taking sides or attempting to assign blame. You have probably found you naturally do that yourself – asking which side it right. However, this framing has proven ineffective in achieving lasting peace. Instead, we can reframe the problem by focusing on creating systems that incentivize peaceful behaviour, regardless of the underlying political or ideological differences. You don’t need to choose a side, you just focus on helping people have a better life.
Engineering a Solution: Applying Control Theory
Control theory, a fundamental concept in engineering, involves designing systems that maintain desired outputs despite external disturbances. Applying this to the Israel–Palestine conflict, we can conceptualize a feedback mechanism where international aid is contingent upon the level of peace maintained in the region.
For instance, a predetermined amount of aid, say the amount given in 2024, could be pledged annually, adjusted for inflation. However, any acts of aggression or escalation of conflict would result in a proportional reduction of this aid. This negative feedback loop would create a tangible incentive for all parties to minimize conflict, as continued aggression would directly impact the resources available to them. Governments especially would be motivated to ensure these funds continue to flow in so they can keep taxes low while still providing services.
Such a system would also empower moderate voices advocating for peace, as they could point to the direct consequences of conflict on their community's well-being. It shifts the focus from ideological victories to practical outcomes, aligning incentives with the desired state of peace.
The Political Engineer vs the Political Scientist
In my book, I compare engineers with other professionals. One comparison was with scientists and the use of boundary analysis common in engineering textbooks, but often absent in scientific textbooks – even when the basic topic is the same. While scientists are, almost by definition, focused on why a system works, engineers are happy to understand how it works so they can move onto the next step to implement what they are working on. In this case, we don’t care about the specific action the people will take to ensure peace, we simply care that they will take action of some sort and keep trying until they find it. The scientific question can be answered after the engineering solution is implemented.
Conclusion: Engineering Peace Through Systemic Incentives
While the Israel–Palestine conflict is deeply complex, applying engineering principles like control theory offers a novel perspective. By designing systems that align incentives with peaceful behaviour, we can create environments where cooperation becomes more beneficial than conflict. This approach doesn't solve all underlying issues but provides a framework for reducing violence and promoting stability.
Disclaimer and request
Because you are likely an erudite reader (and if you don’t know what that means, then look it up – you will laugh when you read the meaning and think about how I assumed the word described you) you have potentially noted that this is a lot like an idea put by Edward de Bono (not the marmite idea). This is true – I have reverse engineered his idea and expanded upon it.
If you think of any other non-engineering topics you would like to see given engineering attention, then let me know. We can even thrash out a solution together. 

In some tribal societies, the most successful hunter didn’t go on every hunt. In fact, after making a few kills, they would stay back.
Not because they were tired. Not because they were lazy. But because they understood something fundamental about group survival: if only one person is doing the hard stuff, no one else gets the chance to improve.
Engineering teams work the same way.
Imagine you have a standout engineer on your team. The one who always figures out the problem first. Who gets handed the most challenging tasks. Who, when deadlines get tight or the project gets messy, is always the go-to person.
Sounds like am excellent engineer to have in your team, no?
But that could be a problem.
The Rockstar Engineer Trap
When one engineer becomes the “hero,” several subtle but significant problems can arise:

• Other engineers stop growing.
  If the best tasks, the real head-scratchers, are always funnelled to the same person, the rest of the team doesn't get the experience they need to improve. They plateau.
• Team morale declines.
  Eventually, the others stop stepping forward. Why try when the outcome is already decided? Engineers thrive on challenges and solving problems. With that gone, you risk disengagement and quiet quitting.
• The team becomes fragile.
  What happens when the rockstar engineer is sick, on leave, or leaves the company? If no one else has been allowed to develop their skills, the company will suffer.

And in global or multicultural teams, this dynamic can be even more pronounced.
Imagine a multinational company with engineers from five countries.
One engineer — perhaps from the same background as the manager, or who shares a language with a key client — naturally starts getting more responsibility. Maybe they simply "fit" better with the current project context.
Before long, they’re doing all the cross-cultural liaison work. They’re solving the most complex problems. Not because they’re the only one who could… but because they were the most convenient person to start with.
The result?

• The rest of the team never gets to practice working across cultures.
• The team’s global competency stagnates.
• And perhaps worst of all, team members from other regions may start to feel second-rate — even when they have the potential to contribute more.

As I note in my book, Engineering Is a Team Sport
We all want high-performing engineers. But building a high-performing team requires something more nuanced.
Sometimes, your best engineer needs to step back — not because they’re not needed, but because others are.
Distributing challenges, rotating leadership on difficult tasks, or simply having the awareness to say, “Let someone else take this one” — that’s not a loss. That’s how you build depth, resilience, and motivation across your team.
Just like the hunter who stayed behind, the global engineer knows: sometimes, stepping back is what's best.

You will note two things:

1. She notes that there are things that were invented in Africa that are often assumed to have been invented elsewhere.
2. She gets very emotional about it because of the effect it can have on people when they are told (even if only implicitly) that they are from a less inventive race.

This brings us to the topic of how the way technological history is taught to you. And how that could affect the way you assume (maybe even only unconsciously) your race affects your inventiveness – or how you might assume others’ inventiveness might be affected by their race.
You can imagine how someone not from the stereotypically inventive race would have limiting beliefs about their own inventive ability. Further, you can imagine how people would assume others could be less inventive if they themselves are from the stereotypically inventive race.
Both above assumptions are anathema to being a global engineer. And neither assumption is actually supported by reality.
If you read How we Got to Now by Steve Johnson and Guns, Germs and Steele by Jared Diamond, then you will realise two things:

1. Invention is limited by your environment more than it is by your ability.
2. Each invention is a result of prior inventions and often shows up in multiple places independently, but under similar conditions.

That means, effectively, we are not the bold inventors driving innovation forward – as we like to think we are – but the mechanism by which one technology provides the need or opportunity for the next.
When you take on this perspective, you no longer think of some latent ability within us (one that could be more common in some races than others) that brings about innovation. Instead, you think of us following a process that is the means by which technology evolves form one invention to the next.
With this perspective, where we see innovation as a product of the situation (including prior innovations), we no longer have to worry about our race – or even our sex, nationality, or any other innate properties of a person – as an indicator of inventiveness. Instead, we simply focus on the processes that allow for ingenuity in ourselves and others. That’s the expectation a global engineer has of themselves and others.
Get the 10 minute audio summary of the book here.

​The recent tariffs announced by the Trump administration—imposed on pretty much every other country in the world—have drawn a lot of criticism from economists.
And from other countries.
And from his domestic opponents.
But could things look different from an engineering perspective?
In this piece, I’m going to cover why economists are so opposed to tariffs—and then explore whether there might actually be an engineering opportunity we have not yet noticed.
​
Why Economists Hate Tariffs
Tariffs are supposed to protect local industries and jobs. Intuitively, that seems great—cut out foreign competition, and locals get to keep their jobs. Or, in Trump’s case, bring jobs back.
But in the current U.S. context, two things complicate that picture:

1. Low unemployment
2. A strong currency with high purchasing power

That means if jobs are going to be brought to the U.S., then companies need to do two difficult things:

1. Pay more than they would in another country, to match U.S. dollar purchasing power; and
2. Pay even more again to lure people away from the jobs they already have—because most Americans already are employed.

So any product made in the U.S. under this model comes at a higher cost. And those higher costs get passed on to customers.
And there is evidence of how tariffs do actually put prices up. But not in living memory for many. One of the few places where people in a developed economy can recall the effects of tariffs is Australia. In the 1970’s Australia was only just introducing colour T.V. But this was stifled by tariffs. The tariffs were there to protect the local radio and television manufacturing industry – but the effect was that a colour T.V. would cost around 9 weeks’ pay. Australians were not impressed, but they still wanted their colour T.V. Tariffs dropped from around 180% to 35% to 5%. A lot of industries were lost, but a lot of things became affordable. You can watch a 17 minute video on this topic below.

Adam Smith, almost the first of classical economics, argued over 200 years ago against tariffs — even retaliatory ones — because they only hurt your own citizens.
 
Can Engineering Offer an Alternative?
All of this assumes that the technology of production stays the same. That’s a key point. It’s essentially a zero-sum view.
But what if innovation could shift the game entirely?
In my book, I argue that engineers—when thinking about economics—should be Schumpeterian. Joseph Schumpeter believed that real economic growth doesn’t come from reshuffling jobs or trade balances. It comes from innovation. From finding ways to do more with less. That’s how societies get richer. Fewer people needed to make a car, a fridge, or a bag of doughnuts. More output per person.
But innovation doesn’t just happen. It needs a driver.
And unfortunately, fear has often been one of the most effective motivators.
Take WWII. It produced radar, jet engines, penicillin, and kickstarted the computing revolution. Or the space race—another fear-fueled scramble—gave us satellites, advanced materials, and a cascade of spin-off technologies we now take for granted.
Even in peacetime, we’ve seen what can happen under pressure. During COVID, I was part of a project that turned an empty office space into a factory. And thousands of ventilators were built in a matter of months.
So here's the question: what if the fear of tariffs and economic stagnation could be channeled into a national innovation push? Could the U.S. become dramatically more productive—not by avoiding the cost of labour, but by needing less of it?
 
Why Hasn’t This Happened Already?
We have the tools. Automation, AI, robotics—these technologies exist. As an engineer, you’ve probably noticed just how much day-to-day human labour could already be automated. Diagnosing illnesses. Servicing vehicles. Even preparing food.
So why haven’t we gone all-in?
Two reasons, I think:

1. Economists tend to default to comparative advantage
   They prefer frameworks where countries do what they’re “best” at. That often leads to outsourcing and doesn’t put much value on building new capabilities.
2. It’s just plain hard to imagine an economy without people
   Let’s be honest. The idea of a society where most of us are no longer “needed” economically is both utopian and hard to believe. I must confess, I struggle to envision how it would work.

 
The Trump Thought Experiment
But imagine the benefits if Trump rallied resources to develop this kind of innovation to make as many people as possible redundant. There would be ample people to take on these jobs he wishes to bring into the U.S. And, what’s more, there would be a huge increase in the amount of production per person. The wealth increase would be phenomenal. This would then set an example for the rest of the globe. And all would then enjoy an increase in wealth when they did the same thing.
But that would require two things:

1. Fear
2. Imagination

Not a common combination.

What’s the takeaway?
The above does seem fanciful. Like I said, I can’t imagine an economy free of people. I think it would make for an excellent challenge for economists though. But still, it helps us think about just how much we could improve things if we really focused on seriously on eliminating the need for us.
And who knows, there are times when history takes a turn no-one saw coming

In the past, when I have presented my findings on how background can affect engineering practice, the basis for my book The Global Engineer, people have at times asked if I found there was any effect from sex. Because I was focused on engineering, which does not have a large proportion of women, and because I was focusing on a deeper research method, which meant a smaller number of participants, I did not get to talk to enough women to make such commentary.

However, that was my research specifically. There are still other avenues from which we can answer this question.

First off, the titular question of this article is a compound one. We need to ask the implied prior question: is there even a difference between men and women?

In The Origin of Species, Charles Darwin noted that there were species that did not have different sexes, and those that did. The former were hermaphrodites – each organism had both reproductive organs – and both would become pregnant. This would mean there could be a greater rate of reproduction when sharing DNA for ongoing adaptation. The latter species, like us, with the different sexes, invested not in increased reproduction rates, but the division of labour. By having a difference between the sexes, a species can have greater specialisation, and this increases survivability.

Therefore, it is apparent that there would be a difference between men and women.

But what is the difference?

Charles Darwin was a smart man – he did not discuss the specifics of the difference – he did not have enough evidence on hand to inform the matter sufficiently well and he was not one to publish opinion as fact.

While there has been some research looking into the differences between the sexes and cognitive attributes, there has also been research into the importance of practice.

In The Global Engineer, I cited the work by Erickson and summarised in Talent is Overrated that showed the overriding importance of practice. I also cited research by Beilock that showed how our perception of ourselves affects our cognitive ability (Asian American girls could have their mathematical ability increased or decreased by making them think about their Asianess or femaleness respectively) in her book Choke.

Therefore, while there could be natural talent differences between the sexes, the major effect would likely come from effort and practice.

But if there were to be a natural difference, then what would it be?

I am reminded of a New Scientist article that my high school chemistry teacher read to the class about the notion of a pill that would make you smarter. The initial premise of the article was to ask scientists if they would take such a pill – should it ever exist. However, the question on what actually made for intelligence then presented. The answer, that all asked for the article could agree upon, was, a desire or enjoyment to think about the problem at hand. Newton and Einstein also noted the importance of spending considerable time thinking on the things they were challenged by – this is much easier when you enjoy such thinking.

So, the real question should be: do men and women have different things they enjoy thinking about?

They might, and this could be the real reason we see more women in nursing and more men in engineering.

If this is the case, then the question I originally put is meaningless. And, really, it’s about anyone enjoying engineering enough so that they are good at it.
And that should be the takeaway: do you (or anyone you might be considering for an engineering role) like engineering?
​
On a related note: if you ever find yourself, like I have before, asked to talk to a group of schoolgirls about why they should do engineering, then do not start talking at them. A better approach is to ask them a question: what do you want from your career? Once you have a solid list of preferences for any future career from the group, you can then explain how engineering can satisfy those preferences. This way you can create motivation to choose engineering – regardless of sex.  

The speech addresses several key concepts:

• The separation of design and manufacturing: Can it be done or not?
• The idea that design ability is innate, potentially influenced by race or culture.
• The tension between lower costs (especially from labor) and innovation.
• The issue of stagnating productivity.

 
I've noticed that people tend to focus on different aspects of these notions, often influenced by their prior beliefs, especially those regarding globalization.
 
This newsletter is called "The Global Engineer". It emphasizes the importance of being an engineer capable of working anywhere in the world and in any role (within reason). Therefore, I do not identify as an anti-globalist. In fact, I believe globalization offers significant advantages for engineers.

• The laws of nature are universal, allowing engineers to work in different countries and leverage their qualifications for greater adventure in their careers.
• Globalization enables regions to specialize, fostering advancements and accelerating the progress of engineering, which can lead to a more engaging career for all engineers.

 
I think the Vice President's speech raises important questions about how globalization has affected engineering and what we can anticipate for the future. He rightly points out that design should be closely linked to manufacturing. I often discuss the importance of concurrent engineering. It’s refreshing to see a politician with such insights into technology — from my experience, there are only a few who possess this understanding. Given the significance of concurrent engineering, we can expect that regions previously thought of as mere manufacturing hubs will also start to engage in design work. Additionally, as wealth becomes more evenly distributed, we will see manufacturing return to other areas – maybe after going those areas still not developed.

I don't believe we will see the old design leaders reclaim their dominance. Despite Japan's recent economic challenges, it has not lost its engineering design capabilities developed in the mid-20th century - capabilities that the rest of the world learned. Instead, we are likely to see more regions cultivate their own ingenuity. Engineers everywhere aspire to do more; they seek to innovate, and as I argue in "The Global Engineer," anyone can develop the essential skills needed.

I agree that many managers often prioritize low costs over investing in innovation, viewing the latter as an expense rather than an investment. This perspective is common among shareholders as well. Al Dunlap, known for his aggressive cost-cutting strategies, serves as a poignant example; despite his controversial practices, many supported his approach.
 
However, innovation should also focus on cost reduction, as improving efficiency can enhance our quality of life without necessitating a trade-off. The use of low-cost labor is often a case of arbitrage that may eventually become unfeasible, yet it has helped lift around 400 million people out of poverty globally, making it difficult to argue against from a moral standpoint. However, we must consider the long-term effects: as skills develop in less affluent regions, those areas may no longer remain inexpensive.

The Vice President also suggests that the preference for low-cost labor over innovation has contributed to stagnating productivity. While this viewpoint may resonate with those outside the engineering field, engineers understand the principle of diminishing returns. Increased productivity typically arises from larger, more efficient production systems, but eventually, it becomes challenging to scale much more, leading to a slowdown in productivity growth. Therefore, attributing stagnation to a drop in innovation caused by globalization is misguided.
​
In summary, while the Vice President raises valid points about the importance of keeping production close to design and the role of innovation, the assumption that any location can inherently excel in innovation is flawed. There must be continuous investment in this capability at the societal, organizational, and individual levels. You can take responsibility for your own development. Then you can leverage globalization to further enhance your skills even more. You can also lobby your respective organization an government for such investment – you can also expect less opportunity as an engineer when your country chooses not to engage the rest of the globe.

We think it shouldn’t; engineering should be governed by fact. But you have probably still encountered times when decisions, once made, seemed to be more politically founded than factually founded.
 
Why is that?
 
I am going to answer this question right now. It will be based on my experience, but informed by all the theory on engineering practice that I covered in my book. You can listen to a 10 minute summary of it here if you want a quick review of the main points – and get some context from what I am about to write next.
 
Attachment
 
The first big driver for politically founded decisions in engineering is attachment. That’s where someone simply likes an idea (often their own) more than others. It is this emotional motivation that drives them to champion an idea in a political manner.
 
Recall that attachment is like a form of fixation, but fixation is usually more cognitive: you just have an unconscious assumption in your mind, and it can only be undone when someone points it out. Once someone does point it out, you usually feel a sense of opportunity and creativity coming from the new perspective. But this is not so with attachment: because emotions are involved, people will become irrational – and political.
 
Therefore, to stop politics in engineering, you need to remind everyone (maybe yourself) about the importance of things like data, first principles and trials. Better yet, don’t let these be forgotten in the first place. When there are plenty of results from physical testing, calculation, simulations, analyses and so on from the onset, the information can either mitigate a person’s emotional tendencies or provide the solid basis others need to challenge someone else’s emotionally based notions pragmatically.
 
What stops people considering only the important facts?
 
Lack of shared situational awareness
 
I have seen times when the ultimate culprit was a lack of shared situational awareness. This is especially so when a person in a senior level does not have complete understanding of the issues at hand. They will then make decisions based on what they think are their amazing insights – AKA ideas formed in a state of ignorance. Given how “amazing” these ideas are, they naturally expect others to implement them straight away, and then expect to see results within a week. Others, who know the flaws in these ideas, but do not have the data on hand to support them, often then find they can offer only an opinion. As well informed as this opinion is, it is, until data is at hand, only an opinion. It then becomes a battle of seniority and rhetoric to see which idea comes out on top i.e. politics.
 
To confront this issue, you can put the effort into creating a document that summarises all key information. It might be a briefing document for a meeting, or it might be an ongoing log that all involved people are alerted to each time it is updated. The important thing is that people will review the content prior to formulating their ideas and putting them forward. Ensure that the document has the following:

• The context of the challenge so people can understand systemic issues and the goal
• Any analysis that has been conducted (numerical or analytical)
• Any test results from physical testing
• Records of all prior meetings on the topic
• Items that remain unresolved – this could be a risk registry

 
Then ensure that, before anyone starts giving opinions, they have been given ample time to go over this document.
 
The assumed need for an immediate solution
 
Another cause of attachment overriding fact-based thinking is the assumed notion that the final idea to be implemented must be identified straight away. Think about a time when you were in a meeting (formal or informal) discussing the solution to a problem and it was assumed that only one idea could be selected at the end of the meeting and that idea was the one that would be implemented. It’s likely not that hard. In fact, you have probably now realised that most meetings you have to come up with a solution to a problem are like this.
 
Make it a goal not come up with the idea that will be implemented, but to come up with a collection of ideas (not too many) to be evaluated further. The best one being selected later. This encourages the perspective that all ideas are selected based on facts – because they are tested further to collect evidence. Also, if there is any remaining attachment, then at least there is a greater chance, after this initial meeting/conversation, for anyone’s idea to be selected – and the motivation to push politically for an idea is reduced.
 
A general lack of first principles
 
The above points have likely implied the importance of first principles. Indeed, simply ensuring people always consider first principles from the onset, will help them become more objective.
 
An informal selection process
You have likely heard of a selection matrix. Where each option is rated against others along criteria that have been developed earlier for the respective problem. The option that rates the highest is the on that should be chosen.
 
When you use such an approach, people can no longer lobby (politic) for an idea as easily. Instead, all are involved in a more disciplined approach to select the preferred option.
 
Note, this is not simply for ideas to solve engineering challenges. It can be used for almost anything, and is the basic approach Daniel Kahneman proposed for selecting new employees.
 
A lack of evolution
 
A formal selection process can also encourage evolution. In The Global Engineer, I talk about coevolution being a major part of engineering – where our understanding of the problem evolves as we evolve the solution. This phenomenon, when accepted and then leveraged, can also help reduce politics in engineering.
 
If an option, after being put through a selection matrix does not come out on top, or, even if it does, but it has some weaknesses against some criteria, then there is an opportunity (if not an obligation) to evolve the design. This would focus on better satisfying the criteria with lower scores.
 
When you do this, two things happen:

1. The solution selected, which might not be the one that first came out on top, will be even better.
2. Each option will have had input (ideas) from others as they think of ways to improve it. This means each idea now has multiple “owners”, and that means it is less likely that one person will have only one option they are attached too – thus less need for politicking.

 
 
 
All of the above comes back to the way engineering problems are viewed and solved in a company. That in turn comes back to culture. If you are in a position to change the culture by mandating practices like that above, then the responsibility is yours. If you work for a company or manger that does not follow such pragmatic procedures for decision making, and politicking has become the norm, then it is probably time to find another place to work – you are unlikely to learn much in your current role and you are unlikely to be having a good time.
 

You have likely heard of design for manufacturability, design for sustainability, design for servicing and design for recycling. You can also work out what each is about. You have likely also heard of “design for X”. Where you substitute X for whatever is important to you.
 
But have you heard of “design for design”?
 
It seems an odd concept, but you have probably already done it. Maybe it was for the best, and maybe not – but I will talk about that later.
 
In design for design, we make a design decision early on in the engineering process so that the rest of the design task is easier. For example:

• A team designing a race car on a limited budget (for both time and money) specifies that they will design a space frame instead of a monocoque. Thus, the analysis process and adjustments of the design to accommodate ongoing changes in other subsystems are easier. Making the overall design project easier.
• An engineer who needs to develop a seal between two existing parts decides on the use of silicone tooling and polyurethane so that a complicated shape can be made that works around those other two parts. The seal might be more expensive to produce and maybe more time consuming to install, but the design process is now faster and easier because there is only one part to be designed as opposed to three. This implies that time or design budget were limited.

 
You have likely noted in the above that there is some external reason that mandates the design be completed quickly. Therefore, the engineer makes decisions that will make the design process faster. You could also argue that this is actually part of the development of the design brief – and not design. But given things such as coevolution, there is actually no clear definition of when the brief development ends, and the design process starts. And one could argue that a design brief could also be designed – potentially another example of design for design that has been happening in engineering all along.
 
And this all seems reasonable – although not always ideal – it would be good to always have the time and resources to implement an optimal engineering solution.
 
However, what about times when design for design is not reasonable?
 
And have you been guilty of this?
 
Some other examples of design for design:

• An engineer dislikes sheet metal parts – such parts are not precise and this engineer has mild OCT – so all parts are designed for machining.
• An engineer enjoys designing with surfaces in CAD so creates parts with convoluted shapes that justify the use of surfaces. The official reason for the convoluted shapes is aesthetics and stress minimisation.
• An engineer in a design house contracted to develop a tool set for a market niche chooses to design new metal forgings (as opposed to just custom over-mouldings for existing forging) because they are excited by the notion of designing hand tools from scratch.

The above examples show that sometimes design for design is not about making the design process easier, but, instead, about making the design process more enjoyable.
 
By the way – I have witnessed all of the above examples firsthand.
 
So next time you are making some early decisions for how you will go about tackling an engineering challenge (and designing for design), ask yourself if you are doing it to make the process more efficient or just more enjoyable.

If you have read my book, then you will know that first principles are at the core of good engineering practice. They provide you with excellent constraints when making decisions. This in turn means you can focus your energies on other well less defined decisions.
 
An illustrative example that given by Gordon Murray when he was explaining his thinking process, involved the specification of a steering shaft in F1.
 
It was quite common for engineers to simply specify a nominal diameter – 25mm (around 1”) for example. That was because that was what everyone had done, it seemed to work, and it was thus easier to do that on all other cars.
 
However, that meant you could either be carrying excess weight. Or, it might even mean that you were close to failure and steering could be lost part way through a race. Neither option is ideal. So by taking a relatively small amount of time to calculate the diameter that would be able to transmit forces required, one could, in such an instance, know that they have an optimised and safe design.
 
That’s the power of being a mathematician as an engineer. You optimise.
 
But, there is also something more; something nearly magical. You gain great insights when you use first principles. Insights that can almost make you look like a magician.
 
Back to steering columns.
 
When Gordon Murray started to analyse the steering column, he realised that there were two types of loads: bending and torsion. Bending was mostly from the driver leaning on the steering wheel. Torsion was from the column’s main purpose: steering.
 
From this insight, which was provided by the use of theory and mathematics, it was possible to re-frame the problem. There was to be a structure designed to support radial loads, and the shaft was to be optimised for transmitting torque. This allowed for further optimisation of the overall design.
 
And it all started with the decision to use first principles and mathematics.
 
So by being a mathematician as an engineer, you can also be a bit of magician.
 
But it can also stop you from being a fool.
 
I also mentioned in my book when I was designing a dynamometer for model solar boats. They were small vehicles designed by students. So, it seemed to me, it should not be too much of a challenge to have a design where the water flowed under a stationary boat. That would allow for the boats to stay tethered in one place under a lamp (emulating the sun). Then, students could experiment with different configurations for different solar conditions. It all seemed like an easy way to offer great outcomes.
 
But then I decided to apply some first principles.
 
This was to choose the right pump. And, as it turned out, I needed a pump that could move 1 tonne of water every second!
 
I felt embarrassed.
 
But the senior technician, who was to organise the implementation of the dynamometer I designed, was grateful that I at least did the calculations – later, but before we actually started any construction. It seems many other engineers he had dealt with were neither mathematicians nor magicians.
 
And you now know what that leaves!
 
So, make the choice now to use first principles to guide your engineering decision making. Do some mathematics. And then make the most of those extra magical insights you will gain. 

Does your religion affect your engineering? Is engineering your religion?
After reading the above heading, you might be thinking about how people who have faith can’t adhere to the principle of science. That’s not what this is about. However, just so you know, you can have faith and be a top-level scientist. How is that? Religion is about faith so facts are to be dismissed. Science is about facts so faith must be dismissed. It is two different parts of the brain that think in these different ways. You can use one for religion and the other for science. You can therefore have both notions existing in the one brain. We don’t all do it, but it is possible.
 
Now for the topic at hand: does your religion affect your engineering?
 
To answer this, I want to first introduce the concept of master morals and slave morals. These two concepts were introduced by the philosopher Nietzsche. Each is associated with a type of religion or belief system:

• There are some that have well defined rules – think of things like Christianity, Islam and Judaism. The Abrahamic religions. They have clear rules – like the ten commandments – they clearly indicate what you should and should not do in any situation.
• Then there are those that have principles that you should follow, but you need to work out how. An example would be the principle of karma in Hinduism and Buddhism.  In this instance, you do not have rules – instead, you a principle from which you can evaluate each case to determine the best thing to do.

 
Note that this is a very short summary with a certain perspective (mine). Many a philosopher would not be impressed with this. Also, each religion mentioned can have elements of the other – I am generalising for effect. Note also, as I said, I have generalised here, and you might view your religion differently from how it is describe above. 
  
The first is said to have slave morals – where you have a clear right and wrong in all situations. The second is said to have master morals – where you need to maximise the good and minimise the bad in all situations. Despite the names, Nietzsche was not of the opinion that master morals were inherently better than slave morals – each has its place. Although, he did find it concerning that Europe gave up the Greco-Roman religions, which were based on master moral principles, for Christianity, which has slave morals. Thus, he did imply that master morals were more evolved and noble.
 
So what does this mean for you as an engineer?
 
The simple thing to ask yourself is if your religion has encouraged you to think there is one right answer for everything or if it has taught you that you need to do the best with what you have.
 
Then you need to ask yourself what is best for your current engineering role:

• Should you be dogmatically ensuring that every decision is thoroughly researched and optimised before it is implemented?
• Should you be noting that you will always need to compromise, and maybe even just get something implemented given limited resources of time and funds, when making your engineering decision?

 
You might find that your religious thinking has encouraged you to think in a manner well aligned with the engineering challenges you face. Also, you might not.
 
The best thing you can do is reflect upon this, and then adjust your thinking as needed for your engineering.
 
Now for a thought experiment to help you better ponder your engineering attitude: if engineering were a religion, then would it have master morals or slave morals? Note – I have no answer for this – it is indeed a thought experiment.