Let’s not be ‘that’ guy. And let’s not be ‘that’ organization.
You know, the one where “DevOps” is some magic pixie dust that we can sprinkle around, and then pat ourselves on the back for being forward-thinking, modern IT managers. It’s actually harder than that. Harder but simpler. Harder because DevOps involves humans. Simpler because pixie dust doesn’t actually exist. (I prefer software instead.)
There is thankfully a lot of good “devops” software out there. We are pretty proud of ours too but we fully admit that paying closer attention to human factors of DevOps helps ensure that you get the most from your software whether you buy it or build it.
Respect
Any “DevOps” organization worthy of that title needs respect and understanding between Dev and Ops. Each brings their own talents, mindsets and constraints. Those other guys generally aren’t trying to make your life difficult just because they can, or because they don’t care. They are making your life difficult because they may not fully understand your environment, your pressures, your management and even the metrics that define ‘your side’. Or maybe they have pressures and constraints of their own. This isn’t a matter of touchy-feely kumbaya. Getting to know and respect each other is actually just good business.
Communication
A DevOps organization should also have good communication. Note that I didn’t say lengthy communication or countless tedious meetings. Just good communication. I also didn’t specify whether that should be verbal or written. It just needs to be good and it needs to fit your organization and your environment. Whether you are a multi-national organization with datacenters across the globe or if your entire IT department can fit in one room,
- Focus on sharing what is important for your colleagues to get their jobs done.
- Make clear what you need or what you need to know from them so that you can do your job well.
- Don’t hide that key nugget or even that bit of bad news under mountains of data. Over-sharing is as destructive as withholding key info.
- Say ‘thanks’, ‘good job’ and ‘sorry’ every now and then to your colleagues in Dev/Ops.
Process
A) People learn by doing, more than being talked at. B) What gets measured, gets done. So find something that works for your organization and your culture to nudge the DevOps mindset that you are seeking. Maybe it’s a job rotation program (even for a couple of hours per week). Maybe it’s paid company lunches. Or working in the same physical area. Perhaps it’s having Dev report on traditional Ops metrics and vice versa. Or maybe it’s sharing the risk and rewards of holding Dev and Ops accountable for combined DevOps metrics. The point is to foster team performance in a we’re-in-this-together mindset.
DOINO
The bad news is that #DOINO (DevOps-in-name-only) is worse than useless. DOINO can cheapen and make a joke of a pretty good concept that should be helping IT teams accomplish more and enjoy their jobs while doing so.
The good news is that you don’t have to be perfect at all of the human factors of DevOps to make real progress. Your improvements may be sparked by formal cross-functional meetings, informal sharing of more beers or even (my favorite) by clever new software that automates the hell out of tasks you had previously taken for granted. The important thing is to just get started.
