There is a philosophy of engineering that states:
If you need or can make a choice or any kind of decision, then you have not collected enough data.
The intent of the philosophy is to argue that if you fully understand a problem – the constraints, the valued attributes, the relative value and cost of each attribute and each failure mode – then there is only one solution. And if you find you need to make any kind of decision – as opposed to completing an analysis – then you need to collect more data.
This is similar to the white hat thinking proposed by Edward de Bono, where one focuses on collecting facts and data. De Bono noted that this was very much a Japanese way of thinking – collecting facts as opposed to arguing for one’s point of view. It was argued by others that this was the approach the Japanese used when they dominated the automotive and other industries in the 1980s and 1990s. They understood exactly what the customer wanted and valued, the cost of each option for satisfying those wants and values, and the opportunities for reducing those costs. With all that in hand, the solution would become obvious.
Let’s now consider this philosophy further to assess when it would be viable, when it might be desirable but not practical, and what it could mean for you and how it could improve your engineering.
When it’s viable – When you have time and money
This philosophy is viable when you can afford to understand the problem fully.
If you know what the user values, the constraints, the likely failure modes and the cost and performance of each alternative, then the weaker options should eliminate themselves. What initially appeared to be a decision becomes an analysis.
However, obtaining that understanding can take time and money. You need to speak with users, consult the people who will manufacture and maintain the system, complete analyses and perhaps conduct experiments. You therefore need an organisation with sufficient resources and an appreciation of the value of this work.
It’s worth noting that not all large organisations with the necessary resources appreciate its value – that’s a result of culture.
When it’s impractical – You’re in new territory
The philosophy becomes impractical when the required information does not yet exist.
Think start-ups or the need to get to market before a competitor.
You either lack the resources or you lack the time.
You don’t ignore the facts you have, and you don’t choose to collect nothing.
Instead, you work with what you have, make the best decisions you can and be ready to respond when you discover that you have made a mistake after proceeding at risk.
What it means for you – Do you at least try to use facts to guide your thinking?
After reading about the two cases above, how do you deal with the need for facts?

• Have you usually not bothered with them and relied on your own point of view – much like the unappreciative large organisation?
• Have you always wanted more data but done your best without it – like a start-up, even if you don’t work for one?
• Have you valued such data and been lucky enough to work for a company that collects it?
• Have you been paralysed by too much data and not known how to use it?

The fact is that facts help. And facts are found in data.
You should try to give every decision some factual basis. This could come from customer research, user research, analysis, hand calculations, simulations or whatever else is applicable.
And when you lack the data and can’t obtain it, be honest with yourself and others about the possibility of things going wrong and corrective action being required.

In 1776, Adam Smith published The Wealth of Nations.
In it, he described a small pin factory.
Making a pin involved around eighteen separate operations. Someone drew out the wire. Someone else straightened it. Another person cut it. Another pointed it. Others made and attached the head, whitened the pin and placed it into paper.
Smith observed a factory where ten people, working in this manner, could produce around 48,000 pins in a day.
Working separately, he estimated that each person might struggle to make twenty pins in a day. Some might not even produce one.
That is an extraordinary increase in productivity – he estimated around 240 time more productivity when you have the division of labour.
Instead of everyone learning and performing the entire process, each person became proficient at one small part of it. Time was not lost moving between tools and activities. Skills could be developed for each specific operation. Equipment could be optimised for individual tasks.
This is the division of labour. And it is key to the wealth we enjoy today in the modern world.
And it is tempting for many engineers to think the same approach can work in engineering practice.
A pin factory production line is not the same as an engineering problem
The division of labour really only works when everyone knows exactly what needs to be done.
In Adam Smith’s example, no-one was trying to determine what a pin should be.
They were not debating whether the pin needed to be longer, stronger, cheaper or easier to package. They were not investigating whether users really wanted a pin or whether a different fastening method would serve them better.
They were just making pins.
And that’s not what engineering is like.
When taking on an engineering problem, the solution is not fully understood at the beginning. Often, the problem is not fully understood either.
If everyone goes off not even knowing what the problem is, then they will work on a different set of assumptions – and the outcome of their work will not integrate with that of others.
You will just end up with things not working, people blaming others, confusion, and lost time.
Good engineering practice can look inefficient
Because engineering problems are so large these days, no-one person has a full understanding of them – or of the solution. Especially at the early stages.
This means that people need to keep talking to other to share what they have found about the problem and ideas that they have had for a solution.
This in turn keeps the team on the same page – what is known as shared situational awareness – so that the team works well together, and produces a well informed and complete solution.
The division of labour does still matter
It is always handy to have specialists. They should be part of your team and involved in concurrent engineering activities.
And any engineering solution put should leverage the division of labour for its implementation. And you will be better able to generate such a solution when your team is working together – and not in separate sections of the overall project.
The lesson
Adam Smith was right about the extraordinary productive power of the division of labour.
But it is a tool that engineering teams should use to implement their solutions effectively, it is not the way engineering teams should be run.

It is human to go with what FEELS right. Humans have evolved to be instinctive – like all creatures. We are lucky to be living in a time when humans have developed the notion of logical thought and pre-emptive action. Without such thinking, engineering would not be close to as advanced as it is today.

That means you will always have a tendency to make subjective and instinctive decisions. The decisions that will lack the soundness of thoughts that ultimate engineering decisions possess.

This tendency, in turn, means you need something to help keep your mind focused and disciplined.

Within this context – the need to ensure complete and informed thinking for solid decisions – you can understand how things like FMEA, QFD, ODI, DMAIC, have each become a thing. There is frustration with engineers not considering important aspects, so something needs to be done to note all the issues to be considered.

You could argue that these are just glorified checklist – and I sometimes do when people do not use them as an integrated and serious part of their engineering process. This usually happens when the engineer(s) involved have not realised themselves that they tend to lack discipline in their thinking. Have you ever noticed how the people who realise they could improve their thinking or approach are the ones who need to improve less than the ones who think everything is fine (or even really good)? Well, such people will not see the need for these tools and thus not use them – or pretend to use them. I have seen many engineers do an FMEA at the end of a project – basically hoping (they would say “knowing”) there will be no issues.
The lesson here is that you should view such tools as a way to enhance your engineering.

Even make it more enjoyable.

When you use these tools to efficiently collate information and needs, you then have more time to focus on the creative and exploratory side of engineering. You know what needs to be done and how success is measured so your open-minded thinking and creativity is now well informed. So, you can really lean into it.
​
And then when you have engaged in this free thinking, you have a clear method of assessment to ensure the outcome is aligned with needs that initiated the effort in the first place. This is similar to Daniel Kahneman’s suggestion that humans always better select an alternative when they use a formula based on the identified requirements.

But how can these tools help the global engineer specifically?

In her book The Culture Map, Erin Meyer noted a number of factors that change how culture can affect decision making. Things like: a stronger focus on either how or why, what is considered polite when noting issues, and who normally makes decisions based on seniority.

These differences in approach to making a decision can cause tension in a mixed team of engineers.

Therefore, bringing in an objective and transparent method of assessment can align all team members in effort and assessment of options. This alignment will reduce stress and increase productivity in such teams.
So when you start your next project, for the sake of better engineering and better team alignment, think about which objective assessment tools you can incorporate to get everyone on the same page.

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.

Depending upon the part of the world you come from, there is an implicit assumption about whether or not an engineer uses tools. In some countries, it is assumed that it would be beneath an engineer, as a professional, to use tools. They are meant to be cerebral professionals. In some other countries, the word “engineer” is conflated with a number of different trades, and it is assumed engineers do little other than use tools. You will also find places that sit between these two extremes.

I am not going to have that debate here. You are an engineer, and you know what your specific role requires. Maybe you do use tools at times to do your work. I have been there. Maybe you work at a place where an engineer picking up a tool would cause a strike. I have been there too.

Instead, I am going to talk about the benefits of knowing how to use tools and why there is indeed a place for craftsmanship in engineering.

In a prior article, I mentioned the notion of the sensual engineer. The idea is that, by using all your senses, you can become better informed about any challenge you are facing and thus develop a better solution. When one has experience using tools, one can enhance the ability to imagine through multiple senses because making something provides sensory information about the object as it takes form.

Not only that, when you know how to use tools, you can explore the solution space as you try different ideas through rapid prototyping. This also increases your understanding of the problem. You will recall, if you have read my book on global engineering, that this is coevolution, where solving the problem helps you better understand it.

In earlier forms of engineering, the design of a solution often occurred as it was physically implemented. Read the excerpt below from Homer’s Odyssey. This is where Calypso is helping Odysseus build a raft. Note that, as Homer describes the act of making the raft, he also describes the design decisions being made. The passage depicts a form of engineering in which design and implementation occur together.

She gave him a great axe, well fitted to his hands, an axe of bronze, sharpened on both sides; and in it was a beautiful handle of olive wood, securely fastened; and thereafter she gave him a polished adze. Then she led the way to the borders of the island where tall trees were standing, alder and poplar and fir, reaching to the skies, long dry and well-seasoned, which would float for him lightly. But when she had shewn him where the tall trees grew, Calypso, the beautiful goddess, returned homewards, but he fell to cutting timbers, and his work went forward apace. Twenty trees in all did he fell, and trimmed them with the axe; then he cunningly smoothed them all and made them straight to the line. Meanwhile Calypso, the beautiful goddess, brought him augers; and he bored all the pieces and fitted them to one another, and with pegs and morticings did he hammer it together. Wide as a man well-skilled in carpentry marks out the curve of the hull of a freight-ship, broad of beam, even so wide did Odysseus make his raft. And he set up the deck-beams, bolting them to the close-set ribs, and laboured on; and he finished the raft with long gunwales. In it he set a mast and a yard-arm, fitted to it, and furthermore made him a steering-oar, wherewith to steer. Then he fenced in the whole from stem to stern with willow withes to be a defence against the wave, and strewed much brush thereon. Meanwhile Calypso, the beautiful goddess, brought him cloth to make him a sail, and he fashioned that too with skill. And he made fast in the raft braces and halyards and sheets, and then with levers forced it down into the bright sea.
Homer, The Odyssey, Book 5, lines 234–261, translated by A. T. Murray.

