When going for a job, engineers know they can do that exact job. They know they do it well. They would not have applied otherwise. But when it comes to explaining why they can do the job (be it in their resume, their cover letter or the interview), the message does not always get across.
So the job goes to someone else – likely someone who previously had a job that was almost the same (that’s the go-to-move used by many employers).
You have probably experienced the above yourself.
In the previous article, The Need for Willpower, I talked about how frustrating it can be to have strong global engineering skills while working for people who are certain they know better.
I also said I would explain how you can use these to better explain yourself when going for a job.
So let’s talk about that now.
​
For graduates: proving you understand engineering, not just exams
Graduate engineers often look identical on paper.
Same degree. Same subjects. Same grades.
What interviewers are really trying to determine is whether you understand engineering, or whether you simply learned how to pass engineering exams.
This is where noting framing, first principles, and systemic thinking can give you the edge.
Point to any example you can and explain:

• how you framed the problem,
• where you relied on first principles, and
• how you considered the system beyond your immediate task,

you will then immediately distinguish yourself from the majority of graduates.
Design projects or any work experience during study are best here. They are often the closest thing students experience to real engineering practice: incomplete information, competing constraints, trade-offs, and uncertainty. If you have access to design projects — especially open-ended ones — leverage them heavily.
For example:
“At first I thought this was a materials problem, but after reframing it as a thermal–mechanical interaction, the constraints became obvious…”
or:
“Rather than relying on testing, which would be time consuming, I went back to first principles to inform my decision. I found that…”
and:
“I didn’t want to simply assume what was presented. I considered the broader system for opportunities or risk and found that I could…”
Statements like this tell an interviewer something very important: you weren’t just executing procedures — you were thinking like an engineer.

Experienced engineers: making expertise transferable
For experienced and senior engineers, the challenge changes.
At this level, employers aren’t just evaluating what you’ve done. They’re trying to work out whether your capability is locked to a specific industry, organisation, or economic environment — or whether it travels.
This is where global engineering fundamentals really matter.
Instead of listing achievements, you explain how you think:

• how you’ve reframed problems when projects stalled,
• how you’ve used first principles when standards, precedent, or organisational habit were misleading,
• how you’ve thought systemically to uncover risks or opportunities others missed.

Crucially, you make explicit that these are generalised attributes:
“It should be noted that I was not following standard procedure. They’re engineering fundamentals applicable to all industries. Industries like [INDUSTRY YOU ARE APPLYING TO]. That’s why they apply even when the context changes.”
This is especially important if you’re moving between industries, organisations at different levels of maturity, or regions with very different economic backgrounds. Engineering does not exist in a vacuum — constraints, incentives, and decision-making are shaped by economic reality just as much as by culture or structure.
Being able to articulate that awareness signals depth.

Engineering managers: scaling judgment across people and contexts
For engineering managers — engineering leads, heads of R&D, CTOs — the emphasis shifts again.
At this level, you’re no longer just applying framing, first principles, and systemic thinking yourself. You’re developing them in others.
Strong candidates for these roles can clearly explain:

• what good engineering judgment looks like,
• how they encourage it in their teams,
• and how those attributes need to be interpreted differently across industries, cultures, organisations, and economic environments.

This is where global engineering truly becomes a leadership skill.
A manager who understands that framing, systems, and first principles manifest differently depending on context is far better equipped to guide teams. Not by imposing answers, but by shaping how problems are understood in the first place.
What’s more, the fact that you know what the attributes are of the expert engineer will likely separate you from other would-be managers. You show that you are indeed an expert engineer – as expected of a manager – as well as having the required leadership attributes. A powerful combination you should articulate.

Why this works: labels make thinking visible
A lot of engineers already do these things. But they just don’t label them – making it hard for other to understand or see your ability.
When you say:

• “I reframed the problem…”
• “I went back to first principles…”
• “I broadened the system boundary…”

you’re giving the listener a framework they can link your past actions to – making it easier to appreciate and recall.
I’ve used this approach myself repeatedly when applying for roles. I link all the actions I mentioned to an attribute of engineering expertise. And without fail, people switch on. They understand what I did and how significant it was because I gave it a name and explained the meaning.
If you’ve read my book, you’ll know there are many other attributes worth developing — fixation, attachment, goal analysis, and more — particularly for leadership roles. But framing, first principles, and systemic thinking are the core.
They are the fastest way to make your engineering capability legible.
And once it’s legible, it becomes employable.
Also, if your application involves moving countries, working across cultures, or managing international teams, one book I strongly recommend is The Culture Map. It provides a practical framework for understanding how communication, authority, and decision-making vary globally — all of which directly affect engineering work.
Start mentioning these things in your next application. And all the best with that application too – along with all the others that follow. I hope your engineering career continues to be onward and upward – offering you all you wanted from it.
 

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

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

So what makes the difference?

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

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

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

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

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

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

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

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

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