If you’re a SolarWinds customer, there’s a good chance you’ve seen a video of a Head Geek, passionately urging you to upgrade to the latest and greatest version Right Now. And that Head Geek is likely me. If the speaker has TV anchor hair and boundless upgrade enthusiasm, it’s almost certainly me. In dozens of videos, blogs, and tens of thousands of customer emails, it’s both a privilege and a calling to help with how-to advice and insider tips and tricks. What may be a surprise, is this hasn’t been an assignment.
It’s a labor of love, a volunteered, personal mission to cheer IT pros on to upgrade their tools. But why? Why would anyone be so committed to what should be a routine, ideally mundane maintenance task? The answer is simple. Upgrading vendor software—any vendor’s software—is among the most cost-effective, and quality-of-life-enhancing IT activities.
In 14 years, I’ve installed or upgraded the SolarWinds Orion Platform over 300 times. A lot of that was during a stint as the SRE of the online demo systems. Even now, two-thirds are beta and release candidate test installs. If there’s a way to break an environment, I’ve done it in the pursuit of having the latest functionality, performance, and security enhancements the same day golden bits hit the wire. Some of my eagerness also stems from hundreds of other enterprise application upgrades over my technology career. Some were piece-of-cake easy, but others more involved.
More than that, my team has unique opportunities to speak with hundreds IT pros one-on-one, especially about what can get in the way of software upgrades. It’s easy to say, “just upgrade,” and five-nines percent of operations engineers agree, “Yes, upgrades are critical!” But for teams supporting multiple vendors’ packaged applications and monitoring tools, keeping applications current isn’t always “just an upgrade.” Keeping SQL Server or MongoDB up to date isn’t the same as updating Notepad++. Actually, on second thought, that’s a pretty good analogy.
With Notepad++, upgrades are a no-brainer, which is good because it has almost as many upgrade releases as Java. No, that’s a Good Thing. I’m a fan! Users frequently see fixes and features they’ve been waiting for and the upgrade requires only seconds. It’s also a tool which prompts for updates on launch by default. (That’s great for desktop tools but considered bad form for enterprise apps.) As a result, Notepad++ users don’t miss many updates and they remain current or very close to it. It’s an easy decision in the moment to click “OK” and our gut tells us it’s a worthwhile interruption in our days. So why can it seem anything more involved can encounter stiff headwinds?
The answer may be as simple. IT teams aren’t encouraged to use the same cost-benefit analysis techniques for internal tools as they do for major projects driven externally. It’s like anything in infrastructure where IT is the primary customer. Surely their tools must run on magic pixie dust, requiring not a single dash of limited resources. IT pros know well this isn’t true—they’re the limited resources which must always defer the needs of the border business first. That’s where the Value-Effort chart comes in. More often than not, the compelling value of upgrades usually can become lost in the “maybes.” I may have drawn this on a whiteboard a time or two.
Let’s start with the two obvious quadrants, “No” and “Yes.” When you consider upgrading anything more powerful than a desktop tool, “No,” or at least “Not right now” is a common, reactive option. Without a compelling reason, immediate and visible benefit, or if upgrading requires even a brief maintenance window to complete, not upgrading to every release may be a reasonable choice. The “No” quadrant also becomes more tempting as criticality and footprint increase. That’s a normal human tendency. <cough cough> Windows Server 2008 </cough cough>.
On the other hand, the “Yes” quadrant for upgrades is usually pretty clear in one of two ways. First, there may be an unplanned, high-priority upgrade required. Sometimes it’s a bug or performance fix with clear, direct benefits to the team using the app. Other times it might be related to compatibility or security. In either case, it’s easy to make the case for temporarily assigning admin cycles to perform and verify the fix, even if at a sub-optimal time.
Where IT pros tend to end up with more missing tool capabilities and frustrating days at the office, however, isn’t in “No” or “Yes” analysis. Ops teams do that for breakfast. Where teams find upgrade value tantalizingly close but not quite justified, is in the “Maybe” quadrants where value and effort are less directly proportionate.
Efficient prioritization requires objective data. ROI is the canonical example. For a given spend, an organization can realistically expect a given transformation, quantifiable by post-investment performance monitoring. For upgrades, your team may know exactly how much benefit they’ll see from a scalability or feature enhancement. If you can’t express that benefit in clear, ROI-like terms, however, upgrades can seem gravitationally attracted to the “Maybe,” “Possibly,” or “Eventually when there’s time” zones.
Other upgrade efforts can fall victim to the siloed team “Maybe” zone, where one team depends on common platforms or services from another. External teams have their own “the carpenter's house always needs work” resource challenges, requiring approved exceptions to prioritize external work. They may have time for a favor, but if they cannot commit to a timeline, pushback will save the requestor trouble in the long run, however frustrating.
This is when breaking out Excel—the unsung bedrock of all IT projects—can justify beneficial upgrades to the broader team. For greatest benefit, you’ll need three elements: first, you need a champion for the effort, a peer to external project leads you’re competing against for resources. Like it or not, advocacy, or even a bit of politics may be required, so partner with someone who gets projects approved. Second, you’ll need to do some research into the candidate upgrade. For new applications, it’s usually easy because the initial feature sets are limited. V2 is always something to get excited about.
Discovery can require a bit more time however for very mature tools. It’s not uncommon for IT pros to use only a fraction of potentially thousands of application features, many of which could even have been hiding in plain sight under a menu for years. With each release, that number can grow further. Managers tend to be the first to make the case for unused feature R&D because they have more time to think about the tools on which the team relies. They’re also are more likely to follow financial curiosity to uncover unused value. They sit between the IT pro users and the budget which supports them, after all. Pique their curiosity about what they’re missing.
Last, well, last is math, or at least what passes for math in Excel spreadsheets. Here you’ll need to track how long your team spends manually maintaining tools, building custom solutions or manually performing tasks that may be fully automated in a current release of a tool. Fortunately, decent estimates are usually enough to remind an approver of lost opportunity. They probably already know and will appreciate all supporting data. With that in hand. comparing ongoing productivity loss vs. resource investment is easier. The upgrade value-effort quadrants of “Maybe” unknowns shrink. Armed with a simple chart which speaks to anyone, you’re generally more likely to push overdue upgrade and maintenance tasks into the wonderful quadrant of “Yes!”
I remain an enthusiastic champion of upgrades, especially for mission-critical applications and management platforms. In general, almost all software improves with each upgrade, and continuous improvement is the key to every technical endeavor. That’s nowhere truer than in IT. The critical services we provide to the business can only be as up to date as the tools IT owns and the skills of the engineers who rely on them. Yes, it can be a pain to stop what we’re doing and upgrade. Yes, it can take so additional cycles atop that to get approvals. In years of conversations with IT pros, however, I’ve almost never met another IT pro who wasn’t happier or even relieved after an important upgrade.
So, when you see me excitedly waving my arms around in a SolarWinds Lab “mega” features episode, or in upgrade how-tos with other Head Geeks and product gurus, this is why I’m so passionate about upgrades. I’ve seen firsthand how valuable upgrade efforts can be for many vendors’ applications and thousands of internal IT users. It might simply be due to the justification process which discovers tranches of undiscovered features team members could begin using even without the upgrade.
I’m just here to get you over the hump to value, when other forces sometimes push back. Even that more buttoned-up time I might have used a teleprompter.