CJSTEELE
  • Home
  • About
  • Contact
  • Blog

The Global Engineer Blog

​The True Age of Engineering Documentation is Coming

26/4/2026

0 Comments

 

Or: How you can instantly become the old guy who has seen it all!

A young engineer who has acquired decades of expeirence
As an engineer, you probably don’t like the documentation side of things. You should at least see its value, but, in my experience, engineers are usually not fans.
We know that it protects the organisation, supports future work, and helps others understand what we have done. And yet, under time pressure, documentation is often the first thing to be condensed, deferred, or quietly abandoned.
This is not new.
But there is going to be a new pressure to create even more documentation.
Not because management suddenly cares more. Not because standards have become dramatically stricter.
But because the value of documentation has fundamentally changed. And it’s because of AI.
How AI Will Make Documentation More Valuable
Historically, documentation has been hard to use well.
It was often written because it needed to be and then just left. People might refer to meeting minutes to double-check their deliverables. But usually, it would be left until there was an audit or something official like that.
And that meant it was written in a way that was only useful for such things. Which in turn meant that it was hard to use for other things. Things like:
  • Understanding why an engineering system was set up the way it is. Ideal for new members of an engineering team.
  • Knowing if options had been considered or tried – and if they would work or not.
  • Explaining how the system works – to engineers and non-engineers.
This was, and is, a great loss. People could easily make the same mistakes or not understand the system well enough to think of improvements.
AI changes that completely.
With comprehensive documentation of an engineering project (design decisions, options considered, trade studies, constraints, assumptions, experiments tried, and outcomes), it is possible to interrogate all of it quickly.
Not by reading everything line by line, but by asking the question you want answered.
Interrogating Engineering History
Imagine you are looking at an existing engineering system and considering a change.
If you have good documentation, you can now ask an AI system questions like:
  • Was this kind of change considered previously?
  • What alternatives were explored at the time?
  • Was something similar attempted and found to fail?
  • What constraints drove the original decision?
  • What assumptions were critical—and are they still valid?
The AI does not invent the answers. It mines your own engineering record.
This documentation becomes your operational knowledge.
You won’t repeat the same mistakes and you can better assess new ideas with the knowledge you now have. It’s like you have become the old guy in the company who has seen it all!
Documentation Will Be Demanded More – Because It’s Easier
There is definitely a certain irony here.
The same technology that makes documentation more valuable also makes it easier to produce. Engineers can now:
  • Dictate notes instead of typing them
  • Generate concise summaries from long discussions and disjointed meetings
  • Convert rough thoughts into structured explanations
  • Maintain logs with minimal friction
As I mentioned in the previous article on one-pagers, AI can help you turn raw notes into something readable and useful. That capability will remove many of the traditional excuses for under-documentation.
And once that happens, the expectation will shift.
If documentation is easy and highly valuable, it becomes harder to justify not doing it.
For the Global Engineer (and Company)
This matters even more in a global engineering context.
When documentation exists, AI allows it to be repurposed for different audiences.
Language barriers are reduced. Differences in writing style, cultural expectations, and technical depth can be adapted on demand.
That means documentation no longer has to be perfect for everyone. It just has to exist. Making it easier again for an engineer to work anywhere in the world.
It also means an engineering company can be more robust.
Engineering teams change – sometimes when you least expect it.
People get reassigned. Projects ramp down. An entire engineering team gets taken out by food poisoning at a corporate barbecue.
When a new team comes in, good documentation plus AI dramatically reduces the recovery time. New engineers can interrogate the history of the project instead of starting with fragments and assumptions.
Think about all the lunar exploration knowledge that needs to be relearned with the recent efforts to return to the Moon.
Knowledge that can be reused, transferred, explained, and interrogated is far more valuable than knowledge locked inside a few people’s heads. When all past experience within a company is documented and easy to use, it increases the value of the company’s intellectual property by orders of magnitude.
And an engineering firm would be foolish not to demand all knowledge now be documented.
The Shift That’s Coming
Engineers are probably going to be asked to document more than they ever have before.
You might not like it. You might resist. But, as the above shows, the payoff will be real.
The best you can do now is start using AI to make this documentation easier to generate and then be mindful to use AI to access that documentation (and others) in the future.

0 Comments

​The old school power technique for engineering team alignment

19/4/2026

0 Comments

 

Or – Death to meetings!