I should note that Samuel C. Florman introduced me to the idea that this passage highlights both an early form of engineering and the sensual nature of the work in his book The Existential Pleasures of Engineering.

Upon reading this text, can you sense the deep connection between the designer-engineer, Odysseus, and the vessel taking form because he is the one forming it? He sees the materials first-hand, so he can understand their suitability for the task. He understands that the tree trunks must be straightened so they can be fitted together. He can see where the mast and steering oar will sit as he constructs the vessel, and he can see the need to protect against the waves. Each action provides a better understanding of the challenge and what needs to be done.

If Odysseus were later to draw up plans for another vessel, perhaps an improved one with features not yet tried, you could be sure that he would understand the nuances of its implementation: how it would be made, how it might fail if poorly made, which features would be difficult to make well, and what would be needed to implement it. Having had this experience, he would be a better engineer.

This is, of course, from a very different time. So what does it mean for you?

Today, you could not practically hope to have the skills and experience of all the craftspeople involved in executing most engineering tasks. Instead, experience using tools can provide additional, rather than complete, insight.

It can also help you better understand the people you work with as you discuss the challenge and potential solutions. Experience and know-how with tools will improve your ability to understand both the challenge and the ideas put forward by others. That will make you a better engineer.
​
So yes, engineers should know how to use tools. You should also continue developing your craftsmanship because the experience of making things will help you more fully explore the engineering challenges you face.

Some time around the year 2000, I watched a documentary about engineering. In it, former JPL engineer and Mars Exploration Program manager Donna Shirley said something that has stayed with me ever since:
Scientists do the work of God; engineers do the work of man.
I have since found that the line is also associated with Bruce Murray, the planetary scientist who was once director of the Jet Propulsion Laboratory. In a Caltech oral history, Louis Friedman, another JPL engineer, said Murray was fond of using it. Whether Murray actually came up with it, I do not know. But Donna Shirley was the person I first heard say it, and it has influenced how I think about engineering ever since.
So what does it mean?
And what does it tell us about the kind of work every engineer should be doing?
I think it tells us that every engineer is a design engineer.
In this article, I am going to explain why the difference between science and engineering means design is not a specialist activity within engineering. It is what all engineers do, or at least what they should be doing.
Even if you never open CAD.
Even if you never develop a new product.
Even if the systems you work on are made from documents, processes and people instead of metal, concrete and electronics.
The work of God and the work of man
The line is not really about religion.
The “work of God” is the universe as it already exists. Scientists seek to understand that universe. They want to know why things are the way they are. Why does gravity work as it does? Why does a material behave in a certain way? Why do cells react to a particular chemical? Why does a star produce the spectrum of light that reaches us?
Scientists observe, develop theories, form hypotheses and then conduct experiments to see if those hypotheses survive.
Engineers use that understanding to do something.
We create a system that did not previously exist, or deliberately change one that does. The result might be a bridge, a medical device, a production line, a maintenance program or a document-control process. But in every case there is an intended outcome for people.
That is the work of man.
This does not mean scientists never make things or that engineers never seek understanding. A scientist might create a remarkable piece of experimental equipment. An engineer investigating a failure might spend weeks trying to understand why a physical phenomenon is occurring.
The difference is the main purpose of the work.
Science succeeds when it produces reliable knowledge about the universe.
Engineering succeeds when it produces a useful intervention in the world.
Do we ever truly understand the universe?
I will note here that I lean toward being a scientific anti-realist.
This does not mean that I am anti-science. Far from it. I think science is the best tool we have for understanding the universe. Nothing else has come close to producing the same consistent, testable and useful knowledge.
I am just not convinced that we can ever reach a final and completely true understanding of reality.
Our scientific theories might be extremely useful models. They can predict what will happen, explain observations and allow us to develop remarkable technology. But are they descriptions of what reality actually is, or progressively better ways for a human mind to represent what it observes?
Fortunately for engineers, usefulness is usually enough.
An engineer does not need a final metaphysical understanding of gravity before designing a foundation. We need a sufficiently accurate model for the conditions and consequences involved. We need to know what decisions to make.
That does not excuse poor understanding. First principles, as I note in my book on global engineering, remain essential to expert engineering. But the goal is not merely to know. The goal is to use what we know to produce the desired outcome.
Making something work is not the same as engineering it
A scientist might need an experimental system to prove or disprove a hypothesis.
It needs to work well enough to produce trustworthy evidence. It might only be operated by the person who built it. It might only need to work once. It can be temperamental, expensive, slow and difficult to use, provided those characteristics do not undermine the experiment.
Of course, many scientific systems need far more than that. The equipment used at facilities such as cyclotrons can be extraordinarily sophisticated, reliable and precise. That is one reason engineers work at such facilities. The scientists determine what must be observed. Engineers help create the system that will allow the observation to be made safely, reliably and repeatedly.
Once something must work for other people in the real world, the nature of the challenge changes.
Now we need to ask:

• Who will use it?
• What are they actually trying to achieve?
• In what environment will they use it?
• How reliable must it be?
• How much can it cost?
• How will it be manufactured, installed, operated and maintained?
• What happens when something goes wrong?
• What trade-offs will the user accept?

Answering these questions and configuring the system accordingly is design.
This is why making a prototype operate on a laboratory bench is not the same as engineering a product. It proves that an idea can work. It does not prove that the resulting system is fit for purpose.
Engineering begins when we take responsibility for that difference.
But I’m not a design engineer
You might be thinking that this applies to engineers who develop products, machines or structures, but not to you.
Perhaps you are a maintenance engineer. A quality engineer. A project engineer. A manufacturing engineer. A systems engineer. An engineer who spends most of the day managing contractors or preparing documents.
You might say, “I don’t do design.”
But what happens when you create a maintenance program?
You need to decide what will be inspected, how often it will be inspected, who will do it, what information they need, how the work will be recorded and what will trigger further action. You need to balance equipment availability, maintenance cost, safety and the probability and consequences of failure.
You are designing a maintenance system.
What about document control?
You need to ensure people can find the correct information when they need it. You need to prevent obsolete information from being used, provide traceability, allow appropriate changes and avoid making the process so onerous that people work around it.
You are designing an information system.
What about planning the laying of foundations?
You need to consider the intended structure, soil conditions, loads, excavation, water, access, equipment, worker safety, inspections, weather and the construction sequence. You are arranging numerous interacting elements to produce a desired outcome.
You are designing a construction system.
What about collecting input from colleagues about job satisfaction?
You need to consider whether people will answer honestly, what questions will produce useful information, how anonymity will be protected, how the results will be interpreted and whether anything can actually be done with them.
You are designing a feedback system.
The material from which the system is constructed does not determine whether design is taking place.
Design can involve physical items. But it can also involve information, responsibilities, decisions and human behaviour.
The common feature is intent. Someone is deliberately arranging the elements of a system so that it performs a particular function for its users.
That is design.
The danger of thinking you do not design
There is a practical reason this matters.
If you think you are not a design engineer, then you are more likely to accept the systems around you as fixed.
You follow the maintenance program because it is the maintenance program.
You complete the form because that is the form.
You call the meeting because the process says there should be a meeting.
You use the construction sequence because that is how the last project was completed.
You stop asking whether the system is actually achieving its purpose.
And this is how badly designed systems survive. Everyone operates them, but no one accepts responsibility for designing them.
An engineer should instead be asking:

• Who is the user of this system?
• What job do they need it to perform?
• How will we know if it is performing that job?
• What constraints and risks must be considered?
• What is making the system harder to use than it needs to be?
• What could be changed to produce a better outcome?

You might not have the authority to make every change. But you should still be capable of seeing that a change is needed and explaining why.
That is part of being an engineer.
Every engineer designs
Scientists help us understand the universe we inhabit. Engineers use that understanding to create and change the systems through which people live within it.
That means our work must be useful. It must account for the people who will interact with it. It must perform under real conditions and within real constraints. It must be sufficiently reliable, economical, safe and usable for its intended purpose.
Whether the result is a spacecraft, a foundation, a maintenance schedule or a document-control process does not change the underlying responsibility.
You are taking elements and deliberately arranging them to achieve an outcome.
You are designing.
So if you are an engineer, you are a design engineer.
The only question is whether you are designing deliberately.

As a global engineer, you are more likely to take on a role where you know less about the specifics of the domain than others. The reason for this is that you would be chosen for that role because if you understanding of engineering and your ability to adapt. That means you need to know how to pick up domain knowledge fast. Also, as any kind of engineer, you want to be continually improving so you can stay ahead of anyone you might be competing with – either to get a new role or maybe even keep your own.
In this article, I am going to talk to you about simple, no-nonsense methods that can help with this.
Domain expert fast and simple
In my book I shared an experience where I was working on a medical device that was controlling the delivery of fluids via drops. The idea was that if the system could produce consistently sized drops, then the precise volume could be delivered by generating a set number of drops.
I had little idea what determined the size of a drop. I knew it would have something to do with gravity and surface tension, but that was about it. I would not have been able to calculate the expected size for any given system.
Not only that, courses on drop formation are less than rare on sites like Coursera and Udemy. So I would not be able to do a crash course on the topic.
Instead, I went straight to Google Scholar. And I found a number of articles on the topic.
In case you are wondering, the drop size depended upon the following:

• Flow rate
• Viscosity
• Orifice size
• Gravity
• Density
• Surface tension

