You might have heard of the AUKUS program. Australia, the U.K. and the U.S. are cooperating to produce a fleet of common submarines to be shared among them so that they can better coordinate their military efforts globally. If you have, then you likely also know how controversial it has proven to be. Most of which have been political, but one of the latest controversies has a decidedly engineering aspect to it – and makes for a great and timely demonstration of a key lesson for global engineers.
You can read about it here in The Age. But the key points are:

1. Funding has been increased considerably.
2. Production rates have still stayed at around 1.2 per year.
3. This is not enough, and the production capacity has become the major impediment to the success of this program.
4. Austin Dahmer, a senior policy official at the US Department of Defence, has said “Any recommendations that consist of more money without a mechanism to materially compress those timelines will not change the outlook.”
5. Arthur “Trip” Barber, who sits on the National Commission on the Future of the Navy said the idea of AUKUS is a good one, but the issue is production caused by an inability to keep workers.

Many engineers will read the above and be able to think of similar situations that they have been in. There is a strong desire to make this happen – this desire leads to effort on the part of those in leadership, but nothing seems to improve. This is despite throwing money at the problem. In fact, it is probably because money is thrown at the problem. This is congruent with a mindset that comes from ignorance – there is no real understanding of the challenge so the instinct is to allocate more funds to keep doing more of the same instead of doing things better. More money flows, but it goes into the same wasteful efforts.
You possibly recall the story of Ford Motor Company taking over production of bombers in WWII. It was in the hands of the generals, but they simply did not know how production worked. We are seeing history repeat.
This phenomenon, though, is not unique to government and the military. I have seen it happen in industry as well. Managers, who, instead of asking how to support those who had the knowledge and were trying to get the job done, would allocate more leaders (leaders who were just as ignorant). This then resulted in even less progress as these extra leaders spent more time distracting those trying to do the job than they did supporting them. Why did management do this? They lacked the engineering knowledge to understand what was actually happening.
Think about this notion of how a lack of engineering management can be so problematic, and now ask yourself these questions:

• Who do you think would make a good leader of the AUKUS program?
• What would you do if you were leading it?

This reflection will help consolidate your understanding of engineering management and the knowledge you might want to acquire.
The above shows how important it is to have an understanding of engineering fundamentals (not just first principles, but the fundamentals of the art of engineering and its practice) when managing any program with a large engineering element to it.
The reason why this is important for the global engineer is because different parts of the world have different attitudes to the role of engineering in government. China is famous for having around 80% technocrats in its government. President Xi studied chemical engineering. In the West the classic backgrounds are law, economics, and political science. And then some countries are more likely to have military leaders (Myanmar, Thailand, Pakistan, Egypt, Israel). This can mean that in different countries, there is a different assumption of what knowledge a leader should have. And it will not always align with an understanding or an appreciation of engineering, but sometimes it will.
This is something to be aware of if you ever plan a significant change of workplace. Keep an eye open for situations where management keeps throwing resources at a problem, but things do not get better. It could be an opportunity for you; or a warning: do not get involved.

I have just finished reading a book called The Cognitive Athlete by Clint Rahe.
The book focuses on methods used in the military, professional sports, and other high-performance fields, and then explains how you can apply them to efforts that are cognitive in nature.
I am not going to review the whole book, but I am going to share with you the basic thrust and something I noticed that is ideal for global engineers.

The basic thrust.
We should not think about time management to maximise our performance as professionals. Instead, we should better understand how our energy levels work so that we can work on the right things at the best time.
This could mean working out when you are most able to think clearly and take on the most challenging of tasks – and then scheduling that time to be free of meetings so you can focus on the hard stuff.
It could also mean finding the time when you are least capable, and then allocating that time to reply to routine emails.
By aligning your periods of maximum energy with the more challenging tasks, you become much more productive.
Further, you should also find ways to automate or routinise as many tasks as you can so that you have energy reserves left over for the tasks that truly need your cognitive capabilities. This includes things like checklists for checking drawings, a standard procedure for approving purchases, and a uniform way for reporting faults in maintenance.
In addition, if you are going to have a period of high demand, then you need to have a period to ramp up prior and then a period of recovery and reflection afterward. What was interesting about this aspect was that these periods could be throughout a day, a week, a month or a quarter. There was no consideration of periods that go for longer. Meaning, if your job is pushing you to 100% until the end of the year, when you can rest, then you are not operating at 100% energy levels – and you are likely far from working optimally.
This is a very rough summary, and if you want to know more about how to maximise your cognitive ability so that you can perform at a higher level, then get yourself a copy.

Why this is important for the global engineer.
As a global engineer, you need to be able to shift to new contexts and still perform well. The perspective of The Cognitive Athlete allows you to understand the nature of cognitive energy expenditure that is required in any new role you find yourself in.
This could be a result of national practice, company practice, or the nature of the specific challenge.
I now know times when I need this more:

• I have worked in countries where the norm is 5.5 days a week so I needed to management me energy differently from other places.
• Some roles were continuous in their nature – always solving problems as they presented – so I had to plan my energy usage on a daily and weekly basis to ensure I would not burn out.
• Other roles had definite busy periods and periods of different task types – I would therefore need to plan for periods to note lessons learned (so I would recall them for the same time next year) and use a short break to get myself in the right frame of mind for the next period.
• I have also worked in roles where, due to time-zone differences, I needed to work at times not aligned with my natural rhythms, and I would need to be more mindful of making the most of those periods where my energy aligned with the opportunity to work on more demanding tasks.

