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