Do unto others

- Collaboration is the grease that makes the gears of DevOps turn. - We talk about culture and sharing, but how do you make it happen? How can you build trust and respect and eliminate blame and hostility so that people feel safe to work together and to take chances to innovate? So first, not everyone has good social skills. Some people are introverts or have other challenges dealing with people. I personally went from painfully introverted as a young man to a belligerent engineer in my early career before I realized how important these skills are and I put some work into building them. Here's the set of books you might find helpful if you find it challenging to have friendly successful interactions with other people. - Beyond that, the single biggest impediment to trust in an organization boils down to misunderstanding due to lack of context or conflicting goals. It's very rare someone is acting out of malice. Most people are honestly trying to do a good job in the way that they think that is best given the constraints that they perceive - Someone else's job is always easier, isn't it? In my first job, after moving to Austin, I had a senior developer confront me as manager of the web operations team, frustrated that his project wasn't higher on our priority list. And he said, "I don't know why we need your team anyway, all you guys do is move files around." Of course, I had an overworked team of operations engineers doing software deployments, building new servers, handling a large load of on-call incidents and much more. While that developer could probably have benefited from a lesson in respectful language, a large part of their frustration came from just plain not knowing what the other team was doing. - One of the most effective DevOps techniques to combat this is to break down those team barriers and getting people from different specialties to work alongside each other. - I was working at a large SAS company in Austin, and we started our DevOps transition by first embedding one Ops engineer into a Dev team, working to roll out a new product. He joined the team full time, sat with them and all the operations tasks went to the same Jira backlog with the dev tasks. There was some initial sticker shock when the Devs saw the huge number of epics and stories, but as they dug into 'em, they realized that they were all critical items required for their new service to go live. They had no idea all the work that went into operational readiness for a production SAS service. The entire team pitched in and started pulling what were previously considered Ops tasks to unblock their release. And from that day on, the Ops engineer was one of them and they had nothing but respect for them and they increasingly shared work going forward. - [James] One specific problem I've also encountered as teams have been becoming more integrated is that there's a difference in language. Our different tribes within IT have developed different sub-cultures with different terminology, different ways of thinking about a problem. - That's right, in the first completely integrated DevOps team that both James and I worked on, we got complaints about our practice of having Devs and Ops present in our design review meetings. - Each group was asking questions of the other folks that we just didn't understand. - So I told them, look, we basically have two choices. We can pull apart and then continue to not understand each other's language or we can push through it and in a very short time we'll both learn and we kept at it. - Yeah, sure enough within two months, the problem was past and we adopted each other's language. - Well, that's great but you can't just put everyone on the same team. - Right. Optimal team size is pretty small given psychology research. So what else can you do? - Be open, be transparent, let people get context even if you're not personally there to give it to them. That means let them come into your chat rooms, see your team Wiki pages, see your code, your infrastructure, your monitoring tool, your ticket tracker. - You know the IT security world has done a pretty good job of teaching everyone about least privilege and separation of duties. Unfortunately, these terms often come out from a cargo cult justification for locking access way down past what any real world compliance requires. - Speaking of chat, one of the practices the teams have found to be especially empowering is called ChatOps, a term that the GitHub team coined. This is a shift to using your chat client, HipChat, Slack, IRC or similar not only as a gathering place for the team to discuss but as a part of your operational system. - Yeah, you can push notifications into chat from commits, builds, deployments along with your alerting system. With chatbots like Cuba, you can even issue commands from within your chat client to the rest of your tool-chain. - Then the built-in transparency of doing everything in chat rooms and the universal accessibility of chat clients promotes sharing. - [James] For more resources, check out the essay, Dev and Ops Collaboration and Cooperation by Paul Hammond and the O'Reilly Web Operations book. Also Effective Devops by Jennifer Davis and Katherine Daniels focuses on the collaboration and culture aspects of DevOps. - Remember, culture is the very first principle of DevOps and without building a culture of trust, you'll find that attempts to implement specific technical practices will go wrong, sabotaged either deliberately or inadvertently.