The Cranky Admin
The Importance of Getting the Name Right
Extracting signal from noise in the IT marketing world.
I've had the opportunity to see how the tech marketing sausage is made. This has not lessened my astonishment at how products and services which will impact the lives of billions of individuals succeed and fail based on nothing more than word choice in a phone conference at stupid o'clock in the morning.
To understand this fixation on vocabulary use, one needs to understand that I have arrived at a point in my career where it's difficult to define what exactly it is that I do. I don't put enough hours into systems administration in a week for the hard-core systems administrators to consider me one of them. I don't do enough analysis or report on enough new technologies for journalists to claim me as one of their own. I don't engage in economies of fact enough for marketers to truly see me as one of theirs.
I read. My job is to learn as much as possible about as many different aspects of IT as possible, and then report on what I find. Perhaps the closest approximation of my job would be that of a professional student.
The part of this I do for paying customers is about helping them explain what they do to others. What makes sense in the engineer/CEO's mind doesn't necessarily translate to the sysadmins, IT decision-makers, and others that they hope will be cutting the checks.
What a Difference a Word Makes
When I talk about a single word potentially deciding the outcome of a product, I don't mean the product or company name. I'm talking about the choices made in how to describe the functioning of a product. These choices aren't irrelevant marketing fluff. They affect IT practitioners, and the companies where they work, in real ways.
Let's look at a practical example. One of the customers I'm working with today is an early-stage startup named ioFABRIC. They make software that allows you to combine all your storage into a single fabric. SAN, NAS, public cloud, Direct Attached: all of it can be added to the fabric. You can then export it as whatever kind of storage you happen to need.
Sounds simple enough, if you already know what a storage fabric is. Trying to explain it to systems administrators who have never encountered fabrics anywhere else in their datacenters proved difficult.
The choice of a single word made all the difference.
If I say that an administrator "assigns" storage from a device to the fabric, this carries certain connotations. Storage "assignment" sounds permanent. It has a certain bureaucratic connotation that implies administrative overhead and intervention that aren't required in this case. "Assigning" storage sounds complicated, and like it requires planning.
If I describe ioFABRIC's solution by saying devices which are part of the fabric may "donate" whatever storage they have available, everything changes about the perception of how this works. There is an impression of a much more ad-hoc arrangement, where storage can be "donated" or not as requirements dictate, and the "donation" is as long term or temporary as necessary. It also sounds more automated.
This reflects the actual product a little better, as the product handles the addition of storage in a more dynamic fashion than the term "assigned" implies. One word -- "assigned" vs. "donated" -- makes a notable difference in the basic understanding of how fabrics are constructed and how they're applied by products in the real world.
This is a small example, but one in which I personally tried a number of different terms to explain the concept to different systems administrators. I've watched this same linguistic selection process occur innumerable times as a systems administrator, journalist, and grumpy man who yells at marketing people.
Throwing Word Spaghetti At the Wall
Very few who are engaged in selecting the vocabulary of product description seem to understand the implications of their choices. Seemingly random trial and error is used until something catches and the product is understood. Or not.
Lack of understanding is a greater barrier to adoption than the suitability of the technology. A number of individuals in my life -- many of whom are competent, educated professionals -- come to me on a regular basis with a Web site from some vendor, asking, "Trevor, what exactly do these people do?" I've spent five years of my life professionally learning to penetrate the Escherian maze of the technology marketer's mind, and even I can only explain about 60 percent of the incomprehensible bafflegab that makes up most companies' Web sites.
All of this was fine 15 years ago. Back then, there were only really a dozen or so vendors that actually mattered. We only had a couple dozen or maybe a few hundred applications under management. If understanding a new one was a pain, it wasn't an insurmountable barrier, just an inconvenience.
We live today in the world of virtualization and clouds. Marketplaces make adding new applications push-button simple. Clouds mean any user with a credit card can increase the number of applications that an IT team has to figure out without even having to tell IT about it. Virtualization made it possible for the number of apps under management to balloon. Clouds make it possible for that number to explode.
Somewhere in all of this IT practitioners have to figure out what all of this crap supposedly does. The responsibility for that rests with the technical marketers employed by the various vendors, but the burden of letting those individuals know when they have failed to adequately communicate rests with us.
It's important to remember that many of the people charged with making the decisions about how to communicate a product's function have no idea what it does or how it works. They are simply trying to take the bunch of big words that some engineer mumbled at them in a meeting and turn them into smaller words that they think will appeal to people with budget.
Stop Not Making Sense
You do not betray ignorance by challenging the description of a product. Instead, you are demonstrating that the vendor has inadequately communicated that product to an audience (you) that they have targeted. This is important because the number of vendors and certainly the number of IT products is not going to go down. If we want to be able to extract signal from noise, we need to be willing to stand up to vendors and say, "This makes no sense at all." If we don't, everybody loses. Excellent, even revolutionary products fail because describing how they work proves too great a burden.
If insisting on clarity is important today, imagine the importance five years from now, when as-a-Service solutions have consumed even more of our IT footprint, and interoperation between business-critical systems relies on applications we don't control whose APIs can change at a vendor's whim. Imagine that their integration with other mission-critical systems relies on increasingly esoteric and niche terminology to which we may not have been exposed.
The more vendors, the more niches. The more niches, the more jargon. The more jargon, the harder it is for any of us to really understand how it fits together. Collectively, all of us need to put me out of a job. What I do -- telling people, for money, that they make no sense -- shouldn't be something you can get paid for.
About the Author
Trevor Pott is a full-time nerd from Edmonton, Alberta, Canada. He splits his time between systems administration, technology writing, and consulting. As a consultant he helps Silicon Valley startups better understand systems administrators and how to sell to them.