Five questions every global network leader should ask now
- Ciaran Roche
Over the past few weeks, my co-founder Tim and I have written about the enterprise impact of the recently announced BT / Verizon joint venture. Tim explored what thirty years of telco partnerships tell us about strategy versus execution, and how the trends that led to this industry development were already well underway before it was announced. I examined the specifics of what actually changes (or doesn’t) in a partnership like this.
Up to now we’ve looked at the impact of this joint venture from the outside in. But if you’re a leader responsible for an enterprise’s global network – even if you’re not a client of one of these global providers – there’s a lot to consider right now.
Because underneath the provider consolidation story sits a shift that I’d argue is even more consequential. The role of the global network leader, whether that title is CIO, network manager, head of infrastructure, or network architect, is fundamentally changing. This has happened because the operational model, architecture, and even the actual purpose of the global enterprise networks have all changed already.
The teams who ran global MPLS networks a decade or more ago were really just managing circuits – in fact, network infrastructure continued to sit under “facilities” teams for a lot longer than many would expect, even in large organizations. The essential skills were carrier management, contract renegotiation, capacity planning and management, layer 3 routing design, and rigid, repeatable operational processes. Those skills haven’t become worthless in today’s environment, but they’re no longer the primary source of value in the role.
If I were leading a global network function today, here are the five questions that I’d be asking today to ensure the business is prepared for the future.
1. Are we measuring the actual experience of the business?
For decades, the network team’s entire focus was latency, packet loss, jitter, and circuit availability. Those metrics made a lot of sense in a private network where there was a high level of control over the path between the user and the application, because they were reasonable proxies for user experience – if any of these metrics deteriorated, you’d usually be hearing about it from users.
They aren’t the essential metrics anymore. A circuit can be “green” on every traditional metric while users in Indonesia struggle to load a critical SaaS application in the US because of DNS issues, congested peering points, or a problem inside the application provider’s own infrastructure. The reverse is also true: a link can show elevated packet loss while nobody notices, because modern networks using technologies like SD-WAN can mitigate even severe path-level issues.
The higher value deliverable is measuring the actual experience of users (in the office and remote) accessing the applications that matter most to the business, end to end, and being able to say with confidence where performance issues are occurring: the user’s environment, the local ISP, the middle mile, the SSE platform, or the application itself. That requires digital experience monitoring, synthetic tests, and application-level telemetry (if you can get it), and it requires the network team to define success or failure in terms the business recognizes. “SAP is running really slowly in our factories in Vietnam, and here’s why” is a much more valuable statement than “all circuits are performing within their SLA.”
2. Do we understand how our network fails now?
Global networks are now almost entirely dependent on the Internet: users reach applications over local broadband, 4G/5G mobile, and LEO satellite, and the applications themselves live in cloud infrastructure and SaaS platforms reached over the public Internet.
This changes failure patterns dramatically. Legacy networks failed in a fairly simple way – a circuit went down, a router failed, a telco had an outage on a specific backbone link. Today’s failures are more likely to be a loss of BGP peering between ISPs, a regional CDN or DNS issue, a subsea cable cut affecting a large part of the Internet, a major cloud provider incident, or a certificate expiry inside a security service. They’re difficult to pin down, intermittent, occur in ambiguous locations around the world, and very frequently exist outside anything you have an actual contract for.
Troubleshooting these requires a different skillset – understanding Internet routing and peering, reading traceroutes and BGP diagnostics critically, knowing how DNS and CDNs actually behave, and being able to correlate many signals across the network, security, and application layers. Very few teams that have years of experience operating with a single-carrier MPLS network have these skills in depth, and if your network is being managed by a carrier, they may not be any better. This is, in my experience, the single biggest capability gap in enterprise network teams right now, and it’s extremely difficult to hire for.
3. What is automation actually freeing our team to do?
SD-WAN and SASE platforms have automated a large share of what network engineers used to do by hand: policy changes, primary/backup link failover, per-application path selection, site activations, and many of the routine issues that occur on enterprise networks. Industry trends like AI-ops are extending that further, with platforms increasingly able to detect, diagnose, and in some cases remediate issues before a human even sees a ticket.
Some businesses have seen these data points and concluded that smaller teams can now “keep the lights on” thanks to all of this automation. This may be technically true, but the more useful question is what freed-up capacity gets spent on. In the strongest enterprise teams I’ve worked with, the answer is that engineers move up the stack into user experience management, automation development, security integration, genuinely useful internal dashboards and reporting, and working directly with application and business teams. In cases where this isn’t being done well, the answer is that the teams just get on with the same reactive work as before, but done more slowly.
This needs to be driven by IT leadership – it’s not a technology conversation or outcome. Automation creates the opportunity for more strategic work, but it’s on the business to fill this capacity with that strategic work. If you haven’t explicitly reviewed roles and objectives around the new operating model, the technology investment will only deliver a fraction of its potential.
4. Can our team work with data, APIs, and AI the way modern platforms demand?
The current generation of network and security platforms are software-based, with APIs at their core. The real value available to enterprises comes from integration – pulling telemetry into your own data platform, sending the right network events to ITSM tools and collaboration workflows, correlating network data with application performance alerts, and building the automations that suit your environment rather than waiting for a vendor’s off-the-shelf offerings to get there.
That means network teams increasingly need skills that used to belong elsewhere in IT: working with REST APIs, writing and maintaining scripts and connectors, handling structured data properly, and understanding enough about data pipelines to make this telemetry useful rather than collecting large amounts of data. AI raises this bar further. The teams that are getting real value from AI-assisted operations are the ones that already have clean, well-integrated data to use with these tools, and are applying real judgement to what comes back.
You don’t need a team of software developers in the enterprise network team, but you do need engineers who are comfortable treating the network as a programmable system rather than a set of appliances, and a hiring and development plan that reflects that. If your job descriptions for network roles haven’t changed in the last five years, they’re describing a job that’s far less relevant to today’s enterprise.
5. Are we ready for the network to matter more, not less?
This may be controversial. There’s a broad assumption that as networks become more automated and Internet-based, they also become less strategic. And many question the existence of the wide-area network itself in many cases, insisting that endpoint-centric solutions will dominate.
In practice, I see the opposite happening. Real-time collaboration is now the default way most organizations work, and it demands more from the network than traditional applications ever did. OT environments in manufacturing, natural resources, and logistics businesses are more connected outside the facility than they’ve ever been, which makes production facilities, mine sites, and warehouses directly dependent on network decisions. And expectations are elevated: availability and performance levels that were theoretical at best a decade ago are now simply assumed, regardless of where the user is – including locations where the underlying infrastructure makes that extremely challenging.
So, the stakes for IT leaders’ decisions are rising at exactly the moment the nature of the job is changing. That creates a big challenge, but also an opportunity. The leaders who can understand business outcomes and link that with network capabilities, who can walk into a conversation with the COO about plant uptime or with the CISO about converged IT/OT risk, are becoming much more valuable than before.
The role is being redefined, no matter what
Provider consolidation like the BT/Verizon venture will get lots of industry news headlines, and it deserves scrutiny. But whichever provider you end up using for your network and security environment, the bigger change is happening inside your own team: from managing circuits to being responsible for user experience, from reacting to failures to actually designing for the way networks fail now, from configuring network appliances to working with data, APIs, and AI as everyday tools.
None of these five questions has a straightforward answer for most organizations, and to an extent that’s the point. The teams that engage with them openly over the next couple of years will find the current disruption in the provider landscape is far less threatening than it looks, because their value will end up being independent of whatever technology or service the provider is offering.