What’s more interesting; the greater the flow rate, the bigger the drop. The viscosity slows the formation of a weaker shape so the faster you get the fluid in the more that will be in the drop before the neck narrows and breaks.
It would have taken me far too long to work that out. And no-one else on the team knew about it. I became the domain expert in about half a day.
And this was before AI was as well established as it is now. If you were to ask any AI system to extract the key information from recent papers on any domain you choose, then you would have a custom white paper on that domain.
Still, don’t underestimate the value of a course if available.
When I started working in the optics industry, I found an excellent course on Coursera about optical engineering. I assume that, like me, you enjoy learning and even more so when it can be applied. So not only was I gaining the expertise I needed, but I was also having a good time.
In summary, it is simple: look for knowledge sources, from courses to research papers, and start studying – and use AI when needed.
Blitzing the competition
When was the last time you re-read any of your textbooks?
I know I would not re-read them often if not for the fact I have them on display in my study. I am thus compelled to look at them, and then randomly pull one out and read a part of it now and then. A friend of mine was more disciplined; he resolved to read two pages a day as he steadily worked through all his textbooks.
You might have heard of the Ten Book Rule. The idea is that if you read 3 books then you know more than 90% of people. Read 10 and you are an expert. The numbers are not important – what’s important is the notion that if you put in the effort to learn (or often re-learn), then you will be more expert than others.
What’s your Google Scholar Alert keyword?
Did you know that you can get Google to send you an email each time a new publication comes out that includes a keyword (or phrase) you choose? Mine is “engineering cognition”. This is because of my field. However, you could choose anything you like. Either for your current role or maybe even one you want to gain.
It might take a bit of tuning – I was getting bombarded with emails with some of my early keywords – but, eventually, you will get regular email updates with the latest in your area of interest. Read them or get an AI summary, and you will be blitzing your competitors with the extra knowledge you have.
Is this a shock to you?
 You would not be the first engineer to have thought that once they finish their degree, they are done with such study.
But that’s good for you.
While the rest take no action, you can move ahead of the pack or even join a new one. If you choose to.

Many engineers do not realise how much they have been limited, both skill-wise and success-wise, by their professional experience. They have just accepted it for what it is, along with its effects upon themselves, and not thought to correct for any limiting issues – they are thus trapped and don’t even know it.
Let’s talk about how you can tell if you are trapped and how to break free.
First off, I should note that my experience, especially in the early stages, was pretty good. So I should state that this is not a case of me living something out myself and then saying, “and you can too!” However, I still learned that my experience was not perfect, and I did need “escape” in a way.
So what are some signs you are trapped?

• You feel you do good work, but people still seem to have issues with what you do.
• You have a fixed notion of how administration should be run – maybe you think there should be none – regardless of the size of the company or the nature of the engineering work being done.
• You feel you need to always defend your work or remind people of what you have done.
• You are afraid to share any idea until you have it fully evolved.
• You work on your own tasks without engaging others working on peripheral or related roles.
• You follow a few guiding principles doggedly and don’t trust anyone suggesting deviation from them.
• When you are presented with an idea that is different, and seems odd, your emotional response overrides your engineering mind, and you dismiss or criticise instead of analysing.
• You expect there to be a prescribed process to solve each problem encountered.
• You like the idea of the engineering department being separate from all others so you can do as you wish.

It might be hard to see the common theme in the above idiosyncrasies, but the root cause is working in an organisation that did not encourage good engineering practice that is aligned with the company size and business model. In such situations, the following can happen:

• An influential mentor will instil in other engineers what has worked for them but is not universal. This one is one of the most common.
• The administration system is not designed or updated for the organisational needs. So it never supports the engineering team by helping to track or guide progress and documenting successes. And it is therefore always a burden for all engineers.
• There is no established culture of suitable exploration. And engineers are either criticised for thinking of something different or expected to implement set processes and solutions.
• There is no system, formal or informal, that encourages the engineering team members to engage each other or people from other teams.

An engineer working in this kind of environment will not develop the engineering attributes that allow them to grow into a professional engineer. Instead, they will simply survive the environment – and become reactive engineers just trying to get by from day to day. This becomes habit, and the engineer is then trapped in this mindset.
How to escape this trap.
The good news is that you do exactly the same thing as any other engineer who wants to improve. You need to focus on applying the attributes of the expert engineer regularly. I cover these attributes in detail in my book, but the key points are:

• You work on framing and reframing problems that are given to you.
• You think systemically when solving challenges.
• You apply first principles to assess ideas and inform your decisions.

As you continue to develop these attributes, you will break off the shackles of your prior work experience. You will then be free – and no longer trapped.
Once you are free, you will then be able to consider other aspects of your engineering ability. Things like your cultural, national and economic background. Then you are working toward being a global engineer.
And if the company you work for does not support this, then it’s time to leave. And you know what kind of company you do want to work for – so you won’t leave one trap just for another.

The following is mostly for those who hire, but it also provides some great insights for those wanting to assess a potential company.
Do you expect new employees to fit in or do you “adopt” them into your company? And by adopt, I mean you go out of your way to help them become part of the company in all aspects.
Until now you might not have thought much about this expectation, and just followed some process in place.
Hopefully though, you have realised that, to get the most out of a new engineering team member, you should do your utmost to help new employees understand the new culture so that they can quickly navigate it, feel welcome, and be productive.
But if you have not, then let’s talk more about it now.
First off, while it might seem obvious now why you should put the effort into adopting any new engineer into your team, within the global engineering context it is even more important.
This is because, while your new employee will have excellent core skills, they still need to understand the nuances of the new company they find themselves in. Otherwise, they are more likely to work in a non-aligned manner, spend excess time understanding simple things instead of working, and not be able to share ideas on how to make things better (because they don’t know enough to spot the flaws). That means you are wasting a valuable resource.
Adoption in this sense is more than things like knowing where the coffee machine is, the company culture regarding start and finish times or working from home, or meeting everyone on the floor. Although these things are important.
It involves things like:

• How is an idea to improve things put forward?
• How are decisions made within the company culture?
• How do we track engineering decisions for future reference?
• How does one approach those in other departments when their input is needed?
• How are people assigned to tasks?
• Where do engineering tasks usually come from?
• How are tasks tracked and established as completed?
• What are the fundamentals of the major technology (or technologies) at this company?
• If something is not going well, then how is it communicated to someone?
• How does the company promote people (if at all)?
• What are the priorities of engineering work: speed of execution; conformance with standards; engagement with others; rigorous documentation; validation before implementation; etc.?
• Is there a desire for cultural change or are things well established and aligned with corporate needs as they are now?

This list could go on.
The theme above that you are potentially picking up is that these are related to the more subtle aspects of how engineering is done – subtle even though the implications are significant.
What you might also be thinking now is that you are not quite sure if you could explain these things to someone. They are potentially things that have become so obvious to you that you can’t see them as unique to your company, or industry, or country.
But in the global engineering context, these things cannot be assumed. And if a new person gets them wrong, then their ability to perform can be severely limited.
If you have a role in welcoming new people to a company, then think now about how comprehensive your induction system is. Does it cover the items mentioned above? Do you even have one?
In my case, I have come up with a checklist of all the things I think are important for an engineer to be a productive member of my team – even things that some might think should be obvious. I then assign induction buddies (people from the team) to go over that list with them to ensure they understand each and how that relates to their work. The induction buddy also becomes a person the adoptee can go back to if anything remains unclear.
If you are applying for a role in a new company, then a good question is: how does your induction process work?  I often add something about understanding the respective technology and the company’s engineering processes – but you should add what you think suits given the nature of the role. The answer can tell you a lot about how well a company will adopt you. Usually, you can sense the surprise because they have never thought about this, or they have a well-defined system in place that they can describe in detail.
 
 

Recently, I have been involved in numerous aspects of the engineering hiring process. I have noticed some phenomena and some changes that would be of value to the global engineer. So, in this issue, I am going to share with you what I have learned from my experience in hopes it helps you progress your career more.
Applicant Tracking System (ATS) really do mean there is a vital part of your resume
When I reviewed the resumes of applicants through the ATS (a program designed to make the hiring process easier) for a role I was wishing to fill, I noticed that each time I clicked on the applicant’s link, the ATS showed a preview of the top 1/3 of the first page of the resume. The end result was that I automatically used this to do an initial screening. Therefore, you should ensure that this part of your resume has a summary of your skills and what you have to offer. If a resume had a summary in this section and that summary aligned with what I was looking for, then I was more likely to pass it to the next stage.
Portfolios are great for engineering roles
 Portfolios are usually for roles like industrial design, graphic design, fashion design and other roles where you can assess the skill of the applicant by what they share.
However, in the engineering context, a section that was dedicated to the various achievements that the applicant was most proud of helped phenomenally. An image was good, if confidentiality allowed, but otherwise a descriptive heading so the hiring manager could grasp the nature of the challenge was a great start. Then a description of the nuances and how the challenge was completed.
I didn’t care how much longer it made the resume; this was excellent insight to assess an applicant.
Photos are good in the right context
I recall one applicant who had a photo of himself on the front page of the resume. He just looked like a design engineer. The rest of the team agreed that after seeing his photo, they could easily imagine him sitting in the same department next to the others in the team.
I suspect the photo was taken by a professional who asked him the role and industry he was interested in, then took care of the rest. He had the right clothes, worn the right way and he had an expression that conveyed that mix of creativity and practicality with a strong dose of cooperation that you want in all members of an engineering design team.
There is no substitution for proper assessment of skills in the interview
Many hiring managers still seem to think that they can come up with the ideal questions to assess skill. In my experience, they can’t. I think half the reason is that they don’t actually think about the skills they really need, and instead focus on specific domain knowledge.
I have found that the best way to assess an applicant is by giving them:

• some pencil and paper,
• a relevant challenge described on another sheet of paper, and
•  an hour or more to explore and solve (if possible) that challenge.

You get to see their knowledge, the way they think, the way they formulate new questions for better understanding, how well they communicate with words and pictures, and their comfort with this type of work.
It would be best if you get challenged like this in an interview, but, the fact is, you will likely need to show domain knowledge for the respective role. And it’s hard to say which aspect the interviewer will latch on to – sometimes they ask you about a specific challenge they had the prior week which is not even indicative of their usual work.
AI was a huge help
I used AI in a number of ways:

