The following post originally appeared in Human Infrastructure Magazine, a weekly Packet Pushers newsletter on life in IT. You can get Human Infrastructure with a free subscription to Ignition.
Earlier this year, Ethan Banks and I were invited to speak to a tech vendor’s sales and product leaders on the topic of what network engineers want.
I spent some time thinking about it, and came up with five general “wants.”
I’m not a network engineer myself, but I’ve been reporting on, writing about, and analyzing the tech industry for two decades. I talk to network engineers and IT professionals on Slack, podcasts, social media, and at live events.
These “wants” come up over and over. I’m sure this isn’t a complete list, so let me know what else your technical hearts desire.
1. Engineers Want Good Software
Good software seems like it should be a given, but it’s probably the biggest complaint I hear.
By good software I mean code that is stable, reliable, and well-documented.
Yes, bugs are inevitable. Patches are a fact of life. Engineers get that. But I believe vendors will win customers if they deliver software that generally works out of the box, functions as advertised, and doesn’t require hours of keyboard pecking and Google searches to get it running.
Patches should be timely, tested against known operating conditions, and stable. Do the work on behalf of your customers to minimize the operational impact of patches.
2. Engineers Want Good Information
When engineers evaluate products for purchase, they need good information. That means enough technical detail to help them match a product and its capabilities to their requirements.
They need to clearly understand a product’s core features and functions, including what’s available in existing code and hardware, and what’s aspirational.
They need to understand a product’s capabilities and—this is important—its limits. If a product can’t do something, they need to know.
If a product does something in a way that’s non-standard or proprietary, they need to know.
They don’t need marketing language that’s larded with superlatives. They don’t need buzzwords that have become so stretched that they’re meaningless.
If you want to make engineers your friends, give them easy access to useful content. Don’t keep data sheets and product documentation behind reg walls. Don’t write whitepapers and corporate blogs that are thinly disguised marketing tools or sales fliers.
Don’t make cutesy videos that talk about digital transformation and the pressing need for operational velocity, but leave out key facts such as: Is your product software? Hardware? Where in the network is it deployed? What, besides enabling digital transformation, does the product actually do?
3. Engineers Want Reasonable Licensing
Allowing a customer to license your product shouldn’t require calculations that rival the complexity of artillery firing tables.
A tweet from Phil Gervasi sums up how painful licensing has become:
When people respond by asking how many punches and to what parts of the body, vendors should recognize that customers aren’t just dissatisfied with licensing schemes, they’re angry.
4. Engineers Want Good Value
Value doesn’t necessarily mean cheap. As Greg Ferro says, IT products are often “reassuringly expensive.” And if you’ve got a good product, it’s fine to charge real money for it.
Value means that your product addresses actual customer problems, or enables a measurable improvement to business operations, or materially addresses a critical risk.
Value means that your product works reliably. And when it doesn’t work, value means that your customers get good support the first time they make a phone call.
5. Engineers Want Good Visibility
“The network’s down.”
That sentence is the equivalent of a user dumping a haystack onto an engineer’s or admin’s desk and saying “I dropped my needle in there. Can you find it?”
What the user really means is “A thing that used to work isn’t working now. Please fix it.” But the scope of the problem is essentially boundless.
Oftentimes it’s not even the network. Maybe an application hung, or a process is slow. Maybe it’s a browser bug. Maybe the user ran afoul of a security policy.
That’s why visibility is essential. The faster you can surface up useful, contextual information to an engineer, the faster an engineer can identify and fix the problem.
Focus On Essentials
There’s a lot of intangible wants that I haven’t mentioned, like being able to leave the office at a reasonable hour, sleeping through the night, and enjoying the professional satisfaction of building and operating systems that help the organization and its employees succeed.
I think if vendors focused on the the essential requirements listed above, these other elements would fall into place.