Picture
Let’s talk about how you can use an old and well-established technique to bring your team of engineers (no matter where on the globe they hail from) into alignment of understanding. And without the need for time-consuming meetings that no one seems to be mentally present at anyway.
Recently there have been stories about how Jensen Huang reads a huge number of emails each morning. The story is likely exaggerated – a calculation of the implication of the claims indicates that he would not really be reading the emails. However, there are details about the nature of the emails – written so that the key points can be extracted quickly – and how this allows for a much flatter company structure - Jensen Huang can quickly distil key information for situational awareness without the need for middle management or excessive and wasteful meetings.
He has been described by some as revolutionising management.
But is this really anything new?
Not really – it is a variation on the theme of the established one-pager.
The one-pager you say?
The one-pager has been a tool of business and management for so long it is hard to establish the origin. That’s an indicator of how powerful it can be. Yet many still do not understand the power, and do not use this remarkable tool.
Why is the one-pager so powerful?
It comes down to two things: the speed of talking and the speed of reading.
People can speak about 150 words a minute. They can read up to 300 words a minute.
You can see the power already.
If, instead of asking people to present in a meeting, you ask them to write a one-pager for others to read, then you have just halved the time demands on each person involved.
But there is even more benefit.
Each person can read at a time that suits – allowing them to better manage their time in general. They also focus when they read – instead of sitting in a meeting looking like they are paying attention when they are not (especially if the meeting is an online one when everyone is working on other things anyway).
And not the disadvantages you might assume.
You might assume the use of the one-pager is a one-way thing: no chance to ask questions. But, after reading a series of one-pagers, you, and others, can follow up if needed. Maybe even call a meeting – but this time you know that meeting will be focused, and of greater value.
Excellent record keeping.
If you have a repository of one-pagers for any engineering project or activities, then you have a great record of efforts. This can be excellent to review why certain things have been done, find how to resolve issues solved prior, and to prepare for stage gate presentations or audits.
Nuances in the global context.
If you do choose to try the one-pager in a global context, then you will find that different cultures will write them differently. And none of them will be ideal.
Western-style. Tell ‘em what you are going to tell ‘em, tell ‘em, and then tell ‘em what you told ‘em. The use of this tricolon method does help to drill the point. But it does also mean space has been wasted – you do have only one page after all.
Confucian style. Spiral to the point. Cover the various aspects of concern as you slowly get to your point – like exploring the whole landscape so nothing is missed. It is a good way to ensure coverage, but, as we will learn, it is good to be upfront with the point.
Arabic style. The zigzagging of iteration. The traditional Arabic approach is start each section with a summary of the last and how it links to the new one. It is indeed good to note interconnectedness, but there is limited space so best to be concise.
The ideal style of the one-pager.
Start with the main points to be conveyed. That helps the reader determine if they need to read more – thus saving people even more time. This section should include any thoughts on how others could be affected – so you can be more sure people will know if they need to read on. It should also include what support, if any, is needed from others – you won’t get help if you don’t ask.
Next, provide the detailed information to support the above. There should be no new information here – just details to better explain what has been said. And it could include images, but do not use up too much space.
You can of course stipulate any format you wish. But be careful. When you are too prescriptive other engineers lose their initiative, you can waste space on things that are not important, and you might not get all the details that are actually relevant.
A truly ideal application for AI in global engineering.
“I apologize for such a long letter - I didn't have time to write a short one.” ― Mark Twain
It does take time to write a concise one-pager. Not much more than it should take to prepare for a presentation in a meeting, but time, nonetheless. So anything that can help with that is ideal.
And AI is excellent at taking a list of thoughts, ideas, questions and so on, and then turning them into a polished concise document. I use it frequently in meetings to take people’s individual comments and then turn them into topic-based meeting minutes in an instant.
Not to mention auto-reviewing.
I mentioned above how a collection of one-pagers can make a great record of an engineering project or be used for audits. Well, you can use AI for these things too. If all the one-pagers are fed into an AI system, then you can:
  1. ask it about ongoing issues that present,
  2. report on the status of specific issues,
  3. ask how you might solve a challenge you currently have, and
  4. get it to generate larger summaries of the state of a design of a project – ideal for management and induction of new engineers.
Take the time now to think about the kinds of things you could get AI to generate if you had a large collection of one-pagers for the engineering project(s) you are working on now.
And it can translate too!
So anyone in your team can write in any language they like, then have it translated into the language the team uses. It can then also be translated into the reader’s language to help further again to enhance understanding.
You can see now the power of the one-pager as an alternative to having someone(s) present in a meeting – especially as a global engineer.
So if you have ongoing meetings where people update their efforts and you think are not doing their job well, or, people seem to waste time calling a meeting each time they have an issue, then try the one-pager method.
Suggest a layout and encourage people to use AI to help.