1. I used it to screen the resumes and rank them based on the attributes I wanted. The great thing about this, is that it read the entire resume looking for evidence of the attributes I was after. Thus, it would find things I would miss – making it fairer on the applicants. Because it also explained why it ranked each applicant the way it did, I was able to refine the prompt if needed and I felt very confident in the findings. This is ideal when you have 100s of applicants – especially if they have extra sections like portfolios in their resumes.
2. Once we had culled the applicants down to about 30, the HR support team was then able to call those 30 for a prelim interview. Because they dictated the answers – likely using AI – we have complete text of their responses. By ensuring the questions asked were aligned with the attributes we were after (things like what’s your favourite engineering design tool or philosophy and why) each answer revealed a lot about their experience and practice. Again, these answers could be put into AI for quick assessment.
3. Developing questions. AI provided great feedback to the questions and assessments I had conceived. It helped me refine them to ensure that there was a minimised chance of misunderstanding and that they indeed assessed for the desired attributes. It therefore helped remove unconscious bias.

I can see it only doing more in the future.
Summary of key points for the global engineer

1. Make sure you have a clear expression of yourself and what you offer in the top third of the first page of your resume.
2. If you are going to do a photo, then consult a professional photographer who understands the goal and purpose of the photo.
3. Consider adding a portfolio (or any other supporting sections). This helps an interested engineering hiring manager learn more about you once they show interest in your application. It also works well with AI systems that can digest a lot of information.
4. Soon AI will become more common, and I can see it making things fairer, but until then, you do need to be ready for idiosyncratic domain-specific questions from employers.

In the past two articles I have compared communism and capitalism asking which is best for engineers. This was to explore the explicit question and also using the process to provide insights into to how different economic systems could influence engineering practice, skills and habits.

The two articles showed pros to each system for engineers: there was no clear winner. One can find not only examples of engineering excellence from each, but cases from each where engineering had suffered.

So what does this mean?

It means that we asked the wrong question. We implicitly asked which was better: communism or capitalism. And OR questions are always dubious. As I mentioned in my book, once you ask an OR question you need to compromise. You should therefore ask an AND version of the question or perhaps a different question altogether.

So we should have asked: how do we get the best engineering outcomes of both communism and capitalism in one system?

Or, the question in the title: what is the best economic system for engineers?

If you have read my book on how to master the core skills of engineering expertise, then you can likely guess the answer already.

Our man Joseph Schumpeter.

Joseph Schumpeter was an influential economist who argued that all improvements in societal wealth and the standard of living of the average person come from innovation and its commercialisation. Society needs ongoing innovation and its implementation so that we have Creative Destruction – where the old is replaced with the new (and better) so that things improve for everyone.

Schumpeter did not care if this came from an entrepreneur (although he thought that spirit was essential) or a large corporation or government-funded institutions (although for the latter two he noted the benefits in having organisations that could fund R&D). What mattered is that the innovation was implemented.

As an engineer, when you stop and think about this, it makes sense: all improvements in quality of life and the wealth of modern society can be tracked back to some form of technological innovation. Also, it leaves you feeling a little taller and content with yourself. For it is engineers who are so instrumental in this act of commercialising and implementing innovation. You realise not only how the right kind of economy can offer more engineering opportunities, but how more engineering activity means a better economy.

So the best economic system for engineers is a Schumpeterian one. And this also means engineers are essential for a healthy and growing economy.

So now that we understand what is best, economically, for engineers, what do you do with this as a global engineer?

Whenever you are considering a move to a new role, assess the culture (be it the company or the location the company operates in). Is it one that values innovation and entrepreneurship; does it expect engineers to be a driver of improvement? If the answers are yes and yes, then you are more likely to be in a role that will be satisfying and offer you a chance for professional development.

And if you are looking to employ an engineer, then such places are more likely to produce expert engineers who will be of greater value to you. Just make sure that the place in question valued both innovation AND its implementation. The former without the latter is just academic.
​
So think now about how Schumpeterian your past places of employment have been. Have you been well served, or is it maybe it is time for you to change so you can develop further?

You have likely heard the phrase “Greed is good”. It is from the movie Wall Street.
The full quote is actually “The point is, ladies and gentlemen, that greed -- for lack of a better word -- is good. Greed is right. Greed works. Greed clarifies, cuts through, and captures the essence of the evolutionary spirit. Greed, in all of its forms -- greed for life, for money, for love, knowledge -- has marked the upward surge of mankind.”
The point of the movie producer was to show the destructive attitude within the corporate world. Others have suggested that the quote is aligned with theories on how the free market (through things like Adam Smith’s invisible hand) and how it makes society better.
I was struck when I found that the quote includes the phrase “for lack of a better word”. It opens up the opportunity for the reader to insert their own nuance – and take what they want from the quote. Especially when linked to life, love and knowledge.
For this article, “greed” is going to mean a desire to make the most of what is available. And we will talk about how a capitalistic system based on this greed could be good for engineers.
If capitalism were to be good for engineers, then how would it be so?
Capitalism should allow for anyone with a good idea (and the sense of greed to make the most of it) to start a venture based on that idea. Therefore, capitalism should mean that there are many places for an engineer to work – offering a chance to find exactly the kind of role they want or pursue a change when they want.
This would be measured via the number of startups (ideas being commercialised) and the economic complexity index (indicating the number of different places an engineer could work).
Which countries top these lists?
The three countries with the highest economic complexity index are: Singapore, Switzerland, and Japan. Countries with the largest number of startups (deep tech – because that’s what you and I are interested in) are: the United States, China, and the United Kingdom. Per capita, the countries with the most startups are: Israel, Estonia, and Switzerland. These are countries that one would expect to offer more opportunities for engineers. Certainly, these seem like countries that have engineering activity. And most seem capitalistic. Although China is officially communist – it has been leaning into capitalistic practices in some ways of late.
So capitalism can be good for engineers – offering a diversity of opportunities, and a more satisfying career.
But it is based on the notion of doing what the customer wants, which might not be good for them in the long run, to remain profitable and competitive. And that in turn means looking for every opportunity to squeeze as much out of the resources available so that the customer sees the offering as the best value for money out of all the options on offer.
Therefore, an engineer who has come from a company (or industry or country) that has flourished in a competitive and capitalistic environment, would likely look for more input on what the market (end user, client, customer) wants. This is especially so when working on a larger, less defined, but well-funded project (like those associated with publicly funded research activities and public works). They could tend to create other constraints through goal analysis (where an engineer looks for more opportunities to improve the outcome for the end user) and then satisfy those as well. These efforts, while well-intentioned, are likely to be wasted effort – because there is no competitive advantage to be gained when there is no competition.
So if you are a global engineer moving from a competitive industry to one that is more regulated, then accept that it might very well be that what you initially think is helping the company could be just wasted time. And, if you are employing an engineer from a competitive industry into one that has different drivers, then think about what you can do to help them better understand the changing requirements and where they should now put their efforts. In short, tame that greed!

In this article I am going to write about instances when, thanks to communist governments, engineers were able to achieve remarkable things, enjoy ample employment of opportunities on exciting projects, and contribute to the general pool of engineering knowledge.
The reason for this is to explore how engineering success, at times, can be a result of external factors more than engineering talent. Further, it will help you understand how factors such as politics, economics and national nuances can influence engineering expectations and practices. This will help you in two ways. First, it will help you better understand the inherent tendencies of engineers from other regions who you might work with. Second, it will help you better adapt to new workplaces with different degrees of public ownership and influence.
So let’s start this off by considering some of the engineering-related success from communist places.

• High-Speed Rail Network in China: A network stretching over 45,000 kilometres.
• Moscow Canal in the U.S.S.R.: Linked the Moscow River to the upper Volga River, providing water and turning Moscow into a functional deep-water port.
• Hong Kong–Zhuhai–Macau Bridge: A system of bridges and undersea tunnels spanning 55 kilometres across the Pearl River Delta.
• Shenzhen–Zhongshan Link in China: A 24-kilometer combination of bridges, artificial islands, and underwater tunnels connecting major hubs in the Greater Bay Area.
• Obninsk Nuclear Power Plant in the U.S.S.R.: Launched the world’s first grid-connected nuclear power station in June 1954.
• The FAST Telescope (Five-hundred-meter Aperture Spherical Radio Telescope) in China: The world’s largest single-dish radio telescope, built into a natural basin in Guizhou province.
• Sputnik from the U.S.S.R.: The first artificial satellite.
• JUNO (Jiangmen Underground Neutrino Observatory) in China: A massive underground neutrino detector housed in a giant acrylic sphere submerged in high-purity liquid.
• The Vostok 1 spacecraft from the U.S.S.R.: Took the first person, Yuri Gagarin, into space.
• The EV industry in China: accounts for 75% of the world’s production and was developed after a state directive in 2009 (17 years ago)

The first thing that is clear about this list is that all items are from the U.S.S.R. and China. There would be other examples, but I have, in that list, stuck with those countries that are most obvious as being communist to the average reader.
What strikes me about the above, and maybe you too, is that each item is more impressive when you consider the economics of the broader population. China has a GDP per capita that is about one sixth that of most developed western countries (factoring in purchasing power, it is about one third to one half). In its time, the U.S.S.R. experienced similar relative levels of wealth.
It is hard to imagine how in other countries with similar levels of wealth such projects could succeed.
Therefore, if you were an engineer in such a country, especially if you gained employment in one of these projects, then you would be glad of the government’s actions. And you might think that communism is good for engineers.
So how is communism good for engineers?
Communism essentially has a command economy. Ideas and businesses do not succeed because there is a market that is prepared to pay for them – the demand economy. Instead, it all comes down to the government demanding what will be done. If the government decides that a space program is needed, then a space agency is set up and engineers are put to work making rockets. If the government decides it wants a high-speed rail line from one end of the country to another, then engineers are now laying tracks, building trains and building power infrastructure. There is no need to wait or hope for the fickle market to demand what you can do – it simply happens.
That can be the attraction engineers have to communism at times.
What this means for the global engineer.
If you spent many years working in a command economy, then you might find you need to put effort into remaining mindful of commercial demands and realities if you work in a capitalist economy. And the opposite can be true if you move in the other direction – you might waste your time thinking about commercial realities instead of just getting the project done.
There can also be benefits.
Someone from a communist economy has potentially built a lot of knowledge in a field because it was so well funded that they could keep working in it. Funding that would not be available when a company needs to worry about income, expenses and profits in a capitalist context. Also, someone from a capitalist background could be ideal to ensure that the end users are better considered, for a more useful and beneficial outcome, than would someone who has become accustomed to only worrying about the broader goals laid out by the government – The Tu-144 (the Soviet equivalent of the Concorde), with its reliability issues, high cabin noise, and environmental concerns, comes to mind.
So, is communism good for engineering? It certainly sems it can be at times. A command economy can direct resources toward large technical goals in a way that free markets often would not, and that can give engineers remarkable opportunities. Regardless of what economy you are in though, as a global engineer, consider how that economy could affect:

