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?

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.

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.