When DevOps was coined by Andrew Shafer and Patrick Debois, the goal was to bring developers and operators closer to achieve customer value together. DevOps is a culture of continuous learning and improvement. While automation and tools can garner some improvements, having the right culture drives larger impacts. The sharing of knowledge and ideas resulting in cultural growth is the value creator in DevOps.
The great dev and ops divide
In many companies, developers and operators are in separate organizational structures and follow different processes. Often the CEO is the first common link in the chain of command. This results in the two groups having different goals. Developers want to create more features for customers, and operators want to keep the existing features usable. This tension makes a healthy partnership between development and operations very unlikely.
Traditionally, a developer might never know that a memory leak they introduced is causing a weekly restart of their service. Or an operator may not know that their operating system patch and restart process has resulted in significant feature degradation. And combined, they have pushed prospective customers into choosing competitors. When developers and operators use the same processes and toolsets, they are able to collaborate and learn from each other.
Development can then introduce concepts like agile and scrum to the operations disciplines to speed delivery of those components of the product. And operators can introduce the complexities of their domains that require so much discipline. This newfound understanding between the two groups enables tremendous growth opportunities.
Empathy leads to understanding
This learning and collaboration process breeds empathy between the groups. Empathy bolsters understanding and can even lead to more predictive behavior. Developers can now predict how their decisions will affect operators. Instead of a developer needing to consult with operations for every decision, they'll be able to make better decisions based on their increased context of the system. However, the production of customer value is broader than just these two groups in an organization.
When you think about the structure of a DevOps team, of course you start with developers and operators. But there are other roles to consider, such as business analyst, that are just as important to the success of your DevOps team.
Business analysts and other business-related roles should be involved in the development process. This is likely where a lot of the requirements will come from, and these individuals will understand them in depth. It is really hard to write something down in a ticket and guarantee it's interpreted exactly as it was meant. Having the business team involved on a daily basis will reduce rework and missed deadlines.
Strategic alliances for your DevOps culture
What about the rest of the company, the functions that haven't been covered so far? Many times, these teams are seen as blockers or as rubber stampers, and any interaction is pushed off to the last minute. These groups should instead be engaged first, because they often have a lot of say in making decisions. Sales, marketing, security, finance, legal, and human resources can change from blockers and rubber stampers to champions and strategic partners. Let's examine what that looks like.
Sales
The sales team should be included as part of your DevOps culture. It's likely that they are also producing requirements, and they probably have the best connection with customers and what they really value. They will be able to provide a tremendous connection to the customer in order to build customer empathy throughout the team. An even more effective approach at building customer empathy and understanding is to have sales take individuals from the team to visit with customers.
Marketing
Marketing sells your ideas. Finding a good designer and partner in marketing is critical. Even if you don't think you're marketing something, you are. We all are. Every day. I may think I can market my ideas really well, but the marketing team is the group that does it every day—and gets paid for it. They know what they're doing. I have often taken presentations, architectural diagrams, articles, ideas, and campaigns to them, so they can help me make a bigger impact. Marketing is a force multiplier.
Security
Security is often a separate entity in many companies. It's important to note that in a DevOps culture, security is also a primary concern of both developers and operators and isn't left to a central team to fix after everything has been deployed. However, a central function of security setting reasonable policies, auditing those policies, and establishing some best practices and tooling is very valuable. It's important to engage security early so they can help you succeed rather than be forced to tell you your code can't be deployed to production. They are really left with no other choice.
Finance
Finance can completely stop your entire initiative by not approving a critical procurement because it could negatively affect the businesses in ways you didn't understand with your available context. It is essential to include them in negotiations as early as possible. I've found that they often have horrible tooling, and helping them with a little automation can pay huge dividends.
Legal
Legal can delay your entire initiative literally for months when contracts and licenses aren't provided early enough for their review. I have a side passion for law that leads me to read thousands of pages of laws and court opinions, so I probably enjoy talking to legal a little more than most.
This is one of the first groups I reach out to with any new initiative, because they will need to understand what you're doing and why. This will help them determine where there is risk to the company and how to defend against it. For example, implementing a bring-your-own-device (BYOD) policy or using Slack as a primary communication tool require understanding more context than I have available. I also help them with license reviews by working with them to create a list of always-approved licenses and never-approved licenses. This reduces their review process by more than 50%, in my experience.
Human resources
HR normally can't stop a specific initiative, but they have a huge influence on hiring, which ultimately influences the company culture. GitLab has one of the best cultures I've ever witnessed. You can find GitLab's HR docs on the internet and even submit a merge request with a proposed change. Everyone there uses GitLab, including HR, but that's probably a lofty goal for most organizations. Small steps in that direction include partnering with the internal recruiters by making sure they know what you're looking for as far as culture fit, helping them automate time-consuming tasks, and bringing them in early by giving them ownership of parts of the culture.
One team, one goal: Customer value
These other areas of the company, which aren't as closely related to product development, generally will be more risk averse, so patience and education are key. They have the same goal you have—to produce the most value for customers as possible—so don't fight them or make enemies. Give these roles the opportunity, and they will impress you with their ingenuity and drive.
2 Comments