Despite being debated for quite some time, there is still no perfect definition of DevOps. But for me, it’s about the people building the software and how they work together. DevOps can be a transformative practice for businesses of all sizes and types. Companies in almost every industry are using DevOps to provide teams with the time and space to tackle more challenging projects.
The toolchain is also important - without the right tools, DevOps can be difficult to implement. I like to think of tooling as the foundations of a house that you can then build upon. Only once organizations have the right tools, can you create a culture that will lead to success.
Effective DevOps has huge benefits. For organizations, it increases software quality and stability, and shortens lead times to production. For developer teams, it focuses on both automation and culture. Both of these play an important role in how the work is executed. But most importantly, DevOps is about enabling people to collaborate across roles to deliver value to end users quickly, safely, and reliably. It’s a recipe of focus, means, and expected results.
When you make that ideological leap, the principles for creating and organizing effective DevOps teams become clearer. Here are my top tips:
Create an environment of trust
A foundation of trust, empathy, and psychological safety is critical to organizing a successful DevOps team. I cannot stress this point enough. Collaborative culture will only be fostered if there is “trust by default”. In this environment, rather than requiring people to earn it first, team members are trusted automatically. However, in turn staff need to prove longer term that this trust is warranted.
An organization in which employees actively look for ways to support and help one another throughout the software and product development life cycles is an organization built on collaboration. Without psychological safety, people won’t put their head above the parapet and ask the important questions that are critical to ensuring that goals and objectives are met. It’s vital that everyone has the opportunity to share their thoughts about decisions.
Trust leads to better communication - and this, as I will explain, is everything.
Collaboration between product and engineering
I like to think of the product and engineering teams as siblings. Despite wanting what’s best for each other, they often conflict and don’t see eye-to-eye. In my experience this is fairly common but can have a negative drag on the performance of the whole DevOps team.
A very simple way to foster more collaboration between these two teams is for the two departments to share tools. For example, if a product team uses Jira and engineers track work in GitHub projects, providing both teams with access to all tools will undoubtedly cut down on the risk that materials will be “hidden” from each other. Integrations between the different tools being used, or the standardization on a single tool that meets both teams’ needs, can further aid the interoperability of both teams.
That said, every organization is different and sharing tools might not always be feasible. If sharing tools is not an option then it’s all the more important to ensure that there is transparency and empathy by providing sufficient training for both sets of teams.
Communication, communication, communication
Successful DevOps approaches tend to have something in common: clear communication between and within teams. This is particularly the case for engineering and product teams. Representatives from engineering should have invites to regular product planning meetings, and a product representative should have invites to engineering status updates.
These should not be tokenistic gestures but important practical meetings to ensuring the two parties are on the same page. The benefit of having a dedicated expert embedded in each team is undermined if the role is treated as a funnel for automation work.
In the same vein, those that are responsible for execution on the team, should be an integral part of the planning process too. They can add value when defining schedules, timelines and deliverables. Product teams will have the information that’s important to understand the customers’ needs.
If the wider team is not involved in creating, stress-testing and having final approval on product plans, it greatly increases the risk that nasty surprises will be lurking for the rest of the team. It’s the uncertainty and unnecessary pressure on deadlines that can cause the relationships between product and engineering teams to break down/ when impossible deadlines are missed.
Dedicated DevOps team for the company
Similar to the above, not only should the teams keep channels of communication open between themselves but it’s important they act as a conduit with other departments in the organization.
Having a dedicated team to bridge the gap between development and operations is sensible on the surface, but there is a risk that this team will simply become yet another silo and a bottleneck for approvals. Rather than breaking down the barriers between development teams and operations teams, the DevOps teams themselves become the broker.
The approach makes deployment and promotion through environments like testing, staging, and production integral parts of the development process itself. If done well, the team shares the overall responsibilities, but individuals can support in specialist areas.
For this to work in practice, processes need to be explicit rather than implicit. This makes it easier to onboard new members of teams. As these processes evolve over time - which is a very healthy sign - the codified processes need changing in the documentation.
Security sets up success
Companies often talk about the importance of building trust with customers through security. Whilst this is completely correct, it’s only half the story. With the right measures in place, security actually supports the DevOps team and provides them with confidence and assurance. That’s why it’s critical to have an end-to-end, unified approach that secures supply chains, code, and enforces policies for the entire software lifecycle.
Progress doesn’t stop here
Software development continues to evolve - it’s what makes it so exciting. For example, the growing use of automation is changing with the way we think about DevOps. Teams are now able to achieve more with automation beyond CI/CD. We’re seeing organizations customize, measure, and continuously improve processes automatically but it’s essential to understand how the team feels about it.
As it continues to evolve, so will the best structures and processes. To ensure teams remain motivated and well-organized, I would recommend implementing simple feedback mechanics. For example, developer surveys, satisfaction scores, and interviews with people across the organization will shine a light on how their day-today role has changed and underline any pain points. Having the empathy to understand the problems of other teams will ultimately improve the product. Often the response might be difficult to swallow or surprising, but it will improve future efforts.
Finding the right balance between tools, people and culture is challenging and ever changing, but striking the right formula will drastically improve the way DevOps is done.
Kai Hilton-Jones, Senior Director of Solutions Engineering EMEA, GitHub