The word "teleconnections" refers to climate anomalies that are connected to each other across long distances, typically thousands of miles. Teleconnection patterns enable us to predict the weather, often several seasons in advance.
We picked TeleConnections as the title of this column because the notion of "connection at a distance" has several connotations beyond climate. First there's the physical concept that telecommunication is a form of teleconnection -- connecting things at a distance. But the "distance" involved may be conceptual as well as physical -- as in the sometimes-vast distance between how a CEO and a telecom engineer think. Teleconnection, in all its forms, is about bridging that distance.
One of the most surprising findings in the Nemertes Research 2014-2015 enterprise technology benchmark is the degree to which wide area networking purchasing decisions are made at senior levels -- sometimes extremely senior levels. Nearly 40% of decisions are made at the C-level -- and often that "C" stands for CEO or even chairman of the board.
Yes, you read that right: In many companies, wide area networking (WAN) purchasing is a board-level decision. "Maybe 1-2 times per year, I have something that goes to the board," an IT manager for a Fortune 500 transportation company tells me.
It's not just traditional, conservative companies that have board-level reviews of network decisions. Our research shows that companies with an aggressive stance toward technology in business -- the ones that are most likely to view IT as a competitive differentiator and act 24-36 months ahead on the deployment curve -- are more likely to require high-level approval for their WANs.
That means network engineers -- and network professionals in general -- need to get better about conveying the value of complex technology in business terms.
Try this thought experiment: Let's say you're a network engineer at a large telecom company that's investing in a network functions virtualization strategy. How do you explain why this is a good thing for your customers' businesses?
Or you're an engineer at a large enterprise looking to put software-defined networking (SDN) in place. How do you articulate the value and benefit of that technology?
It helps to take a few steps back and remember two things. First is that business people are usually deeply technology-agnostic. Unlike engineers, they're unlikely to have impassioned opinions on which technical features are "better" or "worse." What they do care about is how those technical features translate to business value.
Or, as my CFO once memorably told me when I was a CTO, "Don't tell me what the freaking network will do, Johna. Tell me what it will do for me." (That's not precisely what he said, but you get the idea.)
The most important words in that statement are "for me." My CFO wanted to know how it was going to improve his bottom line -- because that's what CFOs do. Similarly, CEOs (and board members, generally) want to understand how technology can deliver a competitive advantage. And so on.
Network professionals need to tailor the message to the business person who's hearing it. So for instance, a CFO might want to hear benefits articulated in accounting terms: New dollars (revenue created as a result of deploying this technology) or saved dollars (reductions in present or future capital or operational costs).
A risk manager might be interested in what I like to call "forced dollars" -- demonstrating that a particular technology better enables compliance with a regulatory constraint.
And the CEO might want to hear how a technology can future proof the investment---protect against a future forklift upgrade a year or two down the line, or if business strategy changes.
Thanks to their technical backgrounds, CIOs are typically pretty good at going one or two levels deeper. In a recent conversation with the CIO of a Fortune 200 manufacturing company, I summarized the benefits of SDN as "increased agility." "I get that," he said promptly. That didn't surprise me at all, since he's leading a multi-year effort to make his shared-services technology organization measurably more responsive.
The challenge is that many network professionals -- like engineers everywhere -- tend to have internalized certain design principles so deeply that we have trouble articulating them. It's a given that a new design should be cleaner, more scalable, more efficient and faster than an older one because, well, that's just better.
How to craft a business-case document
Podcast: Justiying the need for WAN optimization to the CIO
Why business continuity is a board-room issue
Positioning the big data business case