It’s a new project or part of one.
It needs to be delivered quickly. It also needs to be reliable, inexpensive, easy to manufacture, easy to service and compliant with all applicable standards.
There’re only enough resources (time, people, money) for one serious attempt.
So the obvious plan is to simply get it all right the first time.
And everyone seems to be onboard with the idea.
This is home run engineering.
It’s the belief (actually it’s hope) that an engineering team can step up to a new and complex challenge, take one enormous swing, and achieve everything in one go.
It sounds ambitious. Some would say aggressive. It is usually naive.
And it can tell you something important about whether you should remain with your current company or not.
What is home run engineering?
In baseball, a home run allows the batter to complete the entire circuit in one play. There is no need to progress from base to base through a series of smaller hits.
Home run engineering follows the same logic.
Instead of developing, testing, learning and improving, the organisation expects one major effort to produce the finished outcome. The first prototype is expected to be close to the production design. The first implementation of a new process is expected to work across the entire organisation.
The term itself will rarely be used. Because no-one wants to admit they’re doing it.
You might instead hear:

• We need to get it right the first time.
• We only have one shot at this.
• There is no time for another prototype.
• Failure is not an option.

It might even be described as a Hail Mary. Although that expression usually refers to a desperate final attempt, so it’s wore honest while being just as concerning. Home run engineering is more often placed in the project plan from the beginning.
The language can make the approach sound focused and courageous.
But confidence is not an engineering method.
Why companies try it
Home run engineering normally appears when corporate strategy and engineering reality are no longer aligned.
The company might have promised a delivery date before the engineering work was properly scoped. It might have committed to a fixed price without understanding the technical risk. Or it might simply have fewer engineers, less money or less time than the challenge requires.
None of these pressures changes the engineering reality.
They only create an incentive to pretend that reality is different.
It is not really a national culture issue. Although cultures that are more heavily influenced by notions of karma and mind over matter might be more susceptible to this tendency.
It is mostly an organisational culture issue.
This can happen more often in a startup where:

1. the runway is more likely to be disappearing as funds dry up, or
2. earlier evaluation trials were less demanding so people are not accustomed to the greater demands of actual implementation.

But it can also happen in a large and established organisation. Probably where a senior manager has made a commitment and does not want to take it back.
Co-evolution means you cannot know everything at the start
In my book on being a global engineer, I discuss the notion of co-evolution.
Many people describe engineering development as iteration. You develop a solution, test it, make changes and then try again.
But there is more.
As you develop the solution, you also develop your understanding of the problem. The problem and the solution evolve together.
You do not merely improve the answer.
You improve the question.
This is why prototypes reveal issues that no meeting, calculation or simulation identified. A component is more difficult to assemble than expected. A user holds the product differently from how the designers imagined. A supplier cannot maintain a tolerance. Two individually successful subsystems behave differently when connected.
This perspective should show to you just how risk the home run engineering approach can be.
Example 1: There was no obvious way into space
Today, when you think of early human spaceflight, you probably imagine a capsule on top of a rocket.
It seems obvious.
But it was not obvious at the time.
A NASA history of the early space program describes four different American approaches to putting a person into space:

1. The research aeroplane. Fly higher and faster until the aircraft reached the fringes of space.
2. The ballistic vehicle. Put a capsule on top of a rocket, launch it into space and let it return through the atmosphere with little aerodynamic control.
3. The boost-glider. A rocket would boost a winged vehicle into space and it would return by gliding through the atmosphere.
4. The lifting body. Something between a conventional aeroplane and a ballistic capsule. Its shape would generate some lift without relying upon large wings.

These were not four minor variations of the same design. And none were a clear home run. All involved knew that different approaches needed to be explored.
And the Soviet Union did something similar. They used competing design bureaux, each exploring its own idea:

• Korolev’s bureau developed the spherical Vostok ballistic capsule.
• Pavel Tsybin’s bureau worked on the PKA, or Lapotok, a reusable gliding spacecraft.
• Vladimir Myasishchev’s bureau developed the M-48/VKA-23 spaceplane concept.
• Vladimir Chelomey’s bureau then pursued its Raketoplan and Kosmoplan families of reusable spacecraft.

Obviously, space travel is a major task, and no-one would suggest a home run approach. But it is a reminder to think seriously about the size of the challenge being taken on.
Example 2: The modern car
Consider the layout of a modern car.
Usually there are four wheels. The front wheels steer. The driver uses a steering wheel and pedals. In a conventional internal-combustion vehicle, the engine has commonly been at the front.
This arrangement now seems obvious.
But it was not obvious to the early automotive engineers.
The Benz Patent-Motorwagen had three wheels, a rear-mounted single-cylinder engine and tiller steering. Other early vehicles used steam or electric power. Engines appeared at the front, rear and beneath the occupants. Controls included levers, tillers and pedals in combinations that would feel completely foreign to a modern driver.
It took considerable trial and error of an entire industry to get to the layout we now have.
Example 3: The first successful aeroplane
The Wright brothers provide another example.
Their successful powered flight in 1903 followed years of experiments with kites and gliders. When their 1900 and 1901 gliders did not perform as expected, they did not simply build a larger engine and hope for the best.
They questioned the data.
They built a wind tunnel, tested many wing forms and used what they learned in the 1902 glider. That aircraft helped them develop the control knowledge and piloting skill required for powered flight.
The famous flight was not a home run.
It was the visible result of many earlier swings.
Different engineering: different speeds (how a move could bring you unstuck)
Home run engineering can become especially likely when someone moves from an industry in which changes are relatively fast and inexpensive into one where each learning cycle is slower and more costly.
Consider the following:

• A software team might release an update, observe its performance and issue another version within days.
• An electronics change might require a new board revision and further compliance testing.
• A mechanical change might require new tooling and another physical build.
• A civil engineering change might involve approvals, heavy equipment and concrete that cannot simply be rolled back.

This is not an absolute hierarchy. Some software changes are extraordinarily consequential, and some mechanical prototypes can be modified in minutes.
The point is that the cost and speed of learning differ between engineering contexts.
So if you move industries or work with another one, take the time to understand just how involved a project is. Lest you be the one asking for a home run.
How to recognise home run engineering
You will know it when you see it, even though nobody will use the term.
Some signs are:

• The first prototype is expected to be suitable for customers.
• There is funding for implementation, but not for exploration.
• The schedule contains design and delivery, but no meaningful time for learning and redesign.
• Tooling, procurement or construction begins before major uncertainties have been resolved.
• Testing is planned only as final verification.
• Engineers who raise uncertainty are described as negative or insufficiently commercial.
• The project can succeed only if every major assumption turns out to be correct.
• People throw the term “calculated risk” around without actually doing the calculation.

One of these signs does not automatically mean the company is badly run. But if you start to see a pattern of such things then consider a move.
When it’s time to leave
Every company will occasionally create a bad schedule or make an overconfident commitment.
That alone is not a reason to resign.
What matters is what happens when engineering reality becomes clear.
Does leadership adjust the strategy? Does it reduce the scope, move the deadline, add resources or create a staged development plan? Are prototypes treated as learning tools? Are engineers rewarded for revealing problems early?
If not, and your company repeatedly relies upon home run engineering, and refuses to change when the problem is made clear, then it might be time for you to take your engineering ability somewhere else.

The importance of politeness for a global engineer might seem apparent. In different cultures there are different types of etiquette and thus different definitions of being polite. However, you might be surprised by its importance in engineering in general and how it can be a double-edged sword.
In this edition, I am going to explain first of all why politeness is important for all engineers, how it can also be problematic, and how to manage both extremes within a global engineering context.

First the good: So why is politeness important for engineering?
When we are polite, we ensure we act in a manner that keeps others engaged. Think about times when someone has been impolite to you. Even if they did not mean it. You felt less inclined to engage with that person. That in turn means you are less likely to share your ideas with them to gain input (preventing the identification of issues or the generation of new ideas). You are also less likely to contribute to anything they are working on (meaning they could encounter issues that would otherwise be noted earlier, or they will miss out on other ideas that could have been generated).
In short, politeness allows you to engage better with others so that you can improve your broader understanding of the engineering challenges you face. This is very important for concurrent engineering and shared situational awareness – both of which are related to systemic thinking. But it can also help with leveraging other people’s understanding of first principles and considering new frames.

Now the bad: And how can politeness be a problem in engineering?
As important as politeness is to good engineering practice, the success of any engineering system depends upon the fundamentals of reality.
The general goal of politeness and manners is to help us get along with each other so that everything is better ordered and more effective. That’s why we can feel that raising issues will disrupt the order of things.
But if you do not call out every issue you can, then there is a greater chance of an engineering system failure. Sometimes our politeness (sometimes in the guise of etiquette) will dissuade us from saying anything. It does not feel right to point out an issue in something with which everyone seems happy, or at least not too unhappy; even though we know the implications.

So what do we do about this in the global engineering context?
The most impolite thing you can do to someone is to not involve them. So get into the habit of thinking about who should be involved in the development and implementation of whatever engineering system upon which you are working. And then, of course, involve them.
How you involve them, however, can be very culturally dependent. Some cultures prefer you talk to the person’s manager to gain permission first. Some cultures have very clear “rules” on when you should and should not talk to someone – maybe you can talk to them during lunch or maybe you can’t. These are nuances you will need to manage on a case-by-case basis. However, it helps to err on the side of caution – you do not upset people by being too polite.
The next most impolite thing you can do is involve people who do not need to be involved. So also ask yourself if someone really needs to be involved or if you are insulting them because they have bigger issues to deal with. The CEO wants to know that welds are being properly checked, but they likely don’t want to spend their time reviewing the top 5 non-destructive testing machine technologies you have selected.
A system that can help with this is RACI. You might have heard of this – it is fairly common – but don’t worry if you have not – it is a simple system that is ideal for formalising this type of politeness. RACI is where you determine and document: who should be Responsible, who should be Accountable, who should be Consulted, and who should be Informed. Once you take this step, this system will compel you to think more deeply about how to best work with your colleagues and compel you to keep everyone informed. No-one feels left out, and no-one is bogged down in insulting minutiae.
Also, if you do this right (so take your time with it), then those who might otherwise feel they can’t speak out will be actively consulted. By having the RACI documented and shared, people know that they are expected to give their thoughts – and maybe even be accountable if they do not. This helps give them the confidence to speak up without feeling impolite.

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. ​