As a global engineer – or as any type of professional – you too can find you will need to better align your energy levels with your job. And efforts for better alignment will pay off big time.

My biggest takeaway from the book.
I certainly appreciate the new perspective on managing energy instead of time. But for me, the one thing that really stuck was the notion of taking time to reflect upon performance after a major event. I am going to think now about those kinds of large singular events where it is beneficial to pause afterward to contemplate how well it went and in what ways so I can do even better next time with better long-term preparation.
Think now about those rarer large events where you don’t get to learn from your experience as much as would be ideal. Maybe you too need to pause after those and take some notes for future reference. 

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.

There are two types of people in this world – yes, only two.
Those who have their ideas while sitting on the toilet and those who have their ideas in the shower.
It is in one of these times of solitude and contemplation that they ponder things in their life and insights that have grown deep inside the unconscious psyche burst into the conscious mind.
It is painfully rare for anyone to be in the shower or on the toilet during any kind of review or brainstorming session. And even if they were, these sessions are group activities so there is no solitude – is it more the solitude than the place that is important.
For this reason, you are not likely to get all possible insights from an engineering team in any kind of group session. Be it a design review, a scoping activity, a brainstorming session, a risk analysis activity, basically, any activity where you want as many insights as possible to ensure long-term success.
If you are like me, then you have likely had that annoying experience where you think you have considered all issues and perspectives, documented them, assessed them, and then determined a path forward, only to have one or two people come to you with more ideas, issues, or perspectives.
You appreciate that they are sharing these, but it is still annoying that they come to you after you have done all this work.
You feel like you are going in circles and making no progress as you get dragged back each time. You might even decide to ignore them simply so you can progress – even if it is not the most optimised path you are taking.
The other thing that might occur to you is that while these are the extra ideas that are shared, there could well be other ideas that were had by people who don’t want to bother anyone – given the work that has been done.
It really would have been good to have these ideas presented earlier.
So what to do?
Factor this into the related activities.
Don’t ever assume any brainstorming session, design review, scoping party, gemba walk, risk assessment, or anything else like that will be done in a single sitting. Book one session, run it, give people a break – long enough to have been in the shower or on the toilet – say a couple of days – then have another session.
That way, you can be more sure you have conducted an exhaustive, yet not exhausting, consideration.
Don’t have time for such an approach?
Then simply accept you will not cover everything, and proceed at risk.
Best to factor these extra steps into your plans though.

In this article I will to talk to you about a 3 step process that will ensure you are the type of engineer that gets stuff done – even when relying on other people. And then I will talk a bit more about how this can play out in a global context. Given that there is always an increasing demand for speedier delivery and the world is getting smaller, this can be essential for many engineers.

The driver
Have you ever worked with people who seem relentless and just get things moving? Maybe you are one of these people – in which case, skip to the next section. But it is more likely that you want to be one of these people.

You possibly think they are just demanding or pushy or focused. Certainly you would say that they are driven.

But is it actually a very simple process that they follow to make things happen. And here it is:

1. You want or need someone to do something, so you send them an email and wait a set period (you decide what that is) for a reply to confirm or clarify.
2. If you do not get a reply within that period, then you make a call to clarify and confirm action will be taken – or maybe resolve some issues – before noting the new deadline. You might of course need to leave a message
3. If that deadline is reached or they do not call back, then you go to see them physically (at their desk or office) to talk more about the thing you need done. You then resolve and confirm action to be taken. You probably also summarise in an email so you can ensure there is a shared document of what was agreed, and you can go back to step 1.

As you take in the above 3 steps you can understand how following these will ensure your task (when reliant upon others) will get done faster. You also might be thinking that you would use a messenger service instead an email or you might do a video call instead of seeing them. That’s fine, the point is that you have a process of following up and escalating to ensure tasks are done.

So now you know how to be a driver engineer.

The global context
If you want to be a global engineer, then you need to understand how the above process could play out in other cultures (ethnic, national, company and so on).

Not all cultures have the same take on time. What you consider a deadline others will consider a guide. So consider, when you approach someone at a deadline, if you should be talking like something was missed or like you are just following up to see how things are progressing. Also, the other might happen – the person you are talking to will get annoyed if you don’t give them a deadline that will allow them to prioritise their work.

Cultures will vary in how specific their communication is. You might feel that you have been perfectly clear, but people in other cultures could think you are vague or overly specific (to the point of insulting their intelligence). I think this is less likely in engineering because we can often establish, through physical reality, what details are indeed important. But still, it could be an issue to be mindful of.

Hierarchy is another one. Across different cultures who can rightly ask someone to do something (based on the position of the two people) varies. Therefore, from the onset, ensure that you in a position that is suitable to make the respective request of that person – you might be OK to talk directly to them or you might need to speak to their manager or you might need to speak to your manager who will then speak to their manager who will then speak to them.

Finally, consensus. Make sure you can just ask the other person to do something. It might be that you are expected to engage first to ensure everyone involved agrees before any action is take. The three steps above assume that, if required, you have already done this.

Happy driving
I hope that you now find your tasks, when reliant others, are completed in a more timely manner. Whether you be in a different culture or not.