A recent paper published in The Review of Financial Economics  has found that engineers make better CEO. I am sure this is a good boost to your ego right about now, but I thought it would be good to explore this more. This will help better understand what it is to be an engineer and what career options you can consier moving forward.
Fist, the details about the article.
The article, Engineering leadership: A human capital, cognitive‑fit, and innovation diffusion perspective on CEO financial performance, was written by Ehsan Danesh and published earlier this year.  In it, the author examines Fortune 500 firms (2019–2024) and reports that companies led by engineering‑educated CEOs outperform peers on ROA, ROE and net‑income growth, with stronger effects when the CEO has deeper technical education from a second degree.
Why might that be?
In The Global Engineer I argue that three capabilities sit beneath good engineering: first‑principles reasoning, systems thinking, and framing. These aren’t confined to heat‑transfer, structures, or circuits; they transfer to organisation management just as well. They help you strip away noise, see interactions and constraints, and define the real problem before allocating effort. The kind of stuff senior leaders should do when planning what to do next.
It’s also a useful reminder of what a CEO is actually expected to do: set direction under uncertainty, allocate capital across competing options, manage risk explicitly rather than implicitly, and maintain the ability to course‑correct when the system pushes back. Engineers practice this every day: quantify assumptions, evaluate trade‑offs, and take deliberate risk where it is justified. This consistent with what the research found: the performance differences appear where disciplined analysis and adoption of better ways of working compound.
So, if you’re an engineer, take leadership seriously as a future path. You’ll still need to learn finance, governance, incentive design, and stakeholder work, but the underlying structure of your thinking already matches the job. For what it’s worth, I also have a business master’s; it taught me a lot, yet I frequently found my engineering skills providing an excellent base to process and use that knowledge.
Finally, for investors, leadership background is one sensible signal to evaluate a company. When a company appoints an engineer as CEO it’s reasonable to anticipate a different and better approach to problem framing, innovation adoption, and capital allocation. The study suggests those differences can show up in the numbers. So it’s a good indicator of when to buy.
 

From one perspective, all engineers sit somewhere on a particular spectrum. At one end are those who chase the parts of engineering they personally enjoy – often the stereotypical ones. At the other are those who understand the value, satisfaction, and deep quiet pleasure that comes from embracing the entirety of the craft.

The child engineer thrives on the simple. They enjoy the burst of creativity when ideas flow, the thrill of possibility, and the fun of imagining solutions. They love the start of the adventure. But once the idea is “basically there”? They can’t imagine what comes next or the importance of it, for they are children, and their interest fades. They want to move on to the next idea, the next spark, the next moment of juvenile novelty.

The adult engineer, however, has, some time ago, discovered the joy in a broader landscape. They still enjoy ideation. And they also appreciate the deeper, richer pleasures (those that come from seeing an idea all the way through to a proper solution). They take satisfaction in shaping a concept into something real: optimising it so it is efficient to implement, verifying that it is safe when built, ensuring it meets every peripheral need that others down the chain rely on. They document it properly, not because they “have to,” but because this is part of creating something fully formed. They understand that professionalism, like adulthood, carries pleasures that are less obvious to the inexperienced, but far more substantial.

This reminds me of a quote from a man called John Edmondson. He was an advocate of antioxidants and physical challenges – at 47 years of age he managed 5,000 push-ups in 3hrs 18mins. He once said, “winning is boys; killing is for men.” By “killing” he meant killing the challenge in front of you – such as 5,000 push-up or the hill you plan to run up. It could also mean the engineering challenge in front of you. The child engineer will win by coming up with an idea. The adult engineer will kill the challenge – and implement a total solution.

Other contrasts between the child engineer and the adult engineerThe child engineer will complain loudly about tasks they dislike. They will avoid procedures because “they’re annoying,” or try to work around company standards simply because they’d rather not deal with them. The adult engineer sees these procedures differently. They recognise that standard process is what allows whole organisations to collaborate without chaos. They follow the procedure because doing so supports others. And when they know the procedure is flawed, they challenge it properly, lobby for improvement, and strengthen the system for everyone.

A child engineer has a narrow view of what engineering is: they see themselves as someone who “works on the thing and invents things.” The adult engineer sees engineering as a profession. They think about framing problems correctly, applying first principles, checking assumptions, engaging the right stakeholders, and understanding how their decision today affects manufacturing, construction, quality, service, regulations and safety tomorrow. They experience engineering in its full, interconnected richness—and they enjoy that broader horizon. It is the difference between juvenile pleasures and adult pleasures: both are real, but only one offers lasting depth.

