There are some typical attitudes that emerge among devops engineers in many organizations. Partly, it is as a result of dealing with a lot of clueless employees. And, partly, because they seem to think they are the most important group in the whole organization so develop an air of superiority while giving other business groups an impression that everything is way too complicated for people to understand. Let's face it devops is not exactly rocket science. It is a merge of two interdependent functions - development and operations. The following are some typical examples of what happens when people in the workplace interact with devops.
- They make changes without informing others, and without providing sufficient advanced notification of a planned outage
- They will tell you something is too complicated, when it's a simple case of drag/drop or window click
- They will over-exaggerate on the time it will take them to get something done
- They will rarely get it done within the agreed timescales but expect unforeseen/unplanned delays
- They will expect you to log a ticket for everything even if logging a ticket takes more time than to do the work
- They will reject everything you say, then they will say exactly what you had said as if to make out what they said was quite deep
- They will use methods and tools only they can understand and with little to no shared documentation
- They will reject the way you had done something, then approach it exactly the same way
- They will look down at you for everything even while sitting in a meeting, explaining anything is complete chore for them, but they will expect you to have the highest level of communication skills and patience with them
- When you explain something simple to them expect to explain it in french, english, swahili, plenty of other languages, and still expect them to not understand any of it, even while everyone else in room likely understood it in full
- Sometimes your login accesses might be randomly revoked and then randomly start working again, this isn't magic but the devops are likely doing their usual unplanned maintenance or config changes
- When you can't ssh into a server because the devops have randomly destroyed your instance, during their regular cleanup sessions, and you have to start all over again with your work
- When they never acknowledge their mistakes that lead to critical outage issues in production
- When the wrong model or code is deployed into production
- Using too many rigid processes and creating barriers between themselves and the user
- Using metaphors of oversimplification
- Not understanding the value of automation
- Poor methods for testing what they deliver to business
- Lack of a formal architecture evaluation
- Badly managed incident management
- Lack of discipline for conducting effective, sensible, and responsive postmortem evaluations
- Misuse of metrics that don't display the full picture and cost businesses
- They will tell you it will take at least a month to spin up and setup instances in cloud when it should probably only take them less them 2 minutes to maybe 2 days if they need to cluster and setup security groups
- They will block you from doing anything yourself, or even to assist them to speed things up
- Each member in a devops team almost works like in a silo of their own bubble of ego
- Expect them never to be available when you have an outage situation so they can feel an air of importance
