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.

This newsletter is all about how you can be the sort of engineer who can work, and be valuable, in any company in any part of the world.
Obviously, to do this, you need to be a good engineer.
But is that all?
This edition is about how being a good engineer can actually limit your ability to be a global engineer.
How is this so?
An interesting piece of research that I note in my book – The Global Engineer – found that people who are competent often fail when deployed in new cultures and places whereas those who are less competent show higher levels of success.
Why is this?
The research found that competent people were unaccustomed to finding things difficult. Because of their competence, life had, on the whole, been easy. Then, in a new environment, where they had less experience, they encountered challenges. This made them feel less adequate – a new feeling for them and one that is unpleasant. They simply could not handle this – and they quit.
Less competent people, who had numerous struggles in life, were, on the other hand, robust. They were familiar with these experiences and the associated feelings. Because of this familiarity, they knew how to push through and carry on. Thus, they were more successful.
The lesson for the global engineer?
Yes, you should always work on your engineering skills. You might even be lucky enough to have had them all the time – or at least for long enough that you can’t recall being incompetent. But, if you do wish to ply those skills in a new context, then be ready for a period of discomfort and displeasure – the type that makes you feel less than you used to feel about yourself and question if you were ever truly a good engineer in the first place.
Ask yourself now these two questions:

1. When was the last time you felt discomfort because your competence seemed lacking?
2. Would you be able to endure a period of such “incompetence” as you moved from one role to another (and it might be because of things outside of the role – say a new country or culture) in your efforts to be a global engineer?

They will help you determine if you have or if you need to develop this toughness to be a global engineer.
For all your engineering ability, it might be this mental toughness, needed to get through such periods, that actually makes you a global engineer.

This is the next article in the culture check series. The previous ones looked at Western and Sino backgrounds. This time, I am focusing on an Indian background.
As before, this about recognising tendencies that can arise from a cultural, philosophical, and economic environments. You might recognise yourself in parts of this – I have a Bangladeshi colleague who describes his home country as an Islamic nation with a Hindu culture. You might recognise colleagues – depending upon where you work. Or you might see none of it at all. The point is awareness so that we can grow as engineers.
And, as with the other articles, I am focusing on potential limitations. Engineers like problems to solve.
There are three aspects I will consider: the perennial caste system, fatalism, and economics.

Caste and the idea of “the right way” and staying in your lane
The caste system, while officially dismantled and certainly less rigid than in centuries past, has had a long and deep influence on Indian society. It organised life around inherited roles. If you were born into a particular group, there were expectations about what you would do for the rest of your life to make an income.
It is wise to note that there were reasons such systems existed. One benefit often overlooked is environmental continuity. If your family and descendants were going to fish the same waters for generations, you had every incentive not to overfish and protect those waters from others. Long-term role continuity can create long-term stewardship – there is a reason this land was able to support so many people. I am not defending the system; I do not care for it, personally, but it did not arise without logic.
But there were not just expectations about what you would do within your caste. There would often be implicit understandings about how it would be done. This would be handed down from one generation to the next because it was established that it would maintain the balance of things. It could also dictate what you should not do – to make it clear which caste you are in.
Often, discussions about the caste systems focus on organisational and social mobility. That is not my focus here. There is plenty written elsewhere about promotion, opportunity, and structural reform. What I am interested in is something more subtle.
When a society has long embedded the idea that roles come with prescribed practices, it can create a strong psychological tendency toward standard procedure.
In engineering, this can show up as a preference for:

• Established standards
• Accepted methods
• Approved processes
• “The way it is done”