0 Comments

​Is being a good engineer enough? Is being a global engineer better than being a good engineer?

11/4/2026

0 Comments

 

Or: How competence can hold you back

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

​Fruit Salad Engineering

5/4/2026

0 Comments

 

Or: why a diverse team is a good engineering team

Engineering fruit salad
How do you have the best engineering team?
You might, depending upon your age (or your children’s age) know the song We’re all fruit salad by The Wiggles.
The lyrics note that you can’t make the perfect fruit salad with only one fruit. You need a lot of different types of fruit.
Also, in the lyrics, it is noted that the fruit bowl is the world. Meaning the world is a better place with diversity.
But the analogy does apply when the bowl is an engineering department as well.
If you want an excellent team, then it too should be like fruit salad.
Why is this so?
There are two reasons:
  1. The three attributes of engineering expertise.
  2. The implications of a fruit salad engineering team.
If you have been reading my content for a while now, then you know that the three attributes of engineering expertise are:
  1. Framing – looking at a problem from a different perspective to find an easier engineering solution to implement; allowing for greater success sooner.
  2. Systemic thinking – considering ALL aspects of an engineering challenge for potential issues and opportunities so that the solution eventually developed is comprehensive and optimised.
  3. First principles – using scientific knowledge so that every decision is informed and optimal.
When you have a diverse team of engineers, they are more likely to:
  1. Provide different perspectives so you can find the best frame.
  2. Consider more aspects of any challenge, due to different experiences, values and education.
  3. Cover more first principles due to having different areas of expertise.
If you have a team of people who have all studied in the same institution and worked for the same company, then you can expect them to all think the same. They will all have the same blind spots, the same biases, and the same foci. Thus, they will not catch others’ mistakes and they will not spot opportunities missed by the rest of the team.
So next time you are putting an engineering team together, or looking to join an engineering team likely to succeed, make sure it is diverse. In as many ways as possible, country of origin, place of education, places worked, age, sex, and anything else that makes engineers different.
Of course, you can and should always be working on broadening your own engineering skills, experiences and knowledge. And so should the others in your team (no matter how diverse it might or might not be). You and your colleagues will each be more well rounded bowls of fruit salad, but it always helps to have a bigger bowl with more fruits.
0 Comments

    Author

    Clint Steele is an expert in how engineering skills are influenced by your background and how you can enhance them once you understand yourself. He has written a book on the - The Global Engineer - and this blog delves further into the topic.

    Archives

    July 2026
    June 2026
    May 2026
    April 2026
    March 2026
    February 2026
    January 2026
    December 2025
    November 2025
    October 2025
    September 2025
    August 2025
    July 2025
    June 2025
    May 2025
    April 2025
    March 2025
    February 2025
    January 2025
    July 2024
    June 2024
    May 2024

    Categories

    All
    3-body Problem
    AI
    AND Vs OR
    Attachment
    Attention
    Attitude
    Autarky
    Best Engineer
    Budgets
    Business
    Calculations
    Capitalism
    Career
    Casestudy
    Change
    Chief Engineer
    Creativity
    Culture
    Data
    Decision Making
    Design For Design
    Development
    Dimensional Analysis
    Documentation
    Economics
    Education
    Employment
    Engineering Cognition
    Engineering Teams
    Entrepreneurship
    Experiments
    Expertise
    First Principles
    Fixation
    Focus
    Food
    Framing
    Gender
    Globalisation
    Globalization
    History
    Indian
    Ingenuity
    Innovation
    Intuition
    Invention
    Knowledge
    Language
    Leadership
    Library
    Luck
    Manager
    Mathematics
    Maturity
    Meditation
    Meeting
    Mentorship
    Modal Shifting
    Negligence
    Optimisation
    Optimization
    Paradox
    Political Correctness
    Politics
    Problem Solving
    Product Review
    Professionalism
    Project Management
    Protégé Effect
    Protégé Effect
    Race
    Real Engineering
    Religion
    Retro Enigneering
    Rockstar Engineer
    Safety
    Self Sufficiency
    Self-sufficiency
    Sensing
    Sex
    Shared Situational Awareness
    Simulation
    Software Engineers
    Spacex
    Stupid Things Engineers Have Said
    Systemic Thinking
    Tariffs
    Technology
    Thinking
    Tier Analysis
    Transferable Skills
    Trump
    Visualisation
    Western
    What Would An Engineer Do
    Willpower
    Wokeness

    RSS Feed

Proudly powered by Weebly
  • Home
  • About
  • Contact
  • Blog