By Nikki Marsh, CRO
The most useful conversations I’ve had over 30 years in telecom were the ones where the person across the table had decided to be straight with me. That’s especially true for me now in my leadership role at DQE. When IT leaders are candid about what they need, what their last provider missed, and what they wished someone had told them before they signed, then we can have a real conversation.
What I heard in those conversations was less about uptime percentages and more about the deployment that slipped three weeks with no one calling to explain why; the 2 AM outage where, four transfers in, nobody had seen the environment before; the provider who met every SLA requirement while being effectively unreachable when something complicated came up.
Reliability, to them, was never one thing. It was the sum of all the moments a provider either showed up or didn’t. I brought those conversations with me when I joined DQE, and they helped form the framework we call the four pillars of reliability. The full version is here.
What I want to offer here is an explanation of what it costs when any of the pillars is unreliable.
Infrastructure:
You Don’t Find Out Until It’s Too Late
Infrastructure failures are so damaging because they are invisible right up until they aren’t. An IT leader can operate for years without a significant outage and reasonably conclude that their infrastructure is sound. But what they’ve actually established is that nothing has been tested yet.
When the test comes, the outage itself is only part of what happens. The other part is the discovery that the architecture described in the proposal and the architecture installed in the ground are not the same thing. Paths that were documented as independent shared physical conduit. A ring designed to reroute automatically converged at a facility that went offline. The IT leader finds this out at the moment they have the least capacity to absorb it, managing a live crisis while also reckoning with what the crisis has just revealed about decisions made sometimes years earlier.
Delivery:
The Deployment Phase Is the First Test of the Relationship
Delivery reliability was the criterion I most consistently watched IT leaders underestimate, and the one that came up most often in the candid conversations afterward. It rarely appeared in a formal vendor evaluation. It almost always shaped how the relationship was experienced from that point forward.
The cost of a delayed deployment is not limited to the delay itself. It extends to every project, team, and business commitment that was organized around an expected go-live date – and the organizational pressure that generates doesn’t distribute evenly. It lands on the IT leader who made the vendor decision and is now explaining to stakeholders why the timeline has moved again and when it reliably won’t.
More subtle cost is what the deployment reveals about the provider’s operating character. A provider who manages a slipping timeline by going quiet is demonstrating, under relatively low stakes, how they will behave when the stakes are higher. By the time the network goes live, the IT leader has accumulated more evidence about their provider than any reference check would have produced.
Support:
Troubleshooting Starts Before the Ticket Opens
Support failures are the ones IT leaders remember most precisely, because they are experienced personally, in real time, under conditions that don’t allow for detachment. No one evaluates their provider’s support capability from a position of calm. They evaluate it mid-outage, with something critical down and the business watching.
What I heard from IT leaders who had been through a bad support experience was about the helplessness of being caught between a problem that needed solving and a provider structure that wasn’t organized to solve it. The problem wasn’t competence. It was that the structure placed the competent people too far from the moment of urgency.
The full cost rarely appears in post-incident reviews. It includes the hours the IT team spent managing the provider rather than the problem, the internal communication required to explain to leadership why resolution was taking as long as it was, and the recalibration that followed — where the IT leader adjusted their working model of what their provider was actually capable of.
Partnership:
Accountability Requires End-to-End Ownership
Partnership failures are the least visible in the moment and the most consequential over time, which is part of why this pillar is so difficult to evaluate before a contract is signed. Partnership failures tend to surface gradually, through a pattern of interactions in which responsibility was unclear, complicated questions were referred elsewhere, and the relationship that was described during the sales process turned out to be thinner than it appeared.
The specific failure mode I watched most often wasn’t an outage. It was the ordinary friction of a complex environment. Something unusual came up that required judgment, ownership, and a provider willing to stay with the problem. What the IT leader encountered instead was a structure in which accountability was distributed across enough organizational layers — a carrier, a reseller, a managed service intermediary, a national NOC — that it effectively belonged to no one. The structure didn’t produce a clear owner, and in its absence, resolution moved at the pace of the slowest handoff.
The compounding effect is what makes this pillar so costly over the life of a relationship. An IT leader who cannot fully rely on their provider’s accountability compensates by adding internal oversight, documentation, and time spent managing the relationship, rather than depending on the provider. That operational cost grows across the term of the contract, and it rarely appears in the original calculus that produced the vendor decision.
I joined DQE because it was built around all four of these reliability pillars from the start.
At DQE, we’re doubling down on reliability. Reliably Reliable™ means all four pillars, all the time. It’s a standard we hold ourselves to every day, across every dimension, for every customer. No exceptions.
For a deeper look at the full framework:
Nikki Marsh is the CRO of DQE Communications, where she oversees all revenue-generating functions, including sales, marketing, and customer service. DQE Communications, headquartered in Pittsburgh, Pennsylvania, is a fiber-optic Internet and data network access provider for businesses and carriers in Pennsylvania, West Virginia, and Ohio.
