Let’s talk about how you can use an old and well-established technique to bring your team of engineers (no matter where on the globe they hail from) into alignment of understanding. And without the need for time-consuming meetings that no one seems to be mentally present at anyway.
Recently there have been stories about how Jensen Huang reads a huge number of emails each morning. The story is likely exaggerated – a calculation of the implication of the claims indicates that he would not really be reading the emails. However, there are details about the nature of the emails – written so that the key points can be extracted quickly – and how this allows for a much flatter company structure - Jensen Huang can quickly distil key information for situational awareness without the need for middle management or excessive and wasteful meetings.
He has been described by some as revolutionising management.
But is this really anything new?
Not really – it is a variation on the theme of the established one-pager.
The one-pager you say?
The one-pager has been a tool of business and management for so long it is hard to establish the origin. That’s an indicator of how powerful it can be. Yet many still do not understand the power, and do not use this remarkable tool.
Why is the one-pager so powerful?
It comes down to two things: the speed of talking and the speed of reading.
People can speak about 150 words a minute. They can read up to 300 words a minute.
You can see the power already.
If, instead of asking people to present in a meeting, you ask them to write a one-pager for others to read, then you have just halved the time demands on each person involved.
But there is even more benefit.
Each person can read at a time that suits – allowing them to better manage their time in general. They also focus when they read – instead of sitting in a meeting looking like they are paying attention when they are not (especially if the meeting is an online one when everyone is working on other things anyway).
And not the disadvantages you might assume.
You might assume the use of the one-pager is a one-way thing: no chance to ask questions. But, after reading a series of one-pagers, you, and others, can follow up if needed. Maybe even call a meeting – but this time you know that meeting will be focused, and of greater value.
Excellent record keeping.
If you have a repository of one-pagers for any engineering project or activities, then you have a great record of efforts. This can be excellent to review why certain things have been done, find how to resolve issues solved prior, and to prepare for stage gate presentations or audits.
Nuances in the global context.
If you do choose to try the one-pager in a global context, then you will find that different cultures will write them differently. And none of them will be ideal.
Western-style. Tell ‘em what you are going to tell ‘em, tell ‘em, and then tell ‘em what you told ‘em. The use of this tricolon method does help to drill the point. But it does also mean space has been wasted – you do have only one page after all.
Confucian style. Spiral to the point. Cover the various aspects of concern as you slowly get to your point – like exploring the whole landscape so nothing is missed. It is a good way to ensure coverage, but, as we will learn, it is good to be upfront with the point.
Arabic style. The zigzagging of iteration. The traditional Arabic approach is start each section with a summary of the last and how it links to the new one. It is indeed good to note interconnectedness, but there is limited space so best to be concise.
The ideal style of the one-pager.
Start with the main points to be conveyed. That helps the reader determine if they need to read more – thus saving people even more time. This section should include any thoughts on how others could be affected – so you can be more sure people will know if they need to read on. It should also include what support, if any, is needed from others – you won’t get help if you don’t ask.
Next, provide the detailed information to support the above. There should be no new information here – just details to better explain what has been said. And it could include images, but do not use up too much space.
You can of course stipulate any format you wish. But be careful. When you are too prescriptive other engineers lose their initiative, you can waste space on things that are not important, and you might not get all the details that are actually relevant.
A truly ideal application for AI in global engineering.
“I apologize for such a long letter - I didn't have time to write a short one.” ― Mark Twain
It does take time to write a concise one-pager. Not much more than it should take to prepare for a presentation in a meeting, but time, nonetheless. So anything that can help with that is ideal.
And AI is excellent at taking a list of thoughts, ideas, questions and so on, and then turning them into a polished concise document. I use it frequently in meetings to take people’s individual comments and then turn them into topic-based meeting minutes in an instant.
Not to mention auto-reviewing.
I mentioned above how a collection of one-pagers can make a great record of an engineering project or be used for audits. Well, you can use AI for these things too. If all the one-pagers are fed into an AI system, then you can:

1. ask it about ongoing issues that present,
2. report on the status of specific issues,
3. ask how you might solve a challenge you currently have, and
4. get it to generate larger summaries of the state of a design of a project – ideal for management and induction of new engineers.

Take the time now to think about the kinds of things you could get AI to generate if you had a large collection of one-pagers for the engineering project(s) you are working on now.
And it can translate too!
So anyone in your team can write in any language they like, then have it translated into the language the team uses. It can then also be translated into the reader’s language to help further again to enhance understanding.
You can see now the power of the one-pager as an alternative to having someone(s) present in a meeting – especially as a global engineer.
So if you have ongoing meetings where people update their efforts and you think are not doing their job well, or, people seem to waste time calling a meeting each time they have an issue, then try the one-pager method.
Suggest a layout and encourage people to use AI to help.

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?