And then there is how they engage others. The child engineer expects others to package information for them in an easy-to-digest way. They share their own information however they like and assume everyone else will interpret it correctly. The adult engineer takes the time to understand what other teams need, adjusts their communication accordingly, and gives people what they require to progress. They also push back when others try to offload their responsibilities onto them—not out of defiance, but because professionalism is reciprocal.

This notion of the adult engineer is universal. These are the engineers who thrive in global environments, where assumptions differ, cultures vary, and clarity, discipline, and respect for process matter even more. The comparative mythologist, Joseph Campbell, spent his life studying patterns that show up everywhere in human experience: archetypal behaviours that transcend local context. The transition from childlike enthusiasm to adult responsibility is one of them – it happens everywhere. And it is exactly this adult mode of operating that allows an engineer to be effective anywhere in the world.

If you are an engineering managerThe distinctions in this article are an excellent reference for your team. Many engineers simply haven’t had someone frame the difference for them. They may not even realise how often they operate as child engineers. Not because of immaturity, but because no one has ever shown them the deeper pleasures of the full craft. Sharing this with them invites growth.

If you want to grow as an engineerTake a moment now to reflect on where you sit on this spectrum. Think through the last few weeks of your work. Did you lean toward the tasks you enjoy, or the tasks that were needed? Did you shape the entire engineering journey, or just the parts that felt good? Did you help the organisation function, or make it bend around you?

Also, consider your environment. Some managers prefer their engineers to remain childlike. This can be a result of culture as well – those that are more authoritarian. Children don’t push back, they don’t question weak processes, and they don’t challenge assumptions – making it easier for a manager to maintain authority. This can feel comfortable for a manager, but it limits you. If your environment rewards you for staying a child engineer rather than growing into an adult one, you may need to consider whether your development requires moving on.

There is far more pleasure in embracing engineering in its complete form. The breadth. The responsibility. The discipline. The craft. The influence. The impact.

So where do you sit on the spectrum?
​
Do you know some child engineers?

In this article I am going to talk about a common phenomenon that has afflicted at least one engineer (usually more) in every company I have worked for. It affects engineers (and others) around the world.
And it might affect you!
And if so, then you want to know it – and how to overcome it.
Because this phenomenon is practically the first key thing you need to overcome if you wish to be a global engineer. In fact, once you crack this, the rest is fairly easy.
Which is why it is so sad to see engineers who have been limited by the phenomenon their entire careers – and never progressing as much as they otherwise could have.
So what is this phenomenon?
It has been described by numerous people in different ways with different perspectives. But you can basically say it is the notion of true independent thought.
Independent thought means you are no longer reacting to a situation. Instead, you contemplate it, you ask yourself questions about that situation, you are then prompted to think more, you collect information, you try solutions or responses to better understand the situation – and not necessarily solve it. Basically, you “explore” the situation.
No matter the culture you come from, it was likely heavily influenced by someone (and others) like this. History has many such people who thought for themselves and then laid foundations for others to work with. Adam Smith. Confucius. Mohammad. Aristotle. Francis Bacon. Karl Marx. Buddha. Imhotep. Jesus. Deganawida. There are many more. There would also be others you know who also have independent thought – but they have just not been as influential.
You too want to be such a person so your engineering, while potentially being influenced by your background, is not controlled by it.
When you can think independently:

• There are fewer genuine issues raised with your ideas. Either in review or implementation. This is because you have been able to collect the information needed to create informed ideas.
• When issues do present, you can usually overcome them quickly – you are familiar enough with the context that you thought these issues were a possibility or you understand them in an instant.
• You can justify, to yourself or others, each aspect of any idea/solution you have developed.
• You likely took your time before launching into final-solution mode.

When you don’t think independently, and you tend to be reactive:

• You often find people raise issues with your proposed solutions and feel you are often criticised.
• You can be shocked when things don’t work out as you expected.
• There are numerous aspects of any solution you put that seem arbitrary.
• You probably jump straight into coming up with a solution, and, as you do, each step feels more like a reaction to the prior step than a well-thought-out step. You basically keep shooting from the hip.

