This article is more than 1 year old
How to avoid getting hoodwinked by a DevOps hustler
If they’re a 'DevOps Expert', they probably aren’t
Comment We’re almost halfway through this year, and how’s progress on those Digital Transformation Initiative slides doing? Maybe you need a quick jump in improvement to buy some time for August vacations, and then ensure you can get enough actual change and a few successful projects in place by the holidays.
While they’ll ship themselves to your door, those gifts aren’t going to buy themselves. At this point, finding an outside expert to push your jalopy-cruiser’s KPI gauges up is a common tactic. And why not? It might actually work, and if it doesn’t, you can always whip out your blame-storming finger to buy time while you look for a new job.
'What’s this thing on my wrist, then?'
The larger the organization, the less likely management will have the skills to look at their own watch to tell the time accurately. That is, they’ll need to hire some outside consultants to help shuffle the organization along to the golden path of DevOps. Traditional-minded watch-reading assistants have been biffing it of late, with well over 70 per cent of senior management registering dissatisfaction with traditional consultants in a recent survey. You’re going need some sluice-fiddling to find the good change consultants. Provenance
As any angler will tell you, going to where the fish actually are is a key step in catching one. Where should you find these experts, then?
“Here's a hint... strong DevOps consultants don't come from vendors,” said Matt Walburn late of Target’s DevOps team and now at Amazon. Now, now: if I may be biased a bit, perhaps a vendor will hire such people to staff a practice, but, sure, that heuristic will serve well more frequently than not."
Put another way, you’d like to find someone who’s Done This Before. Without getting too far into a phrenologic alphabet soup, you want people who have experience both with the technology and the meatware.
Walburn characterizes a good pedigree thus: “A strong background in not only the technical and tooling side of DevOps, but also in driving enterprise-wide people and process changes.” For example, a passing familiarity with the woes of DNS and Westrum-type spotting are good signs.
Judge a person by how they’ve failed in the past
Many can claim to have such a broad skill-set, but they must be vetted somehow. Sniffing out a track record should primarily be driven by word-of-mouth and talking with past clients. When asked for a lengthy list of referrals, if a prospective consultant pleads that their past dance partners are unwilling to talk, be immediately suspicious. Any organization that’s successfully changed is tripping over itself to tell others how awesome it went.
As a bonus qualifier, ensure that the referrals tell you plenty of stories of woe: no mercenary time-teller is without defeats and warts. A referral is likely being overly glowy (read: dishonest or just indolent) if they don’t tell you what went wrong.
And, ever looking for adding more heft to any blamestorming that must happen post bed-soiling down-the-line, building up a good list of credible people who said it was a good idea is fine defence. Well documented due diligence is a solid parachute.
Anyone can make pretty slides
It’ll be tempting to qualify consultants by the beauty of their conference talks and, of course, written material (yes, dear readers, the ragged irony-crow sitting here my shoulder doesn’t escape me). It’s easy to fall into a Socratic trap of dismissing good rhetoric: just because one can speak pretty doesn’t mean they’re wrong. However, short-listing consultants based on their conference performances and spoken work takes some skill. As a general rule, you should differentiate between successful self-promotion and actual DevOps community appreciation, and, this, accreditation.
When asked for a lengthy list of referrals, if a prospective consultant pleads that their past dance partners are unwilling to talk, be immediately suspicious.
“If someone is considered expert by people other than themselves, they typically show up in more places than their own self-promotional efforts,” says Bridget Kromhout, head of the global devopsdays organization and suffer of reviewing many conference talk submissions. So, if all you see is a series of lambo videos, Twitter verified badges, and sponsored keynote talks at conferences suffixed with the word “Expo,” be suspect.
Every good consultant knows that a book is a deft calling card. When you’re using the bookshelf as a selector, ask yourself if the tome contains tactics you can actually put in practice, rather than just Sunday morning bromides. For example, Gary Gruver’s books practically order you to put continuous integration in place, first thing. Other books, which shall go unnamed, spend much time painting the corporate inferno and telling you just about the end-state of bliss, but little on how to actually get from the path of sin to the blessed elevator. You want stories of suffering, and how the expert fixed it.
Once hired, you’ll need to measure these consultants to make sure they’re actually doing their job and worth their salt. This is Devilish, as with all measurements involving meat-sacks that haven’t been yet replaced by robots. How would you attribute causal success to the consultant rather than the organization... or apocalyptic failure when it was actually that a bad plate of oysters your sysadmin had the night before that $440m bash-script error? If success has many fathers, failure kills all fathers involved.
The easiest way to track a consultant's progress is to ask the teams they work with if they’ve been helpful. If you don’t mind long-term studies, you can track things like total number of teams that have run through the consultants fingers, crossed with those teams new-found abilities to release software more frequently with fewer bugs. But, will the consultant even be there long-enough for that?
Of course, you’d like to also account for the consultant’s contribution to the success of the business that’s driving all this change in IT. That can be dicey, however, if you’re not honest with your assessment. Numerous consultants I’ve shared noon cocktails with as we Quincy, M.E. their client’s train-wrecks have built compelling cases of organizations that eat themselves to failure despite all that good counsel.
To rate a consultant, you must clearly define the job you wanted them to do and the blast radius of success you allow them. This of course, requires knowing what your own goals and metrics are, dare I say it, what strategy your business is pursuing and how it’ll know when it’s failed and succeeded. And who among us, after all, has the time to figure that out?
Better to hire a consultant to come up with your strategy. ®