1. the expertise you can develop (or have developed), and
2. your tendency to factor in broader commercial effects

relative to those working in a different economy. This will help you appreciate your own skills, opportunities to develop further, and make transitions from one region to another much smoother.

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.

This article is another part of the retro-engineering series. Where we take a look at engineering efforts of the past to find insights into the generalities of good engineering practice. This then lets us become better global engineers. This time we will explore the time a group of General Motors (GM) engineers were engaged to develop what many consider to be the first true heart pump.

If you want to read more about this project, then take a look at this article in the New York Times.

In summary though, a team of engineers from GM developed a heart pump that, on July 3, 1952, was used in the first successful surgery where the patient survived while a mechanical heart maintained blood supply. This was a major step forward in open heart surgery.

The first thing that I note about this project was that it was an automotive company that was engaged. I understand that GM was and is a large company with many capabilities, but I would also think that a company that specialises in pumps would be better suited.

So why was GM the company of choice for this project?

It was because, in 1949, Charles E. Wilson, a GM president, was also the chairman of the newly formed Michigan Heart Association. And this was because Wilson had a major interest in heart disease. If he did not have such an interest, then he would not have been a member of the association and unlikely to have been approached. Who knows who would have then been engaged or if the project would have even progressed at all.

The lesson here for the global engineer, have other interests and network so that you can be a part of more opportunities.

So that explains the first step – finding out about the project and being invited to join – but what about the decision to actually get involved, and take on such a challenge?

This is an example of understanding the transferable nature of engineering fundamentals.

“We have pumped oil, gasoline, water and other fluids one way or another in our business,” wrote Edward V. Rippingille Sr., the leader of the team of engineers and researchers who developed the heart pump. He wrote further, “It seems only logical we should try to pump blood.”

There are indeed differences to how blood and Newtonian fluids behave, but, at the same time, lessons from pumping the latter can be applied to pumping the former. Rippingille showed the ideal global engineering perspective that one should not assume a new field is completely foreign and off limits to them. Instead, it was realised that there are fundamental commonalities, and that these can be used when moving from one field to a new one.

But still, it was different, and those involved were wise enough to understand this. The General Motors Research team started by reviewing almost everything that had been written anywhere on the subject. Further, Rippingille travelled extensively, examining various pumps that had already been made for such use but had failed for one reason or another. This shows an at least implicit understanding of the importance of systemic thinking and first principles. By studying the prior art, an engineer can quickly acquire the respective domain knowledge needed for systemic thinking and use of first principles. And that’s what would have been achieved by reading prior art and looking at what others had done.

But even then, with all that research done prior, it was not a linear product development process.

Over a period of 30 months, 6 to 10 concepts were built and tried – and 84 dogs were lost through testing. For this project to work there was funding from The Michigan Heart Association and GM had provided support as a public service. This commitment and support did not seem to waver after the first prototype. Thus, there was an implicit understanding of the need to implement solutions to better understand the challenge – many call this iteration, but, in contexts like this where the challenge is new, the global engineer knows it to be co-evolution. And initial failures are not just one more step to success, they are an essential part of defining both the challenge and the solution.

Despite the example of engineering expertise noted above, there was some hint of cognitive laziness or automatic association.

Sometime later, Dr. John W. Kirklin from the Mayo Clinic, who was conducting research into heart-lung machines, reviewed The Michigan Heart Pump and one that had been developed by IBM. He noted the former looked like a car engine and the latter looked like a large computer. This led to some thinking the engineers actually miniaturised a V12 for the job. In reality, this was more likely a case of fixation – where a designer has ideas in their head that they do not realise they have and that they and can’t shake. These are not always bad – and in this instance it might have allowed the engineers to focus more of their engineering efforts on the real challenge – moving blood.
​
In summary, the case of The Michigan Heart Pump is an excellent example of global engineering expertise: engineers networked, found new opportunities, understood the fundamentals, leveraged existing knowledge, understood what it really takes to tackle such a challenge, and let their fixation from prior experience reduce the cognitive effort. It is something that you and I can use as a reference for engineering best practice.

Do you ever give thought to who was the smartest person ever? Or, compare one supposed historical genius with another? I am more inclined to compare them. The notion of intelligence and smarts has proven to be too difficult to quantify in this context to work out who the smartest is. A comparison though, I have found, reveals more about the way we choose to think and what we choose to learn so that we can be better at what we do.

So, in this article, I am going to compare two people history has decided are geniuses for two rather different reasons: Sir Isaac Newton and Leonardo da Vinci.

One of the things I find most remarkable about Newton is the story of how he solved for the Brachistochrone curve. This is because I am quite fascinated by the related isochronous curves and because of how quickly Newton found the solution compared to others at the time. It was a challenge set by Johann Bernoulli in a scientific journal for all those who read it. It seems that Newton did not read it because Bernoulli sent him a letter directly. While another requested one and a half years to find the solution, Newton found it on the night he read the letter (after getting home from work at The Royal Mint).

What strikes me about da Vinci is how he used the scientific method to find knowledge to help him with things as diverse as inventing machines for specific tasks and his painting. He got his hands dirty – literally. He would dissect people so he could then understand their form – allowing for better paintings. He also paid detailed attention to what he saw – using his studies of light to revolutionise the use of shadows to enhance the 3D effect in paintings. He never learned mathematics or Latin and never pursued any formal advanced studies. He was not part of the contemporary scientific community. But with the knowledge he gained, he evolved insights for ideas on mechanisms and inventions such as a strut bridge, an automated bobbin winder, a rolling mill, a tensile strength tester of wire and a lens-grinding machine.

While Newton invented the reflecting telescope, it is hard to imagine him making such advances in art or contemplating numerous types of mechanisms and inventions like da Vinci did. While da Vinci showed considerable scientific expertise, it is hard to imagine him deriving formulae for natural phenomena.
It is indeed as if each of them had powerful brains made for different things, and one could not expect one to also be good at what the other did.

But is this true?

If we go back in time further again, then we can consider Archimedes. He was definitely inventive. Think of things like: the Archimedes' screw, the compound pulley, a crane used to lift and drop attacking Roman ships, an odometer. He also came very close to inventing calculus without algebra and only geometry – making him all the more impressive.

Could Newton have achieved even more if he got his hands dirty? He did put on disguises to bust counterfeiters so he was the type to get visceral if needed – if only he put that ability to something scientific or technical.

What would da Vinci have achieved if he could have applied mathematics to his inventions for faster optimisation and assessment? He certainly had the mental capacity to learn and master mathematics – imagine if he could have used mathematics to find the most viable invention ideas to progress further.

Or, would they each have lost what made them unique and impressive?

We will never know, and each can, regardless, be very content with what they did achieve.

But it is hard to imagine any harm in them broadening their skills to augment those they already have.
​
And that’s the lesson for you as a global engineer. As you move from one role to another, think about the new skills you might need – and then develop them. Even now, think about skills that could help you just a little or might help in the future – and then develop them.

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. 

If you have been paying attention, then you have heard about the USD 12 Billion that Jeff Bezos and Vik Bajaj raised to develop an AI general engineer. One that can do what any other engineer can do – so it should be much like a global engineer. Read more here if you are not aware.
If possible, then what would that mean for professional engineers like us?
Bezos thinks this will help augment engineers and give them more time. Others think that all engineers will eventually be replaced. And what has been achieved thus far is not yet in the public domain.
In this article, I am not going to talk specifically about what Prometheus will or will not be able to do. Instead, I am going to use this as an opportunity to talk about the following:

1. What would be needed to train such an AI system?
2. What that means for the nature of such an AI system?
3. What would that mean for engineers working with such an AI system?
4. Should we even expect such an AI system to think the same way as human engineers?

I am not going to assume that I will know exactly what is being done on Project Prometheus. Nor that I will have the exact answers, but this conversation will help you and me think more about what’s needed to make an AI engineer and what it is to be an engineer in general.
What would be needed to train an AI engineer?
In my book on being a global engineer I noted what has been found about the way the best engineers think. In summary, they do 3 things really well:

1. They frame problems in a way that makes them easier to solve. They do not accept the problem as is. They look at it from different angles to find another way to define it – and then find an angle that makes the solution obvious and easier to implement.
2. They think systemically. They do not focus on just the challenge in front of them. They look at all peripheral elements for both challenges in accomplishing their goal and opportunities to help achieve those goals.
3. They use first principles. They do not make arbitrary decisions about the values of key parameters. They calculate the optimum value based on theory. They also use theory to understand the nature of any challenge they face.