Think about the above now – and determine what kind of thinking you currently engage in.
So how do you become the type of engineer who thinks independently?

• Before you take on any task, take the time to ensure you get it. Don’t just assume you get it.
• List questions you could ask about the respective situation – put dedicated time into this.
• Allocate time to review what you are thinking of implementing, be it a handful of concepts, your understanding of the problem to be solved, more refined ideas, etc. By having these breaks in your solution process, you can check if you have been reacting (shooting from the hip).
• Keep a list in sight (maybe on Post-it notes) of all the various aspects of the situation you have discovered – this is to remind you think about these various aspect, and stop the reactionary thinking.

Once these practices become the norm, you can better contemplate your own thinking. You can then work on becoming a global engineer – and that will now be much easier.
A note for managers – demanding a design log and regular reviews can have the desired effect upon any hip shooters in your team.

I would like to first share the anecdote of what led to me writing this article.
Some time back, I started following a newsletter on LinkedIn that was written by a software engineer. We had a number of interactions within the comments section of a few posts – so I sent a connection request. After his acceptance and after reading some more of my content his message to me was “You seem to have a background in real engineering.”

He was wondering if my content was equally applicable to software engineering.

I had always assumed two things:

1. Software engineers are real engineers.
2. They benefit equally well from what I share about being a global engineer.

However, based on the anecdote above, I realise that some engineers might not make the same assumptions.

I therefore had planned, since then, to write this article – explain that yes software engineers are indeed real engineers and how they too can benefit from things like framing, systemic thinking, and first principles.

However, now seems a more opportune time to talk about this nuance of engineering identity. This is because of the mass layoffs we are seeing in the software space due to AI. This trend and how it affects people in the space – people like software engineers – was reported in the L.A. Times (https://www.latimes.com/business/story/2026-03-06/tech-layoffs-pile-up-as-sllicon-valley-shakeout-continues-into-2026). There is certainly some cynicism about this – the term “A.I. washing” is used, but it is also clear that more and more jobs in the space have been automated.

Does this automation mean that software engineers were never really engineers in the first place?
I recall when CAD became a thing. Many drafters lost their jobs – some of these people were engineers. Some engineers were then expected to do their own drafting or do their own drafting faster – so fewer engineers were needed.

I also recall the introduction of simulation software. Engineers did not need to calculate or experiment as much. Again, more could be expected of fewer engineers, and a company did not need as many engineers.
However, something else also happened. A company could now consider investing in engineers (or more engineers) because there could now be greater returns. Putting 50% more into your engineers could now see 200% more gains in product improvement – and market share or profit margins.

A.I., in the software space, I think, will have the same effect. Applications that once seemed marginal, due to the effort required to develop them, now would seem profitable – because fewer software engineers would be needed to develop the application. Also, larger applications, with even greater returns, can now be considered.

Therefore, the recent events in the software space – while deeply troubling for those who have lost their employment (and I do hope that if you are one of these people, then you find something else soon) – is an indication that software engineers are indeed real engineers. They are going through what the rest of us went through some time back.
​
But we can also look more deeply at what software engineers do and compare it to engineering expertise.

Do software engineers ever frame?
Only all the time. It is often the case that the assumed strategy to create a desired function in an application hit a stumbling block, and a new approach is needed. Also, once the feature is tried with real life users, it is found that the way people actually want to use the application is different from what is assumed. This demands a new approach or frame.

Do software engineers need to think systemically?
Do I even need to answer this? Applications need to run on something – often a diversity of machines – so this needs to be factored in. Some applications have numerous subroutines – these can interact with each other and cause numerous issues if not managed at the systems level. Most applications also run on machines that are running other applications – and you need to ensure they are compatible.

Do software engineers need to use first principles?
I recall talking with a software engineer who was writing code for a simulation package. He needed to understand the differential equations – so he needed to understand first principles. However, once the program ran, he did not know if the results were reasonable or not. So he needed to improve his first principles. First principles also helps a software engineer optimise the efficiency of the methods used to process information. This is all congruent with software engineers needing and using first principles.

After reading the above, and seeing how the experiences and attributes are so similar, it should be clear to you that software engineers are indeed “real engineers”. I would not be surprised if they are sometimes separated from other engineers, and would benefit more from interactions with other engineers, but it still remains clear that they are engineers and they can be global engineers.

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