Now, standards are not the enemy of engineering. In fact, they are often essential. They encapsulate accumulated knowledge. They protect safety. They provide consistency.
But engineering excellence is not the same as procedural compliance.
If your background encourages the belief that there is a correct, inherited way of doing things, you may be less inclined to reframe a problem. You may ask, “What is the standard process here?” before asking, “Is this the right problem?” That is a subtle but important difference.
Framing is about questioning the boundaries and assumptions. It is about asking whether the standard process even applies in this context. A cultural leaning toward prescribed practice can sometimes make that reframing instinct weaker.
Still, when translated into engineering, the “there is a way” mindset can become a constraint.
Then there is the issue of being a sensual engineer. I have spoken before about the benefits of experiencing the physical aspects of a problem. Touching the thing that is of consideration, listening to it, taking it apart yourself and putting it back together. In the caste system, for many who become engineers, this physically and be an anathema to one’s caste. Thus, the caste system can sometimes limit the experience and perception an engineer will have of an engineering challenge.

Karma, fatalism, and first principles
Another influence often associated with Indian culture is the idea of karma. Whether one believes in it literally or not, when you grow up in an environment where ideas of fate, destiny, and moral causation are frequently discussed, it can subtly shape perspective.
One possible tendency is fatalism.
If something does not work, it may be interpreted as “not meant to be.” If a project fails, there can be a sense that forces beyond control were at play. Even without conscious belief, this ambient perspective can influence how problems are approached.
In engineering, this can weaken first principles thinking.
First principles require you to assume that outcomes are governed by natural laws. If something failed, it failed because of identifiable causes. If something works, it works because of physical relationships. There is no moral dimension. There is no destiny. There is only cause and effect.
A fatalistic undercurrent can reduce the instinct to dig back to fundamentals. It can encourage trial and acceptance rather than analysis and derivation.
Further, it can result in acceptance of how things are – for oneself and others. This is not what engineers are meant to do. They should always be thinking of ways to make thing better for all.
There is, however, another side to this.
Karma can also be interpreted as personal responsibility and perseverance. If you are being tested, you might iterate relentlessly. You might refine and adjust repeatedly to prove worth. In that sense, the same philosophical environment can produce extraordinary persistence.

Developing economy and the power of jugaad
India has developed rapidly, but it remains shaped by decades of operating under resource constraints. From that environment has emerged something widely recognised and even celebrated: jugaad.
As described in Jugaad Innovation by Navi Radjou and his co-authors, jugaad refers to frugal, improvised innovation. It is the art of making things work under severe constraints.
The classic example is the missed call. You ring someone a predetermined number of times and hang up before the call connects. They see the missed call from you with the set number of rings, and they know to meet you at the station. No cost incurred. Communication achieved.
That is ingenuity.
From an engineering perspective, growing up in an environment where cost sensitivity is constant can create a powerful instinct to optimise for affordability. You become highly alert to waste. You find alternative paths. You adapt quickly.
This is an advantage.
However, constant adaptation can also create inconsistency. Engineering systems often rely on repeatability, traceability, and disciplined configuration control. If ad hoc cost-saving improvisation becomes habitual, systemic robustness can suffer.
Systemic thinking requires you to ask not just, “Does this work now?” but, “What are the long-term interactions across the whole system?” Jugaad can sometimes prioritise immediate functionality over systemic integrity.
​
What does this mean for you?
If you are from an Indian cultural background, then ask yourself:

• Do I default to standard procedure before reframing the problem?
• Do I ever attribute outcomes to circumstance before returning to first principles?
• Do I optimise for cost at the expense of systemic robustness?
• Do I avoid physical aspects of engineering because they I think they are beneath me?

If you work with Indian engineers, or are moving to India, ask similar questions from the other side:

• Am I misinterpreting procedural preferences as lack of creativity?
• Am I undervaluing frugal innovation because it looks informal?
• Am I failing to recognise when persistence is strength rather than stubbornness?
• Do I need to communicate more the value of trying something new and being prepared to be a bit more physical?

As I have said before, your background is not your destiny. But by noting how it affects you, you can improve yourself further.
That is what makes someone not just a local engineer, but a global one.