Would an AI engineer explicitly be trained on these three attributes?
If so, then would we explicitly state these as needs or would we train the system to engage in these actions by default?
Not only that, but would we consider other, very human aspect of engineers?
One example is fixation. Where someone, in this case an engineer, stays focused on an idea that has come to them. It might be because it is the first one that showed promise, something they are excited about, or something that seems obvious because they have been working in a certain field for so long.
Fixation can, at first, seem like a bad thing. However, it has also been found to provide drive – and engineers have developed remarkable innovations by overcoming the challenges caused by this fixation. Sometimes better than what would be expected by someone objective who could see that fixation taking effect.
Would we want the AI engineer to show this tendency toward fixation to explore ideas fully?
Which brings us to another attribute: co-evolution
Many engineers talk about the need to iterate a design. I agree with the need, but I do not think the word “iterate” explains the depth of what is going on. The word “co-evolution”, I think, elicits the true deeper meaning of what is happening. As a solution is implemented in some sort of trial, new information is generated about the problem. So as we generate the solution, we better understand the problem. The solution and the problem evolve together.
As we co-evolve both the solution and the problem, we expand our understanding of the solution and problem space. It is like exploring a new land – but one where the terrain is the challenge we are solving. Some solutions find a path through rocky terrain that opens new areas to explore that we never knew about.
Do we need to find a way to train an AI engineer to explore like this?
If so, then is it all through simulation or do we need to run the physical tests under its instructions and then report back (expecting questions about how well we ran the tests)?
What does this mean for the nature of such an AI system?
Considering the above, do you feel that there is data enough to train an AI system to be a general engineer?
Personally, while I do think AI engineers will eventually be a thing – and eventually be better than us, I am not sure it will happen as a result of ingesting large amounts of data.
I think there will at least need to be some kind of reinforcement learning. Where the AI will adjust through trial and error to provide better outcomes.
That means the system will need some kind of objective measure of success. It will need to be able to assess how well an idea has performed. Maybe based on a numerical goal. Maybe on some other system that is more “reflective” so it can ponder how it could have done better – comparing what it actually did with other things it could have done.
This is something that many engineers do. You have possibly thought back to things you did years ago and thought “now why didn’t I do it like this?” I know I have done that.
So the AI engineer would need to have some kind of inner monologue. Is that possible?
Maybe it will actually need to be a team of AI engineers – each with different parameters from their own training – interacting with each other. Comparing the performance of each other’s ideas and then adjusting their own parameters to think in a better way.
So it might be that we never have a single AI engineer in the true sense, but a collection of AI engineers working together and then presenting output as if it is from a single AI engineer.
This considers the “cognitive” aspects. But what about the physical or real-world execution?

• Will the AI engineer call up suppliers to confirm current capabilities and use that as an input?
• Will it have hyper-generalised transducer (maybe a humanoid robot) that allows it to build and run prototype tests?
• It will likely be able to connect to rapid prototype machines, but will humans (with their nimble hands) still be the ones putting the parts together and finding (with their comprehensive senses) the ideal place to run the assembled product?
• What is the most economic execution of the above actions at this time, and what does that mean the AI engineer should be like?

The above does seem to point to the notion put forward by Bezos that the generalised AI engineer will be working with other engineers to increase productivity and free up the time for humans. For now, at least.
What does this mean for engineers?
If you do ever find yourself working with a general AI engineer, then it would seem likely that you will be using it to do the things that would normally be time consuming for you. Explore numerous ideas, source the appropriate first principles, conduct simulations and calculations, generate test plans, come up with questions to better refine the problem statement.
You could then share your own ideas to help move things along.
At first that seems like you get to enjoy the fun parts more. And have more free time.
 
However, in the continued pursuit of profits, I am sure there would eventually be fewer engineers working for the same amount of time. History just shows that’s how things go.
But how will you interact with the AI engineer?
Again, in my book on being a global engineer I covered how words are not enough to explain engineering concepts. How engineering is very much a visual thing – even though other senses can help better understand any challenge you are facing. How do you convey what’s in your mind’s eye to the AI engineer?
Engineers are either going to have to improve their CAD skills to quickly convey their ideas or work on their ability to sketch. You might be able to use words to ask for an initial concept, but sooner or later you will need to edit some sort of visual to convey what’s in your mind.
But will the AI engineer visualise the way we do?
Should we even expect such an AI system to think the same way as human engineers?
We have developed our engineering skills by working with the brain that biological evolution gave us. This does not mean it is the only way invention can come about.
There are numerous examples in nature of animals showing the action of invention. Sometimes it is thought to be a result of instinct from evolution and sometimes from actual intent. But, as we learn more, the definition of intelligence and creativity seems to broaden.
Such ideas have also been explored in literature.
In the Children of Time series, Adrian Tchaicovsky explores how creatures with multiple brains or limited memory capacity could evolve inventiveness. In some, there is a separate brain that takes the problem as given by the main brain and then returns a solution some time after processing. Others have an ability to install and uninstall knowledge so they can use what is needed for the respective task.
In the West of Eden series, Harry Harrisson explores the nature of intelligence and inventiveness of an evolved reptilian brain. Where all technological advancement is an iteration on previous efforts with no major leaps – keeping them away from metal working and machinery, but phenomenal selective breeding.
Given the diversity of thought that we have found in nature and what we can conceive when we put the effort in, we can expect the possibility of a general AI engineer that thinks very differently from how we do while still generating excellent solutions.
Will we be able to work with such an engineer? Will we automatically think it inferior? Will we try emulating it ourselves after it reveals new ways of thinking to solve engineering problems?
In this article, I have only covered the major and some select aspects of engineering cognition. I have also only covered a select number of engineering activities associated with the full implementation of any engineering solution. I have also only alluded to the importance of engineering teams. And the diverse nature of the potential forms of intelligence was given only a cursory coverage. To deal with them properly would require an entire book.
That means there is much more to explore and consider. I currently can’t make any solid predictions about how this will all end up.
However, I do now feel convinced that the effort to make this general AI engineer will reveal much more about what it is to be an engineer. Even if it fails. So I plan on following it in detail, and I think you should too.
As you think about it now, what challenges and opportunities do you see? What would you want a general AI engineer to be like?
Share your thoughts – this is a conversation I would like to extend so we can all learn more about what it is to be an engineer.

Here is a scenario you have likely been involved with if you have had even a short amount of engineering experience.
Someone in a meeting suggests something that is unorthodox. Others dismiss it – maybe even derisively. But the one who put it forward continues to think it is a perfectly good, and logical, idea to pursue further. Neither side agrees with the other nor even understands the other.
How can engineers, who should be using sound and rational reasoning to assess all ideas, disagree like this? Surely, they should be able to explain their point in sufficient detail to ensure clarity – and not degrade into unfounded disagreement that seems more like personal preference.
The reason for this is that at least one party (probably all) is relying on their instinctive response and they don’t actually understand that response.
If you take a moment now, then you can probably recall a time when someone presented you with an idea to which your initial response was just discomfort. You did not know exactly why you felt uneasy with the idea. You might have even acknowledged that their explanation as to why it was a good idea made sense. But still, you simply did not like it.
This was your instinct.
It might have been right. But if you can’t explain it, then you will not have agreement. And just so you know, engineers can’t say things like “It just doesn't feel right to me” and expect that to be argument enough.
For a global engineer, this can be more extreme. If your instincts are based on experience in one context, then those instincts could be perfectly correct for that same context. But in another context, which is more likely to be experienced by a global engineer, the likelihood of it being corrects is much less.
You therefore need to dig deeper into your feelings, and turn them into sound logic.
Such feelings come from your unconscious, which holds numerous memories. One of these memories was triggered by the idea put to you. Something you experienced in some way suggests this idea would not work.
So your job is to delve deeper into your mind and find what it is that generates this feeling.
This is much easier said than done. You will likely need to sleep on it before you realise what caused this feeling. However, as you continue to put effort into accepting the feeling for what it is and then trying to extract what caused the feeling, you will get better at this. Eventually, you will find that you can extract this information in moments and with little effort – because you have created the mental paths that allow for easy flow.
The other side of this same story is when you come up with an idea, but others just don’t get it. And you don’t know how to explain it well enough – because it is instinct, and not clear thought.
This time, the idea came from the same place as did your unease with other people’s ideas. And without those mental pathways, you just can’t get the important knowledge out to create the argument you need to explain what you are thinking.
Once again, you need to work at it – until it eventually becomes something that happens in the moment.
Once you do this, you will:

1. Better explain your ideas – releasing the genius within.
2. Only critique ideas that have real issues so that good ideas are not dismissed – controlling the idiot within.

So next time you have that instinctive feeling, dig into it. And reveal the genius you have within or foolishness you need to excise. 

This is the first engineering product review article I have done for this series. It’s a bit like the retro engineering articles, where we look at a previous engineering system to find examples of engineering expertise, but this time we take a look at a current product.
In this article it is the Henson Razor.
Summary of the Henson Razor
The Henson razor is designed around the precision mounting of a standard flexible blade. Further, the head is designed to create an intuitive alignment to guide the user. By mounting the blade precisely and guiding the user with alignment, the razor will shave the hair away without excessively scraping the skin.
I have used this razor myself, after being impressed by their explanations of the design and demonstrations, and agree with others who have reviewed it highly – it is an excellent razor.
So how did they create such a razor?
When you read over their website and watch their videos, you see numerous examples of great engineering practice.
Outcome-Driven Innovation
They definitely showed a Jobs To Be Done perspective and started with the user. They were able to pick their design goals:

• Minimise cuts on the skin
• Minimise the length of hair left after a pass of the razor
• Minimise waste and cost – not like plastic razors
• Minimise build-up of lather and hair to minimise the need to clean the razor while shaving

