Sam Newman, from an excellent post about the absurd notion of "devops certification":
I do have some respect for some sorts of certification in IT, but very little of it. Cisco certification for example assesses individuals ability to understand, install, and maintain Cisco hardware. There are lots of clear yes or no type questions you can ask about setting up a router. If I want to install some Cisco networking equipment, I'm likely to look for someone who knows their stuff, and in the world of Cisco, that means I'm looking at their accreditation. But I see this in the same class as making sure the person who installs my gas boiler knows their stuff. In the UK for example their is a program to ensure that gas engineers are properly trained and do things right.
DevOps is about bringing people closer together. It's about breaking down silos, using different behaviors combined with the appropriate tooling to help bring focus on the end goal. It certainly has very little in common with installing networking equipment.
I agree regarding training/certification for very technically specific stuff like Cisco networking. Same deal for the old CNE/CNA cents back in the day, and, to a lesser degree, MCSE-type certifications.
However, the notion that someone is going to pat some money, go sit in a room for a few days, and come out with some methodology that will let her/him solve diverse organizational and architectural issues is patently absurd.
You want to "learn devops"? Spend 9-12 months working with a heterogenous group of architects, developers, and operations people. Dig into the guts of the software systems they build and support, and work hour by hour, day by day to get them talking to one another and working across traditional team boundaries to solve real business problems. Sound hard and painful? It is, and that is why so few organizations are actually doing it for real, and why devops certification is a stupid idea.
A bit farther on in his post, Newman briefly touches upon the notion that certifications "help companies feel that they have got their money's worth." That is almost certainly true, and while it is just as wrong-headed as the concept of methodological certifications, it is a problem that extends much more broadly.
Large companies have a tendency to believe they can hire expertise. Whether that expertise is represented by an impressive resume, or a laundry list of certifications, or a fancy and well known consultancy, or a big-name vendor of enterprise solutions, there is a persistent C-suite urge to hand over buckets of cash to an expert in hopes that s/he will magically solve the problem at hand. Hire senior technical candidates, because they will walk in the door with the knowledge and experience necessary to fix our stuff, this thinking goes. Wait for the slide deck from the consultants to tell us what our strategy should be. Buy the million-dollar black box and plug all of our apps into that.
That is not getting your money's worth, though. That is covering your ass. That person we hired sucked? But the resume was great–must have been a liar! That black box is just sitting in the data center, doing nothing but consuming power, cooling, and rackspace? Point to the SLA and blame the vendor! The strategy from the consultant turned out to be garbage? Send the lawyers to go through the statement-of-work!
This kind of stuff is appealing, however, because the alternative is really hard work. It is hard conversations and difficult decisions. It is working with people, getting them to understand the goals and finding out from them how to get there. It is hard to quantify, hard to measure, and hard to neatly summarize in a slide deck.