The article is the second culture check article. The first was about a western background. This one is focused on a Sino background - China and influenced countries/cultures. It might seem extreme to consider one country after considering an entire hemisphere last time. However, China is a big country with a long history – and thus justifies such attention. And, as implied above, the article could also have elements applicable to other countries that have a strong Chinese influence – either through cultural exchange or migration. It is for the reader to decide if this is applicable – either to themselves or those they work with/manage.

Perspective on Knowledge – framing and first principles
There is a cliché about Chinese not being as creative as those from other cultures. However, I can say from my own personal experience working in China that this is not the case. But there is something that can explain why people have this perspective.
It is the perspective on knowledge.

Some view knowledge as something that is external to humans – something to be acquired through exploration. Others view knowledge as something that comes from within humans – those who have something innate and special.

In China, there is a greater tendency to view knowledge as something that comes from within.

This is a result of two broad influences on Chinese culture: Buddhism and Confucianism.

The first brings with it notions of karma – this idea can mean that success is more a function of the character of the person than the laws of nature being understood and used correctly. Being a good person alone would mean that things will eventually work out. The second, often (you will see below why I use the word “often”), extols the value of obeying those in authority for the sake of social (if not cosmic) harmony – that can convey the notion that along with authority comes expertise.

The above can mean that people will be more greatly influenced by ideas that come from those viewed as experts. Therefore, an engineer with a Sino background could be less inclined to consider reframing a problem (or previously presented solution to a problem).

It can also create an environment that is dismissive of first principles. And an engineer might still choose to pursue an idea that is clearly, due to first principles, unviable; solely because someone senior said to. This was something I encountered when doing my research into how cultural background can affect engineering practice.

This tendency for Chinese to view knowledge in such a manner is sufficiently common that a solution, applicable in all disciplines, has already been developed by others.
Folklore precedence matching.

In this process, one looks for an example from Chinese history (or folklore) that is aligned with the approach desired.

Folklore precedence matching for engineering
You could choose to look for something similar to the exact approach desired. But a better approach, I think, is to showcase examples from Chinese history that showcase the approaches aligned with engineering expertise more broadly. These examples can be part of induction, education, training, or regular reminders. Use them anyway you see fit.  

Examples from Sun Tzu.
“The general who advances without coveting fame and retreats without fearing disgrace, whose only thought is to protect his country and do good service for his sovereign, is the jewel of the kingdom.”
The Art of War, Chapter 10 (Terrain)
This shows that the good of the country (company and those who work there) to do service for the sovereign (manager, owner, shareholders etc.) should be what guides actions. That means considering new ideas (framing) and adhering to the laws of nature (first principles); not simply doing as you are told to in hopes of getting approval from others (coveting fame or fearing disgrace).

“There are occasions when the commands of the sovereign need not be obeyed.”
The Art of War, Chapter 8 (Variation in Tactics)
This clearly states that the manager is not all knowing. And an engineer should be free to do as they know is best – using first principles and framing as needed (not to mention systemic thinking, which will come in more detail later).

Example from the Battle of Red Cliffs.
One of my favourite Chinese movies is John Woo’s Red Cliff. And one of my favourite parts is where Zhuge Liang is charged with acquiring 100,000 arrows.
And he needs them fast.
Everyone assumes he plans on finding some way to make them quickly – and they assume he is going to fail. However, Zhuge Liang makes no visible preparations to produce arrows and offers no explanation to his peers or superiors.
Instead, he waits for specific environmental conditions (heavy morning fog) and prepares boats covered with straw. He rows these boats toward the enemy camp, beating drums and shouting at the same time to simulate an attack. Unable to see clearly and assuming an assault, the enemy responds with volleys of arrows. The arrows embed themselves in the straw coverings. Zhuge Liang then withdraws with the needed arrows – collected from his enemy and ready to be returned.
This is an example of the value of the independent expert(s) to get the job done.

