In engineering, we often need to find the compromise of two competing requirements. This can include the way we work – and not only the solutions we develop. Engineers need to be able to work autonomously while also ensuring collaboration. We want deep work for optimisation, but we can’t work in isolation. We want agility for speedy solution implementation, but the work still needs documentation. I refer to this in the book Global Engineering as modal shifting – where engineers often need to move from one mode of work to another as the nature of the challenge changes. In the post COVID world (been a while since I used that term) working from home (and hybrid working has become more common. This has added a new nuance to engineering colocation – in the past it was about things like international teams across timelines and siloed organisation structures.
I should note that engineers should be co-located.
Hybrid work is here to stay. Some of your best work probably happens when nobody talks to you for three hours. But colocation—being in the same space, at the same time, working toward the same goal—is essential for engineering excellence.
And this has been known for a long time.
The Case for Co-Location: Obeya, Agile, and Actual Progress
If you’ve studied Lean, you’ve likely heard of Obeya—the Japanese term for “big room.” It’s not just a room full of desks. It’s a space where multidisciplinary teams come together to share plans, data, goals, and progress. The aim is shared situational awareness. The result is faster decisions, better alignment, and a sense of shared purpose.
This should sound familiar. And agile agrees.
The Agile Manifesto explicitly states: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Agile emerged from the trenches of software development, but its principles align perfectly with the needs of modern engineering: tight feedback loops, quick course corrections, and collaborative problem-solving.
None of that happens over email, text or online chats.
But Engineers Also Need Time to Think
And yet… engineers also need solitude.
There are moments when progress means going deep, not wide. When an engineer needs to put on noise-cancelling headphones, stare at a whiteboard, and lose themselves in a technical knot. That’s not just nice to have—it’s essential so you can leverage the power of your unconscious.
So how do we reconcile the need for co-location with the need for deep work?
The Maverick Middle Ground
One answer comes from Ricardo Semler’s Maverick. In his iconic book about transforming traditional management, he describes a system where employees aren’t told when to work, but rather when to be available.
Imagine a framework where engineers are expected to be onsite between 10 a.m. and 2 p.m.—a shared block that ensures collaboration, alignment, and quick decision-making. The rest of the day? That’s for solo work, whether it’s at the office, at home, or in a quiet corner of a café.
Or consider a structure where engineers are co-located Tuesday through Thursday, with the remaining days left flexible. The result? A blend of spontaneous conversation and uninterrupted focus. Team synergy and personal autonomy.
Co-Location Isn’t Just Old School Thinking.
This isn’t about going back to the old way of working. It’s about acknowledging what has always worked—and updating it for today. Engineering teams thrive when they have shared goals, shared knowledge, and shared space.
So yes, engineers should be co-located. But it need not be all the time. And not at the cost of deep work.
Instead, we can be intentional: design our workweeks to make the most of face-to-face time, while respecting the individual cognitive demands of engineering.
That’s not just efficient—it’s engineering.
If you have come across methods to find a balance between solo work and colocation that you think worked well, then let me know in the comments.

The Mars Climate Orbiter was destroyed when one team used metric units and another used imperial. The Mars Polar Lander likely failed because its software misinterpreted the deployment of landing gear as touchdown, cutting the engines too early.

Not long after these events, I was lucky enough to attend a presentation by Chris Johnson, who had been asked to investigate the disasters. He specialised in safety — how to prevent incidents, basically. His job was not to understand the technical causes (they were known); his job was to explore the organisational aspects that allowed the causes to exist in the first place.

His presentation included a number of interesting elements. For example, he was told by some government departments that they had evidence the lander was on the surface — but they could not tell him what their evidence was (that was classified). Another example was that he studied the code in the system and found that the power management software kept resetting the emergency beacon — so even if the lander had survived, it would never have been able to let anyone know.

There were many examples within his investigation that would help demonstrate key principles of engineering expertise — or, at least, what can happen when they are not applied.

However, the one element I found most interesting in his presentation was Tier Analysis.

Tier Analysis is a tool used to find the root cause of failures from the perspective of the organisation. It checks that each level of the organisation has done what it should to prevent the respective failure. In his presentation, Chris Johnson said it was basically like this:

• Blame the person lowest on the hierarchy involved in the respective project.
• Then ask: is it fair to blame them? Were they sufficiently informed and supported?
• If the answer is “no,” then blame their boss.
• Then ask if that is fair.
• Keep on repeating this process until eventually the answer is “yes, it is fair to blame this person; they should have done more.”

In the presentation, Chris Johnson noted that Tier Analysis had proven popular with many organisations. However, as they used it, they found that often there was a lot of blame placed on middle and senior managers. Those managers didn’t really care for being blamed — so they decided to stop using Tier Analysis.

And that is why I can say: it probably is the boss’ fault.

What does this mean for Global Engineers?
You can probably see how the application of Tier Analysis — and managers choosing not to use it — demonstrates the importance of well-functioning engineering teams. Shared situational awareness efforts, dedicated to ensuring all team members understand what is trying to be done and how, would mean more people could spot gaps in plans and point them out before it’s too late.

So if you are the boss, be mindful of ensuring those under you have all the information they need. If you are not the boss, then consider taking on the role of documenting everything and sharing it with others (including your bosses), so that potential issues can be spotted before they become disasters.

What would you do differently?
Have you ever been in a project where things went wrong — but the real problem was further up the chain?

Would a better flow of information, or clearer expectations, have helped?
​
Drop your experiences or thoughts in the comments — I’d love to hear how you’ve seen this play out in your own engineering career.

​You’ve likely seen this in action: people arguing about who was responsible for what, conflicting versions of the same plan, parts that don’t fit together, or teams who only discover they’re on different timelines after it’s too late. The best outcome when things like this happens is that you end up behind schedule. The worst thing is that the engineering goal is never achieved – or only partially achieved after blowing out the budget and the schedule.
This happens when engineering teams do not have shared situational awareness. Situational awareness is one of the core attributes of any successful team. And if you don’t have it, then, no matter how skilled the engineers in the team are, they will not be succeed.
This issue of lacking shared situational awareness is even more prevalent when you are members of your team are from different backgrounds. This is because each member will contextualise differently based on their background.
Therefore, as a global engineer, it is vital that you know how to create shared situational awareness.
Here are three simple but powerful ways engineers and engineering teams can build and maintain shared situational awareness – whether you’re working on software, spacecraft, or subways.

1. Get in the Same Room
It sounds simple, because it is. The first and most powerful step is to get everyone physically in the same location. In the Agile Manifesto, one of the key principles is: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
This idea has roots far older than Agile. In the Toyota Production System, it was formalized as Obeya (literally "big room"). The Obeya is a space where all the key stakeholders on a project – engineers, managers, planners – work together in close proximity. The room is visual, physical, and intentional. Everyone can see what’s happening. Everyone hears what’s being decided. No one is out of the loop.
Whether you set up a formal Obeya or simply commit to spending regular time together in the same place, you’ll notice an almost immediate increase in coordination, clarity, and energy. This will come from people talking to each other about what they are doing, and incidentally identifying differences in understanding to be corrected.

2. Use a Document of Absolute Truth
This isn’t some mythical or complicated concept – it’s a simple principle: everyone knows that no work is considered done until it’s recorded in one place.
This document – or digital repository – becomes the single source of truth for the team. It might be a master CAD model, a shared file tree, a wiki, or a visual project board. What matters is that everyone knows where it is, how to use it, and what it means.
When everyone refers to the same source, two things happen:

• Everyone has the same understanding of what the project needs to achieve.
• Everyone can see how their work affects, and is affected by, others.

These two things together make a core of shared situational awareness.

3. Schedule Regular Updates
Even with a shared room and a document of absolute truth, teams can still drift. People get absorbed in their own tasks. Decisions then get made in isolation. Then, eventually, you have conflicts within the team.
That’s why you need structured, regular updates. These aren’t just check-ins for the sake of it. They’re touchpoints that give everyone:

• A consistent, shared message
• A chance to ask clarifying questions
• A reset button on assumptions

It’s not enough to assume shared awareness will persist once achieved. It must be maintained. And that’s what the updates are for.

Final Thought: do you already do this or do you need it
Think now if you are someone who needs to put extra effort into ensuring shared situational awareness. Or maybe even needs someone else to do that for you because you always charge off working on your own tasks without thinking about others. Talk to my AI engineering coach Ingeny if you would like some ideas on how to deal with this.
Also, think about “documents of absolute truth” that you have come across. You might not have realised it at the time, but thinking back now, you can understand how they kept everyone on the same page. If you think of one, then share it in the comments – I like learning about techniques that people use.

I know I am not the first person to take on the topic of AI of late. But the conversation on how it could affect engineering in the broadest sense has not, as far as I have witnessed, been explored as much as it could be. In this post, I am going to go over some recent experiences I have had with AI in engineering, and then, from that, talk about what we could expect.

Can AI do engineering?
Recently I have been developing an AI agent to help people like you think of ways they can be better engineers. I have trained it on the knowledge I have documented on best engineering practice and given examples of how to reply in certain cases. 

The agent is called Ingeny. Try it out here.

This is the first version, and it is still evolving. So if you take the time to explore it to see how it can help you with things like your engineering skill development, career progression and working with other engineers, then you will help make it better. I would appreciate you taking the time to help evolve it. By the way, the plan is to keep it free so engineers can always use it as they wish and need.

In the process of training Ingeny, I needed to train it to respond differently depending upon whether questions are about improving engineering expertise or about actually doing engineering. In the former it does not need to provide a warning that it is not a qualified engineer. In the latter, it should let you know that while it has offered as much insight as it can, into say a design for EMC, it is still up to you to do the engineering work. 

This proved to be demanding. AI is not good with that kind of nuance: is it an engineering question or a question about engineering?

If AI can’t easily deal with the subtle difference between doing engineering and talking about engineering, then it’s probably not going to do well with the subtle differences within engineering problems that can have huge effects upon the nature of the optimum outcome. It is also going to have difficulty assessing all the systemic issues present, the best way to apply first principles, or the best way to frame. This is because the AI that seems to reason is, at this time, based on Large Language Models - words - and engineering, as I have noted before, is very visual (it’s often in the “mind’s eye”).

Does this mean engineers are safe?

For now, I can’t see AI understanding the challenges of something like reviewing the landscape to determine (or create) the best approach to building a bridge to cross an expanse of deep water. However, I understand that AI is only getting better. It is therefore only a matter of time until AI can do such things. 

I remain unsure how long that will be.

Until then, it will be the same for engineers as what has been said for writers, medical practitioners and others. The question of whether it will be engineers or AI is the wrong question. The premise is that it will be engineers and AI, so the question then becomes: how will engineers use AI?

And it’s probably going to be pretty good.
Be the engineer you wanted to be
Anecdote time. 
When I was in academia, I would sometimes ask my students who of them wanted to be the type of engineer who understands the fundamentals of theory and first principles, but wants to be more an ideas person who then gets other engineers to make the ideas happen. Everyone would put their hand up. I did this to show my students that the chances of them getting such a job, given the popularity of such a job, is minimal. That means they were all going to have to make the ideas happen as well as coming up with the ideas.
However, AI has probably proved me wrong.
While I think it will be some time until AI can truly do engineering work, I can see it, fairly soon, doing a lot of the grunt work so that we can be the ideas engineer.
How would this work?
Software engineers are showing us how this could play out. They have felt the brunt of AI more than others, because, out of all the engineering disciplines, software engineering is the most language based. And a Large Language Model is ideal for that kind of work.
But while software engineers have been hit the hardest, they have also shown that they are valuable when it comes to the initial idea and providing the right prompt.
That’s what could very well be the case for the rest of us engineers. Consider the following:

• Providing the description for the part you want, and AI then generating the CAD features to produce that part. You can then take a look at the first iteration and describe the changes you want made - then, they would be executed with the speed of AI. If you have been a CAD monkey like me, then you know how much time this could save and the ideas you could generate when you only need to consider the final outcome as opposed to how to generate it.
• Asking AI to generate a circuit board design based on the inputs, outputs, and the available space. Once again, you can review the initial iteration and make suggested changes.
• Using AI to take your initial free body diagram - maybe hand drawn - generate all the force and moment balance equations, solve them for the key parameters you have identified and then optimise for the one parameter you are interested in. You could draw up a number of ideas and have them all analysed near instantly.
• Importing the bill of materials of a product you need to make to an AI system and then asking it to generate the layout of a production line that could make the product. You could then use it to develop details for each work station, estimate the time to complete work, then step back out to see how that affects the overall work flow, iterate, and then do other work stations. With AI to execute your instructions, you could design an optimised production line at an incredible speed.
• ​Have all the parameters set up instantly and to best practice for a CFD simulation. So you need to only focus on analysisng the results, assessing them for validity and then contemplating what changes to implement next.

You can see in the above, that you are automatically like the chief engineer getting other engineers to execute the detailed work for you to review. Imagine also that you can likely talk to the AI system and use peripheral devices to augment your instructions - like when you sketch and use hand gestures to work with colleagues. This is the type of work that many engineers I know would love to do.
The major challenge I see is that we will need to establish how we will train engineers to get to the level where they can be the ones providing the initial instructions. Maybe that is a post for another time.

What will come after this?
There is a chance that one day AI can do our work. I am not one of those people who naively says “AI can never do my job.” But I am not saying I know it can either. So the best thing is to be ready for what could come.

And if AI can one day do all the engineering, including the ingenious stuff, then it has probably also become smarter than us. And If it is that smart, then, like other smart entities (us), it will likely have pets. So work on being adorable to AI so it wants to keep you as a pet and make you happy - not a bad life really.
What are your concerns?
Do you have any thoughts about AI in engineering or any concerns? Share them with me in the comments. And also let me know how you go with Ingeny.
Note
And so you know, while I do get AI to help check my articles, I do write them. Usually on a Sunday night. But I will use AI to often generate my images - if I can’t find a suitable one online - and I sometimes dictate the article content to be cleaned up and written (this one was typed though).

A Review of The Culture Map by Erin Meyer
If you're an engineer who’s worked in, moved to, or collaborated with people from a different country — or if you're about to — then, The Culture Map by Erin Meyer is a book you should buy now. It’s written for anyone navigating the often-unspoken expectations that govern professional interactions across borders.
And it’s especially pleasing (as well as interesting) for engineers, not because we’re immune to cultural friction, but because it reveals how we have a unique approach that helps us overcome cultural differences -- and shows why engineering is an ideal job if you want to travel the world.
Hopefully this has your interest, so let me explain more.
One of the most striking elements in The Culture Map is how it breaks down workplace behaviours across eight cultural dimensions — from how decisions are made, to how feedback is given, to how trust is built. It's not just stereotypes; it's data-informed insights that can help prevent the kind of miscommunications that quietly derail international teams.
What’s fascinating is that the patterns aren’t always what you’d expect. A memorable example in the book highlights how, in China, the Germans and Japanese seemed to work well together — and so did the French and Chinese — but not the Germans and French, or Japanese and Chinese. That might surprise people who assume cultural compatibility comes down to geography and shared history. But engineers will recognise that these kinds of relationships often stem from unspoken assumptions around hierarchy, risk, and workflow — and that’s exactly what Meyer helps unpack.
Now here’s where it gets interesting for engineers. While The Culture Map lays out how professionals from different cultures might clash or confuse one another — for example, over how to run a meeting, make a decision, or teach a concept — engineering practice already gives us a head start.

Meetings: Clarity of Purpose
In some cultures, a meeting is a space for brainstorming. In others, it's where decisions are made. Elsewhere, it’s a rubber stamp for decisions made beforehand. But as any good engineer knows, meetings are tools — and every tool needs a purpose. We specify why a meeting is happening and what we’re trying to achieve, whether that’s exploring options, aligning teams, or confirming next steps. It’s a discipline that cuts through cultural ambiguity — and it’s one I emphasise in my own book as well.

Decision-Making: Inputs and Iteration
Another key difference across cultures is how decisions are made. Some rely on hierarchical authority; others favour consensus. But again, engineers are used to getting input from across levels of an organisation — because that’s where insight comes from. The book gives an insightful example of Japan: a highly hierarchical society that still makes enormous efforts to gather input from across the organisation. This approach — exemplified in the Japanese Ringi system — will make a lot of sense to engineers, who already understand that hierarchy and consensus aren’t necessarily in conflict.

Learning Styles: Why and How
One of cultural differences the book highlights is how people teach. Some do so by diving into theory (the why). Others teach through practical demonstration (the how). Engineers don’t get to pick. If you’re going to master a system or innovate within one, you need both the underlying principles and the procedural steps. So again, where cultural differences might trip others up, the engineering mindset already pushes toward integration.

Respect, Authority, and Curiosity
But perhaps the biggest cultural challenge for engineers abroad is this: in some cultures, the behaviours that earn respect may run counter to the behaviours that make you a better engineer.
In my own work and writing, I’ve emphasised the importance of being physical as well as theoretical, asking questions, seeking input from others, and being willing to be wrong. But in certain contexts, asking questions of a subordinate might be seen as weakness. Or challenging a superior might be seen as disrespectful. Getting your hands dirty could be an issue as well. As Meyer points out, these norms matter. She encourages readers to lean into local culture — a sensible and respectful approach — but I’d offer a slight caveat for engineers: don’t lean so far in that you lose the technical behaviours that make you effective. The risks we’re trying to prevent — design flaws, safety issues, implementation gaps — don’t respect cultural boundaries.

A Recommendation (and a Tool)
Even if you're not deeply interested in culture, if you’re just an engineer working across borders, then culture should be an interest. The Culture Map is a fantastic entry point — readable, grounded, and full of insights that will help you interpret the subtle dynamics around you. And there’s a bonus: Erin Meyer’s website includes tools that let you compare cultures across the eight dimensions, and even evaluate your own tendencies. I recommend checking it out if you’ve ever thought, “Am I the weird one here?” or “Why does this keep happening in meetings?”
Because sometimes you are. And sometimes they are. And sometimes, it’s just culture.

Let me know if you’ve read the book — or if you’ve got your own experiences to share from working across cultures as an engineer. I’d love to hear your stories, and maybe even build a list of engineering tools and mindsets that help us thrive, no matter the country or context.