Different industries have genuinely different domain knowledge. But underneath that expertise, organisations repeatedly encounter the same systems problems: information has to move, decisions have to be made, dependencies have to be managed, specialists have to be coordinated, resources are constrained, circumstances change, and humans remain inconveniently human.
About three years ago, I moved into construction because I was over the tech industry and wanted to do something completely different.
A couple of months into my new role as a construction project coordinator, I had a slightly annoying realisation:
Even this is the same.
We’re moving different widgets around different systems, but beneath the terminology and technical detail, many of the underlying structures are remarkably similar.
Plumbing, electrical and telco systems obviously aren’t the same. Each has its own technical requirements, risks, regulations, and specialists who know far more about their field than I ever will.
But zoom out far enough, and they start to look surprisingly familiar.
Something needs to move from here to there. It passes through different parts of a system with dependencies and constraints. Something interrupts the flow. We need to figure out where the problem is, who understands that part of the system, what needs to change, and how we’ll get it working again.
At my core, I’m a project manager and a relationship builder. I tend to understand something new by asking:
What is this similar to that I already understand?
Then I build the differences back in.
It’s how I went from knowing virtually nothing about routers and switches to effectively supporting network engineers. It’s also how I can now talk with a plumber about where a drainage line has collapsed, what needs to happen next, and how we explain the proposed solution to the people approving the work.
I don’t need to become the plumber or the network engineer.
I need to understand enough of their world so we can work effectively together.
That brings me to something I’ve noticed in project management job advertisements. Many place significant emphasis on years of experience within one particular industry or technology. Sometimes that makes perfect sense. Some projects genuinely need a PM with deep domain knowledge and existing relationships.
But we also need project managers who are simply great at project management.
A PM needs to build relationships with SMEs, ask good questions, identify dependencies and sticking points, translate information between people, maintain visibility across the project, and keep everyone moving towards the same outcome.
The PM shouldn’t necessarily be the person disappearing deepest into every technical rabbit hole. Often, a better use of their time is getting SMEs the information, people or decisions they need, removing blockers, and letting them do what they’re actually very good at.
The project manager’s job isn’t to become every SME. It’s to get the best out of the collective expertise already in the project.
This diagram is deliberately simplistic, but at a high enough level it can describe an extraordinary number of systems: plumbing, electricity, telecommunications, logistics, information flows and even some organisational structures.
The details are different.
The basic questions often aren’t.
**Where are we now? **
**Where are we trying to get to? **
**What’s stopping the flow? **
**Who understands that part of the system? **
**What do they need from everyone else? **
What needs to happen next?
When something breaks, reality hits, and the project suddenly feels like an end-of-the-world scenario, it’s then down to the PM: establish the current state, understand how it differs from the plan, identify what’s actually preventing progress, and coordinate the people who can get it moving again.
Sometimes it’s easier to see that when you’re not the person deepest in the technical detail.
And there’s another benefit to this approach that gets underestimated: relationships.
I’ve found most SMEs are incredibly generous with their knowledge when you ask good questions and genuinely respect their expertise. Let them explain what they can see. Build enough of their model in your own head to ask the next useful question.
Stripping a system back to its essential parts, understanding the relationships between them, and then adding the domain-specific detail back in helps me understand unfamiliar problems.
More importantly, it helps me understand the people I’m working with.
Because when the plan inevitably meets reality, it’s rarely one person with all the answers who gets a project through.
It’s the relationships between people who know different parts of the system.
The widgets change. The domain changes. The method transfers.
And increasingly, I find myself looking at supposedly completely different industries and thinking:
It’s all the bloody same.
Originally published on LinkedIn.