An example from Confucius.
Then there is of course Confucius. Confucius is often thought of as someone who encourages people to defer to those in authority – as mentioned above. Also, he is often implicitly viewed as an example of someone who has innate knowledge. Still, he also said:
“In serving one’s lord, one should remonstrate with him when he does wrong.”
Analects 14:22
This implicitly states that there is an objective truth (first principles) and that these should be adhered to.
The above examples provide a way one can leverage Chinese folklore precedence matching to establish a culture and environment aligned with good engineering practice. And this can change the perspective of people at any level within the engineering team. Remind them of these principles and, from that, emphasize the importance of engineers:

1. Relying on first principles to guide their decisions, and
2. framing problems differently when there is value in doing so.

An idea can come from anyone – not just those in authority.

Organisational maturity – systemic thinking
China has progressed economically at an amazing rate over the past decades. There have, along with that, been improvements in regulation, research and development, education, and business management. However, there are still significant areas of China heavily influenced by earlier practices – including those of the communist era.

One practice that is significant in the context of engineering expertise is the division of labour.

When it comes to production, there is no substitute for the division of labour. Early estimates by the economist Adam Smith noted an improvement in productivity of 206 times when using the division of labour.

And it is tempting for managers who have seen the power of the division of labour in production to then erroneously use it in engineering practice. Putting each engineer in their own Dilbert-esque desk and having them focus on one specific task in the engineering process. Because of the large number of managers in China who have come from production, there is a greater tendency for this practice to occur in China.

There are many issues with this approach regarding good engineering practice and outcomes. However, for the engineers in this situation, their ability to think systemically, given they need to focus on a single task all the time, atrophies.

This, based on the experience of a colleague working in China, can be addressed by simply steadily expanding the scope of engineering works. Something that has atrophied from neglect can be strengthened from exercise.

Thus, if you are an engineer with such a background or managing such engineers and you want an increase in systemic thinking, then all that’s needed is a steady increase in the number of systemic issues that are to be factored into any task.

Closing
In the above I have shown how a Sino cultural background, particularly as expressed in China, can influence engineering practice in subtle yet important ways. But it could be useful for Taiwan, Singapore, Malaysia – any part of the world influenced by Chinese migration – or any other culture that shares similar philosophies. By examining perspectives on knowledge, authority, and organisational structure, it shows how framing, first principles, and systemic thinking can be weakened when expertise is overly associated with hierarchy or when production practices are misapplied to engineering work. Importantly, it also demonstrates how Chinese philosophical and historical examples can be used to reinforce good engineering practice, offering practical ways for engineers and managers to align cultural context with engineering excellence.

This is the first "culture check" article I will write that will specifically look at different backgrounds (in a fairly broad sense because there are so many of them) and how it could cause issues in your engineering. I am focusing on the negative aspects because engineers love having problems to solve.

What are the key attributes of western culture?
Western cultures are typified by a longer period of wealth and a stronger focus on individualism over the focus on the group. There are other aspects, but these are the ones that I will focus on in the context of engineering – because they are the ones that proved significant in my research.
​
And the effect on engineering?
If you are from a wealthy western country, then you are, most likely, from a post industrialised society. That means the majority of wealth comes from the services and knowledge industries – and it has also been like this for some time. And manufactured goods are frequently considered ultra-cheap; thus, the alternative name “The throw away society”.
In such a society, we become more interested in customised and bespoke products. Brands can hold some sway, but not because they are associated with wealth; because they are usually associated with an image or persona. You can’t as easily convince people you are successful by owning certain brands anymore – because the fact is many could afford something that is practically comparable. Status thus comes from uniqueness and thus exclusiveness.
An engineer from such a society will always have more of a tendency to try something new. But not because they know it will be a better solution – even though it might be. But for the sake of the novelty itself – and the perception that the cost is not that great, nor much of an issue.
Now couple this with the tendency to individualism.
Such an engineer would now be more motivated to pursue such an idea for their own glory. If it helps the company, then great. But if it becomes a success, then they would be more inclined to say “That was my idea” as opposed to saying “That helped to company enter a new market”, “That cut cost and boosted revenue”, that reduced down time” and so on.
Thus, with a tendency to gravitate to the novel without worrying as much about cost and with less thought given to the greater group, the western engineer is more likely to go rogue and be a maverick.
This might be what’s needed at times. But, let’s be honest, good engineering happens when the engineering team is implementing solutions that are aligned with each other and with the business goals.
 
