I work with a plumber who has joked more than once about coming to work for him.
Apparently, I do excellent scopes.
Which is lovely.
But also slightly unfair.
Because he gives me half the answer.
He knows the plumbing. I know the system.
A quality scope happens in between.
What actually happened?#
On some of the more complicated jobs we work on together, we’ll spend a surprisingly long time on the phone reconstructing exactly what happened.
Not because I know more about plumbing than he does.
I absolutely do not.
He understands the physical system. He knows what he found, what failed, what had to be exposed, what he repaired and why.
I understand the system that information has to travel through.
The reporting requirements. The scope. The codes. The evidence. What the client needs to see to understand what happened and make a decision.
So I ask questions.
Where exactly was the problem?
What did you expect to find?
What did you actually find once you opened it up?
Where did the existing pipework run?
What had to be removed to access it?
What did you replace?
Where does the new pipework run?
What could you see before you started, and what only became apparent once the work was underway?
Sometimes we’re on the phone for quite a while.
But eventually I can see it.
Not in the way he can see it. I’m still not a plumber.
But well enough in my mental model to understand what actually happened.
And that’s the point where I can start translating.
Sometimes you don’t know until you open it up#
I think this is an important distinction.
Sometimes the scope changes because somebody got something wrong.
But sometimes the scope changes because new information became available.
You can only scope what you can reasonably understand from the information available at the time.
And buildings are particularly good at hiding information inside walls, underneath floors, and behind things nobody can see until somebody starts taking them apart.
Once the work begins, reality occasionally has some additional comments.
On one recent job, the original scope significantly underrepresented the work that ultimately had to be completed.
That didn’t necessarily mean the original scope was bad.
Some of the information simply wasn’t available yet.
The plumbers started the work.
They uncovered the problem.
They learned more.
They adapted the repair to what was actually there.
And now that new information had to make its way back through the rest of the system.
That’s where I came in.
You can’t translate what you don’t understand#
My job wasn’t to find a clever way to make the scope bigger.
It was to understand what had actually happened well enough to represent it accurately.
So we reconstructed the work.
The plumber explained the physical reality.
I asked increasingly specific questions.
I mapped where the pipework ran, where the issue had been found and where the repair had occurred.
I made sure the reports clearly showed what had been discovered, including the things that couldn’t have been known until the problem was physically uncovered.
Then I could translate all of that into the system I work within.
And importantly, I could explain it to the client.
Not:
“The plumber says we need this. Please approve.”
But:
This is what we originally understood.
This is what was uncovered once the work began.
This is where the issue was.
This is what was required to fix it.
And this is the evidence showing what happened.
The client could see what they were being asked to approve.
I could stand behind what I was submitting.
And the plumber could be paid fairly for legitimate work that had actually been completed.
The work didn’t become worth more because I found better codes.
The work had already happened. The original scope just didn’t capture all of it.
Neither of us had the whole answer#
This is the bit I love.
The plumber couldn’t produce my half of the answer without understanding the system I work within.
I couldn’t produce his half without understanding what had physically happened.
Neither of us needed to become an expert in the other’s field.
We needed enough shared understanding to connect the two.
And when we did, we produced something neither of us could have produced as well alone.
The plumber brought deep specialist knowledge.
I brought knowledge of the contractual, reporting, and approval system that his work had to move through.
The client brought another perspective again: they needed enough clear, defensible information to understand what they were approving.
The answer existed at the interface.
I think this is why I keep ending up here#
I’ve worked across some very different industries.
And I’ve realised that a surprising amount of the work I enjoy most happens in these spaces.
Between the technical specialist and the client.
Between the physical problem and the system used to record it.
Between what happened and how we explain what happened.
Between one person’s expertise and another person’s decision.
I like learning enough about one side to translate it properly to the other.
Not pretending to be the specialist.
Not stripping out so much complexity that the meaning disappears.
Just understanding enough to ask useful questions, identify what matters, and carry the information across without distorting it.
Because sometimes the specialist doesn’t need to learn your entire system.
And the client doesn’t need to become a specialist.
They need someone who understands enough of both to help them understand each other.
That’s the work I love.
The bit in between.
The work that happens at the interface.
Originally published on LinkedIn.