First principles
To minimise cuts and minimise the length of hair left after a pass of the razor, the designers knew that a well-controlled blade gap (the space between the blade edge and the leading surface of the head) and well-controlled blade exposure (how much the blade protrudes from the surface of the head that contacts the face) were essential. Not just nominally, but along the length of the blade.
Good control of location of the blade means precise manufacturing methods like machining.
Further, a bent blade is more rigid than a flat one. Therefore, if the blade is bent, then it will have more inherent rigidity.
In addition, a 30° cutting angle has been found to be the most comfortable for use.
Skin is more compliant than metal so it can be expected that the skin being shaved can align, at least to some extent, with the shaver surface.
Framing
In this instance, the framing became apparent given the above: design well-controlled machined parts that securely connect, and control the blade location so that it is bent to 30° at the cutting edge.
This does not make for a stereotypically ideal product – it is not well aligned with mass production methods for low cost – but it is well aligned with reality. Both commercial (what users want) and physical (how razors perform).
Systemic thinking
The designers noted that standard razor blades are ubiquitous and well controlled in their dimensions. Thus, there is an opportunity to leverage these in the design and there is no need to design or produce the actual cutting edge.
The head of the razor was designed to mount the blade as well as let the hair and lather flow through – achieving two goals with the one part.
Goal analysis
The above shows the core attributes of the expert engineer (first principles, framing and systemic thinking) at play. However, as the product (including the commercial aspects) was developed, other opportunities presented:

1. There was the chance to augment the prestige of the product by noting it is made to the same standards as aeronautical parts.
2. Anodization allows for a range of colours, which suits a market that likes customisation.
3. While the razor is expensive, it will last longer and uses cheaper blades so the lower long-term cost is now a feature.
4. This also allows for the eco-friendly nature of the product to be a feature as well – less waste (especially plastic).

Things to note
While I would argue that the Outcome-Driven Innovation was the start of the journey here (even if the engineers themselves do not know this term), I would not argue that the first principles, framing, and systemic thinking occurred in the order I covered them. It is more likely that these actions coalesced – along with the goal analysis.
Because the process started with the needs of the user, it became very easy to sell the product based on its features. This is a lesson for all engineers. If you are clear on what needs to be done, then it is very easy to explain the benefits of your proposed solution.
I have covered this product because I think it is a great piece of engineering. I have no links to the company – apart from being a customer – and I received no income for writing this article. I would recommend the product, but I would first recommend that you take a look at their website yourself to see how they developed this razor.

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.

Many engineers hope that they will come up with an invention that will be the foundation of a successful business. A business that will lead to wealth and their own legacy. However, this does not happen that often. And I know engineers who have tried taking this path, but failed, despite their excellent engineering ability.
What went wrong for them?
They had a good idea. A clever idea. One that only few could come up with. But it was not something that was needed – it was not the foundation of a business.
In this article, I am going to explain the difference between a clever idea and something that is a worthy invention. And from that, the mindset you need to ensure any idea you pursue will have a much greater chance of success.
The first problem is that people can get caught up in their invention. They like it, and they assume (or hope) that others will like it too. All they need to do is explain it to everyone – then everyone will want it.
But that’s not how it works. No matter how clever the idea is, others will not care about it unless it makes their life easier.
So the question is not:
Is this a good idea?
The question to ask is:
Who and how does this help?
And then, even more importantly:
How much does it help them?
If you can’t provide a solid answer to the last two questions, then your invention is just a clever idea – not something that will be the foundation of a business.
Don’t start with the clever idea. Don’t think that if you just keep on thinking, you will eventually come up with a great idea for an invention that everyone will want.
Instead, start watching the world around you and asking:

• What are people struggling with?
• What do people keep complaining about?
• What takes too long?
• What costs too much?
• What needs too many people?
• Where are resources wasted?
• What breaks too often?
• What is done badly because everyone has simply accepted that this is the way it is done?
• What makes people worry?

With this focus, you will have a genuine issue that you can focus on.
If you have read my earlier articles, then you will note how this is similar to outcome driven innovation, as developed by Anthony Ulwick. You don’t start by asking what product you can invent. You start by understanding what people are trying to get done. Then you understand where they are struggling to get it done.
That is much more powerful.
Because then the invention has a job.
It is not just a clever thing looking for somewhere to belong.
Have you ever seen the movie Robots? It’s a good movie so check it out when you get the chance. There is a successful inventor character called Bigweld who has the phrase:
See a need, fill a need.
That saying practically summarises this whole article in one sentence.
This mindset also changes how you should think about patents. Another trap for the engineering looking to invent.
A patent can be very useful. I am not dismissing them. If you have something valuable, and someone else could copy it, then protecting it can matter.
But a patent does not create value.
And it is not evidence that you have a good idea.
I know people who have made this mistake. They had an idea. They thought it was a clever idea. They took it to an investor. The investor said that they would not consider it unless it has a patent.
So they got a patent. They spent money. A lot of money.
And then it all failed – the investor was not interested once they heard about it.
Because it did not solve a problem.
If someone asks you for a patent first, then do not consider them a suitable investor. Instead look for someone who asks:

• What problem does this solve?
• Who has this problem?
• How often do they have it?
• What does it cost them?
• What are they doing now to deal with it?
• Why is the current approach not good enough?

And then asks:

• How does your invention make that better?
• Does it save time?
• Does it save money?
• Does it save resources?
• Does it reduce risk?
• Does it remove effort?
• Does it make something easier?

That last one is probably the simplest way to think about it. Most inventions that matter make something easier in some way. Not always easier for everyone. But easier for someone who cares enough.
And that is where a business can start.
There is another useful point here. If you really do have a good idea, you should be able to get interest from people who fund ideas.
I have heard this from multiple people on the financing side of inventions. If the value is really there, funding can be found. If the idea clearly solves a valuable problem, then people with money will be interested.
Investors will not always be right, but they see a lot of ideas. They see a lot of people who are convinced they have something. They are trained, or at least experienced, in looking past the excitement and asking whether there is a commercial reason for the thing to exist.
That means their response can tell you something.
If a professional investor can quickly understand the value, that is a good sign.
If several of them cannot, that is also a sign. Either this is not going to succeed, or you have not explained how your invention saves people time, money, resources, etc.
And you need to be open to either possibility.
Do you need to refine your presentation, or, do you need to move on to another idea?
This is difficult because your invention can become personal. You have spent time on it. You have thought deeply about it. You might have imagined the business it will spawn. You might have imagined the success. You might have imagined the legacy. And you think nothing need change – the path to success is clear and obvious.
But it’s not going to be like that.
So you need to change something. Maybe the way you explain it. Maybe the whole idea.
Either way, be like Bigweld – looking for problems first -– see a need fill a need.

While it is important for an engineer to utilise all sensory options to fully understand any challenge, the ability to visualise remains the most vital skill.
So in this article, I am going to talk about a way you can improve this.
It might seem a bit hippy, but it works.
Pretty much everything you do can be improved with dedicated training. From something physical like running to something incorporeal like having compassion for all others. So it would be the same for your ability to visualise.
There is a practice that requires, probably more than anything, excellent visualisation skills.
And that’s meditation.
In some parts of the world, this is considered a daily activity. In others it is thought to be similar to prayer. In much of the West, it is associated with hippies and alternative life styles.
Regardless of how you view it, I am, in this article, going to view it as a cognitive process – and then take from it aspects that are useful for visualisation, and thus engineering.
Because I was raised in an area that had a community with a significant element of people pursuing an alternative lifestyle, I was introduced to meditation and its various tools in my teens.
Later in life, I found that the visualisation skill this developed in me, was perfect for many engineering tasks.
And what follows is the primary technique used to develop this skill. Try it daily if you feel your ability to visualise could be improved.

1. Find a quiet place you can sit or lie down for a period without being disturbed.
2. Relax. If you have a technique you use for this, then use that. Otherwise, Try this:
   1. Close your eyes.
   2. Now focus on the peripheral sounds around you. Slowly work out to the sounds farthest away (not the quietest – the farthest away).
   3. As you do this, think about the greater world and your physical place within it. This will help distract you from other worries so you can relax.
   4. Now focus on your breathing so your breaths become deeper and slower.
   5. You might not be totally relaxed, but you will be in a better position to try the next step
3. Imagine you are sitting in a movie theatre – visualise the colour of the furniture, all the seating, the screen in front, the speakers on the wall, the aisles for people to enter and leave, the exit signs. All the different details – try to see them in your mind’s eye at the one time. It might not be easy, but this is training so you can always come back to it to see it get better.
4. Now imagine the lights going dark so you can see what will be presented on the screen.
5. An image is now projected onto the screen. It is nothing more than a bolt. But you can visualise every aspect of the bolt. The thread, any flash from forging, the shape of the head, the colour. Focus on creating every detail in your mind’s eye. Again, it might not be easy, but this is training so you can always come back to it to see it get better.
6. Keep this image in your mind’s eye for about a minute. You will likely lose the image at times, and you will need to bring it back – this is all part of the training and improving your skill.
7. Open your eyes and remember to do this again tomorrow – until you feel you are better at visualising.

There are many other things you could use meditation for (including engineering) so don’t think the above was meant to be a thorough coverage of meditation. It is simply a training exercise to help you improve your visualisation skill.