And the practical implications are…?
Western managers are probably aware of this – even if they don’t know it – and can manage it. Acknowledging the great idea and engineering excellence and then noting that in a different context we could pursue it, but, for now, we need to focus on something more aligned with the broader goals. I know I have had to at times.
But if you are from another background, then this is something to be aware of should you ever be managing western engineers. And I mean based on cultural/economic/national background – don’t assume if they have a different ethnicity from what you expect, have some heritage similar to yours, or can speak your language, then they will think like you. These tendencies could still be there.
If you are a western engineer, then ask yourself now, and indeed then, and then then again, if you tend to pursue ideas for the sake of novelty and personal glory as opposed to doing it for the engineering team, the company, and societal, success.  

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.

In this article I will talk about cultural shocks and how to handle them. But I am going to talk more about one that few expect. After reading it, you will be better able to manage transitions between roles and, if you are a manager, help other better manage the transition.
First of all, let’s consider some of the different things that can affect engineering practice and culture. The main ones are:

You can probably understand from the above how you could experience significant differences in how engineers go about engineering as you move from one country to another. Especially when those two countries have very different cultures.
However, when the differences are that large, we are often fore warned (and thus prepared) about those differences.
It is the cases where you expect there to be fewer differences that you are more likely to suffer. The cultural consultant and author The Culture Map, Erin Meyer noted that the case where there is the greatest failure in professional transfer is between the U.S. and the U.K. People assume that the cultures are sufficiently similar enough that they do not need to mind those differences – this complacency then causes issues.
In my experience and from my research though, there is an even greater (and less noticed) factor that can cause issues for engineers: typical budget sizes.
This can have a tremendous effect upon how engineers go about their jobs.

• Do you take larger risks on each step of a program so that you spend less on each step?
• Do you have the time and other resources to optimise every aspect?
• Should you be leveraging of the shelf components and system or using custom designs and services?
• Do you conduct hand calculations or do you utilise a dedicated simulation team?
• Do you rework parts or just scrap them and move on?
• Do you try to make it work with run of the mill materials or can you start trying exotic materials from the onset?
• Are independent test laboratories given the final system so only one test needs to be done, or do you send them a full system after you come up with each new feature?

These are just a handful of examples of the things that can be dependent upon how well funded your engineering project is. But, the list still shows how you could tend to take certain courses of action if you have become accustomed to a certain budget size in the engineering roles you have had in the past.
An example from some of my research.
This was some time ago when I spoke with engineers in the automotive industry. It was noticed that Australian and Chinese engineers were better able to work with each other than either could with American engineers. Why was this, given the greater cultural similarities between Australian and Americans? At that time, the Chinese automotive industry was not the juggernaut that it is today – few had heard of BYD, and Great Wall was only just starting to be associated with cars. Instead, it was an industry that ran on much tighter developmental budgets. Much like the Australian industry also was at that time. Today, while the Chinese industry has grown, the Australian industry is essentially dead – so obviously the trends were in opposite directions while at that time there was an intersection.
What does this mean for you?

1. If you are an engineer changing companies, then really focus on how this aspect of the new company is different (if at all) from what you are used to. Then, each time you are thinking about your strategy for an engineering endeavour, double check if you have made any erroneous assumptions based unconsciously on what you think the budget would be.
2. If you are a manager who has new people coming in, then a good way to help them become accustomed to the new company is to talk to them about how they progressed such projects in the past. Do this within the context of budgets so you can be explicit with them if things are different from what they are used to.
3. If you work across global teams, make budget assumptions explicit early. It prevents mismatched expectations and helps align design philosophy from day one.

Budgets can be more of an issue than cultural differences (or even a cause of those differences). Noting the above will help you be more of a global engineer and let better managing this rarely considered issue. ​