Unfortunately, while the assertion is probably true to not talk about jargon, there needs to be a starting point of conversation somewhere. Here, it's probably

Unfortunately, while the assertion is probably true to not talk about jargon, there needs to be a starting point of conversation somewhere. Here, it's probably easier to define what devops definitely isn't and cut away irrelevant things than by talking about what anyone's jargon defines it as. This is similar to the whole "cloud" definition but only even more vague than that. Be very wary of anyone that has trouble distinguishing "devops" from system administration with modernized toolsets, especially if they aren't talking about deploying in-house software. Those are the kinds of organizations that are so far behind technology curves they'll drag you down as a vendor, contractor, or employee trying to support them if you don't hold them at arm's length. Because if you're not competent at basic system administration, I doubt spending money on any form of "devops" by any definition will be useful - think of the "you must be this tall to use microservices" concept. The worst is if there's something about culture that's the fundamental goal, the larger the company the more clients seem interested in essentially under-market-rate management consulting by using engineers than MBAs. These also tend to be the same companies that seem to incessantly talk about "it's hard to turn around an aircraft carrier" and have probably discouraged and disengaged employees enough that any form of bottom-up culture change is hampered before it can take off.