One of the difficulties of relying on an external technology supplier is knowing when to challenge their advice.
You engage specialists because they have expertise your organisation may not have.
You expect them to recommend the right solution, configure it properly and explain what you’re paying for.
But what happens when you begin questioning whether the advice you’re receiving is actually right?
I faced this situation with a supplier responsible for part of our network infrastructure.
We had the equipment, but questions remained
We had two data centres, each with two Cisco firewalls.
The equipment had been supplied with high availability as part of the solution.
During a review, one of our engineers questioned how the firewalls were configured.
He could see the equipment, but he couldn’t see the firewalls working together in the way he expected.
That led him to investigate further.
The configuration raised concerns about whether the high availability we believed we had was actually in place.
This wasn’t something I could independently verify.
Cisco firewall configuration wasn’t my area of expertise.
But I didn’t need to be the person diagnosing the configuration to recognise that the concern mattered.
If we had paid for a resilient setup, we needed to establish whether that was what had been delivered.
Then came another recommendation
The supplier was also recommending additional equipment to support 10 Gbps connectivity.
Our engineer identified a problem with that recommendation.
The connection between the data centres was limited to 1 Gbps.
Buying equipment capable of 10 Gbps wouldn’t remove that limitation.
There were budget concerns, too.
I needed to understand why we should approve further investment when the expected performance improvement couldn’t be achieved with the existing connection.
Rather than trying to challenge the supplier on technical details I didn’t fully understand, I arranged a discussion involving the supplier and our engineer.
My engineer explained the technical concerns.
I focused on understanding the recommendation, its cost and whether it would deliver the intended outcome.
The supplier acknowledged the bandwidth limitation and agreed that configuration changes were needed.
We didn’t proceed with the additional equipment.
The bigger issue was confidence
By this point, my concern wasn’t simply about one equipment recommendation.
We had questions about the configuration of a solution that had already been delivered.
We had also been presented with an investment that wouldn’t achieve the expected result without addressing another limitation.
Neither issue, on its own, necessarily meant the supplier was incapable of delivering good work.
But together, they changed how comfortable I felt relying on their advice.
A supplier relationship depends on more than whether somebody can install and configure equipment.
You need confidence that the recommendations consider your actual requirements, that the work delivered matches what was agreed, and that unnecessary complexity or cost isn’t being introduced.
Eventually, we stopped using that provider.
Our engineer had the expertise to take ownership of the configuration and ongoing management.
That made the decision possible.
But it also made me think about what would have happened if we hadn’t had that expertise internally.
We were fortunate to have the right person
Looking back, we were fortunate.
Our engineer understood the technology well enough to identify the concerns and explain them.
Without him, I might not have had sufficient information to question the supplier’s recommendations.
That’s an uncomfortable position for a technology leader.
You remain accountable for the decisions, even when you depend on somebody else to explain whether the proposed solution is technically sound.
One answer is to seek independent validation from another subject matter expert.
But that introduces another consideration: budget.
You cannot realistically commission an independent technical review for every supplier recommendation or configuration change.
And if you lack the expertise internally, you may not immediately recognise which decisions deserve closer examination.
The challenge is deciding when the cost of getting something wrong justifies spending more money to validate the advice.
For me, the importance of the system, the potential consequences of failure and the level of confidence in the supplier all influence that decision.
Trust still needs evidence
I don’t believe technology leaders need to be experts in every technology they oversee.
But they cannot simply accept a recommendation because it comes from a specialist.
They need to understand what the business is trying to achieve, what is being proposed, what assumptions support it and what happens if those assumptions are wrong.
Sometimes that means challenging a supplier directly.
Sometimes it means involving an internal engineer.
And sometimes it means paying another specialist for an independent opinion.
The important thing is recognising when confidence is no longer supported by enough evidence.
You can outsource technical expertise and implementation.
You cannot outsource responsibility for deciding whether the business is getting what it needs.