Ever since I came across it, I have been amazed by the utility and power of dimensional analysis. While many engineers vaguely recall if from their degrees as “some fluid mechanics thing”, I have used it to assess noise generated by spa pumps; optimise machine elements; augment the Design Of Experiments (DOE); review the potential to change a pressure sensor design; recall a formula in an exam that did not have a formula sheet, but did list key constants and their units; and assess the potential of a universe with different fundamental laws.
Because it can do so much more for engineers than would “some fluid mechanics thing”, it is a tool that any global engineer should master so that they can quickly adapt to new challenges. And that’s why dimensional analysis is the topic of this article.
The Universe Does Not Know What a Kilogram Is
The first thing to understand is that dimensional analysis is not really about units.
That might sound wrong because it is often taught as though it is about units. You check that metres are on both sides of an equation. You make sure seconds cancel out. You confirm that you haven’t added a force to a velocity and hoped nobody would notice.
That’s useful. But it is not the main power of the technique.
The real power is that dimensional analysis gets underneath the units.
The universe does not know what a metre is. It does not know what a mile is. It does not know what a second is or what a kilogram is. These are human inventions. They are labels we use so we can communicate consistently with one another.
But the universe does understand relationships.
It understands ratios.
If a pendulum behaves a certain way, it does not behave that way because we measured its length in metres instead of feet. If a structure vibrates at a certain frequency, it does not care if the mass was recorded in kilograms or pounds. If a fluid produces drag, it does not care if the engineer prefers SI units or imperial units.
The phenomenon is the phenomenon.
Our units are just our way of describing it.
Dimensional analysis works because it forces us to describe physical systems in a way that is independent of our arbitrary measuring sticks. It asks: what are the fundamental types of things involved here? Length. Time. Mass. Temperature. Charge. Maybe a few others depending on the problem.
Then it asks: what combinations of these things can actually matter?
That question is far more powerful than it first appears.
It is so powerful that even if the universe were to reform with different laws, dimensional analysis would still work. The laws might be different, but once there are quantities that interact, those quantities would still need to relate to each other in dimensionally consistent ways.
This is why it feels like cheating.
You can sometimes know something must be true before you know why it is true.
Rayleigh Knew This
This is not a new trick.
Lord Rayleigh used dimensional reasoning in the development of what is now often called Rayleigh’s method of dimensional analysis. He used it to explain why the sky is blue. His method is one of the classic approaches taught alongside the Buckingham Pi theorem, and Rayleigh’s method is commonly described as an early method of dimensional analysis.
In simple terms, Rayleigh’s method assumes that the dependent variable in a physical problem can be expressed as a product of the relevant independent variables, each raised to some power. You then solve for those powers by requiring the dimensions on both sides to match.
That sounds like a mathematical trick.
And in one sense it is.
But it is also more than that. It is a way of letting the structure of reality constrain your thinking before you do any testing. It tells you what forms of relationships are possible and what forms are impossible.
That is the part many engineers miss.
They think dimensional analysis is just something you use when you cannot remember the formula.
But it is really something you use when no formula exists.
Why People Think It Is Only a Fluid Mechanics Thing
The reason many engineers think of dimensional analysis as “some fluid mechanics thing” is understandable.
It is used heavily in fluid mechanics because fluid mechanics is hard. In fact, turbulence is so difficult that even with modern mathematics and computing power, we still cannot simply solve many turbulent flow problems from first principles in the nice clean way we might like to.
So fluid mechanics needed dimensional analysis.
Engineers needed Reynolds number, Mach number, Froude number, Nusselt number, Prandtl number and many others because we needed a way to understand and compare systems that were too complex to solve directly.
This is where dimensional analysis became famous.
But this also created a problem.
Because people saw the technique being used in fluid mechanics, they assumed the technique belonged to fluid mechanics.
That is like seeing a spanner used on a car and deciding spanners are only for cars.
The tool was useful there because the problems were hard there. That does not mean the tool is limited to that domain.
Dimensional analysis can apply anywhere physical variables interact.
Machines. Structures. Heat transfer. Acoustics. Electromagnetics. Manufacturing systems. Biological systems. Economic systems even, if you are careful with what you mean by dimensions.
And that should get your attention.
Because global engineers are constantly being thrown into systems they have not seen before.
Why Scientists Often Do Not Seem to Use It
There is something else interesting about dimensional analysis.
It gives insight without always explaining the mechanism.
That makes it extremely useful for engineers, but perhaps less satisfying for scientists.
A scientist often wants to know why.
Why does the system behave this way? What is the underlying mechanism? What is the causal structure? What is the theory beneath it?
And that is appropriate. That is science.
But engineers often need something slightly different.
An engineer needs to know what to do next.
Can I scale this? Can I reduce this? Can I make this quieter? Can I make this cheaper? Can I make this more reliable? Can I change this variable and get enough benefit to justify the cost?
Of course, the engineer would also like to know why. But if the bridge needs to stand up, the pump needs to be quieter, or the machine element needs to survive another duty cycle, then insight that supports a decision is already valuable.
This might be why dimensional analysis seems underused in scientific research.
I have only seen one paper where dimensional analysis was used in a way that really stood out to me, and I have only heard one physicist talk directly about using it as a research tool. That does not mean scientists do not use it. Clearly some do. But it does mean it does not seem to be emphasised as much as its power would suggest.
Engineers should not make the same mistake.
We do not need to wait until we can fully explain the phenomenon before using the insight.
How Engineers Can Use It
So how should an engineer actually use dimensional analysis?
The first use is to partially solve the relationship between variables.
Suppose you think a result depends on five or six variables. Without dimensional analysis, you might feel you need to test all combinations. That quickly becomes impossible. If each variable has several levels, your experiment count explodes.
But dimensional analysis can reduce the number of variables by combining them into dimensionless groups.
This does not usually solve the whole problem.
You may still need experiments. You may still need simulation. You may still need judgement.
But you need far fewer experiments than you would have needed otherwise.
This is where it works beautifully with Design of Experiments. Instead of designing experiments around raw variables, you can design experiments around dimensionless groups. You are then testing the structure of the phenomenon more directly.
It also works well with simulation.
If physical testing is expensive, slow, or difficult, then simulations can be used to explore the reduced relationship. You can use dimensional analysis to define the form of the problem and then use simulation to fill in the missing functional relationship.
That gives you something very close to a formula for optimisation.
Not a perfect formula necessarily.
But a useful one.
And useful is often what engineering needs.
Finding the Levers That Matter
Dimensional analysis can also tell you which dimensions you can change to get the effect you want.
This is one of the most valuable engineering uses.
Some variables give you much more bang for the buck than others.
If a quantity depends on one variable squared, another variable to the half power, and another variable inversely, then you now know something important. You know where the leverage is likely to be.
This helps prevent wasted effort.
Engineers can spend a lot of time changing things that are easy to change, rather than changing the things that matter. Dimensional analysis helps you see the structure of the problem before you fall into that trap.
It can tell you:

• This variable probably matters a lot.
• This variable probably matters, but weakly.
• This variable might not matter at all.
• This combination of variables is what you should really be thinking about.

That is powerful.
Especially when you are looking at a system you have never seen before.
The Global Engineer Advantage
This is why dimensional analysis belongs in the toolkit of the global engineer.
A global engineer cannot rely only on familiar systems.
You might find yourself working on a manufacturing problem in one country, a maintenance problem in another, a product issue somewhere else, and then a forensic investigation in a completely different industry.
You will not always have the right formula.
You will not always have the right standard.
You will not always have someone nearby who has seen the problem before.
So what do you do?
You start from first principles.
But first principles can be slow if you try to derive everything from scratch. Dimensional analysis gives you a shortcut. It lets you frame the problem quickly. It helps you identify the variables. It helps you reduce the complexity. It helps you see where  experimentation or simulation should be focused.
Dimensional analysis does not make you clever by itself. But it gives a clever engineer a way to move faster through unfamiliar territory.
And that is exactly what global engineering demands.
How to Master It
I cannot explain dimensional analysis fully here.
If I tried, this article would become a textbook chapter, and probably not a very good one.
But I do hope I have motivated you to take it seriously.
Not as something you vaguely remember from fluid mechanics.
Not as a unit-checking exercise.
Not as an academic trick.
But as one of the most powerful first-principles tools available to engineers.
If you do want to master it, then I strongly recommend having Applied Dimensional Analysis and Modeling by Thomas Szirtes in your book collection. The book provides mathematical background, procedures, and a wide range of engineering and applied science applications for dimensional analysis and dimensional modelling.
Dimensional analysis is one of those tools that can change how you see engineering problems. Once you get used to thinking dimensionally, you start seeing hidden structure everywhere.
And it might be one of the easiest ways to start using first principles properly.

There are some things in engineering that are very counterintuitive that, if not fully understood, prevent engineers from doing their best work. These perceived paradoxes can limit or misdirect your thinking such that you are not the engineer you can be. In this article, I am going to share two examples of this and then introduce a maxim that can help you with this.

Example 1 – quality is cheap
The above statement seems very counterintuitive; indeed, it is the case that you can often cut back costs at the expense of quality.
However, when a system is easy to implement, making it cheaper to realise, there is also less chance of a mistake being made, meaning quality is higher.
This was one of the reasons Toyota was so successful in the automotive industry – by focusing on making things easier to produce for higher quality, they also became cheaper. The opposite was true as well. By cutting out waste (wasted time, wasted parts, wasted steps) to reduce cost, there was less that could go wrong so quality increased.
This is not to dismiss the importance of more expensive items when needed, but often they will be cheaper in the long run anyway. It’s just that engineers can sometimes give themselves false assurity by choosing the more expensive option.

Example 2 – simple code can do more than A.I.
One would think that with more lines of code and a complex algorithm there would be more going on so it can do more.
But code that has been written explicitly can be tuned so that it achieves the exact goal desired. If a trained ML system does something wrong, then you likely have no idea what’s causing the issue. All you can do is make a few adjustments to the training system, retrain, and hope for the best.
If, on the other hand, you have explicit code, then you can understand what’s happening (or not happening), and make changes to improve performance.
This is not to be dismissive of things A.I. Comparing ELIZA to what’s on offer today shows how powerful A.I. systems have become. It is more that we can think A.I., because of its complexity, will be the better option regardless.
But still, when one considers the success in the early 1970s of much simpler systems – such as the one documented by F. T. de Dombal et al. in Computer‑Aided Diagnosis of Acute Abdominal Pain where a relatively simple program outperformed senior specialists (91% success vs 80%) – there is the potential for simpler code to do more.

What is missing in engineering thought for this to happen?

It can be found in the 1920s.

For some time, it could not be determined if light was a wave or a particle. It had properties of each – depending upon the test. However, by the 1920s, it was accepted that light was both a wave and a particle.

The “OR” was replaced with the “AND”.

And that’s the key thinking difference you need to adopt.

Stop thinking things like:

• We can have low cost or quality.
• We can have efficient code or accuracy.

Instead start thinking things like:

• What can I do to have both lower cost and high quality?
• How can I approach this so I can use simple code and increase accuracy?

​In short, stop asking the “OR” questions and start asking the “AND” questions. Make this a habit, and you will start producing better engineering outcomes – because you will not full into traps of intuition.
Everyone wants to have their cake and eat it too.
And engineers should be trying to make that happen!