Many organizations are transitioning to DevOps, a software practice where developers both write and operate their code. This transition is often driven by digital transformation and the need to innovate faster while being always on, 24/7. But what does DevOps have to do with diversity, inclusion, and belonging?

I believe that the core principles and practices of DevOps transcend software development practices and can be applied across many functions and practices of an organization, including how to build and foster a diverse and inclusive environment. And I see this at PagerDuty, where not only does our development team practice DevOps, but where the principles and practices of DevOps permeate our culture (e.g., one of our company values is “Ack and Own”).

In this blog, I’ll talk about four important DevOps principles or practices, and how they can be applied to building a diverse and inclusive workplace culture.

1. Investing in Automation, Process, and Tooling

The first principle is investing in tools and processes that automate work. Automation here is anything that reduces repetitive or menial work, reduces friction, and allows people to focus on the high-value work that matters.

In the world of DevOps, a great example of automation as applied to building software is the CI/CD pipeline. This pipeline makes it possible for developers to build and deploy code. This is a necessity for the “build it / own it” model to work—you can’t make someone feel ownership over their code if they don’t have the access or tools to both add new valuable features and also fix things when they break.

The same concept can be applied to hiring a diverse workforce and a different type of pipeline: the recruiting pipeline. Companies have a lot of hiring managers, and all of those managers would like to have a diverse team. And why wouldn’t they? Every manager wants to have the best team possible and studies have shown that diverse teams perform better.

PagerDuty encourages its hiring managers to be proactive in building their networks to include people from underrepresented groups. But we also recognize that it can take some extra effort to ensure a diverse candidate pool, so we’ve invested in tools and processes to help automate building a diverse candidate pipeline:

• We run all of our job descriptions through Textio to ensure that they don’t have inherent bias.
• We require our internal and external recruiters to supply a diverse candidate pool. We won’t work with external recruiters that won’t commit to this.
• We partner with a number of organizations like Code2040, Hackbright Academy, HITEC, Path Forward, and Bridgeschool to source candidates for areas like Engineering and Product, where it’s traditionally more difficult to find diverse applicants in many markets.

One great result of these practices is that over 50 percent of the participants in our 2018 engineering and product intern program identified as women and/or people of color. These interns comprise the majority of our entry-level hiring pipeline.

2. Goals and Measures

The second principle is having goals and measuring your progress as you work toward achieving them. In the world of DevOps, companies ask engineers to both develop and operate software. This means asking them to go on call (likely one week out of every six or seven) and be ready at any time during that week to have their lives interrupted. Because of this practice, measuring the amount of time the team spends on “interrupt” work is important. If there’s too much of this kind of work, engineers will experience loss of personal time or sleep, low morale, high attrition, and reduced ability to innovate.

A best practice to effectively manage interrupt work is to have operational load goals and to report on them religiously. At PagerDuty, we share the team’s on-call load at every sprint review and discuss how it is trending over time. We hold on-call handoff meetings for teams to dive into these issues and understand where investments to reduce load are needed. And we build products that help our customers manage interruptions and have visibility into team health.

The same concept applies to your inclusion, diversity, and belonging goals—your goals must be easily measurable and visible. At PagerDuty, we set diversity goals and measure them as part of our quarterly business review process, just like we measure sales or product delivery.

As an example, before I started at PagerDuty, all of the leaders in the product team were men, and there were few women on the team. We made a concerted effort to improve the diversity of the team in general, with one of the focus areas bringing more women on the team. Each year we set a specific goal for percentage of women, measured it, reviewed progress on a quarterly basis, and hit it. These types of changes take time, and our numbers are not yet ultimately where we want to be—but as we continue to take advantage of programs put in place to feed a diverse pipeline of candidates, we hire in ratios that better reflect the population, and continuously improve our overall diversity.

3. Continuous Learning and Improvement

That brings me to the third principle of DevOps: continuous learning and improvement. In life as in DevOps, you are going to get some things wrong. But what is important is how you react to mistakes and foster a culture of continuous learning. My favorite example of practicing this in the world of software development is blameless postmortems, which should be conducted for every major incident.

There are a few elements in a blameless postmortem that are key to ensuring the organization learns and improves:

• They should be, well, blameless. This means the cause of an incident should never be a person. If someone took an action that led to an incident, what controls or guardrails were missing that enabled that action? Ensuring an individual is never blamed will ensure that people are open and honest in their assessment of the situation.
• Incidents should be viewed by the team as opportunities to learn. Postmortems allow you to 1) evaluate your response process to see if the team could have done anything better during response and 2) prevent a similar incident from happening in the future.
• The learnings should be shared not just within the team, but widely across the organization and, ideally, with your customers. Not everyone practices this, but doing so allows your customers to see that you take every disruption seriously and that you have put steps in place to ensure the same problem doesn’t happen again. A mistake can happen to anyone, but there’s no excuse for repeat incidents.

The blameless postmortem can be utilized to learn outside of major incidents. As you know, diversity and inclusion aren’t easy topics. Similar to DevOps, it’s important to know upfront that you are going to make mistakes.

An example of a mistake happened at a PagerDuty Company Town Hall meeting. We were communicating details of our upcoming annual conference, PagerDuty Summit. We had five keynote speakers, two of whom were women. One was our CEO, Jennifer Tejada, and the second hadn’t confirmed yet. Someone created a slide, leaving off our CEO (since everyone in our company knew who she was) and the second speaker who hadn’t yet confirmed. So what showed up were three white male keynote speakers. As you can imagine, that didn’t go over very well.

Some pointed questions were asked, such as “How could a company that puts such value on having a diverse employee base not have diverse keynote speakers?” Simultaneously, the team that had been working overtime on cultivating a diverse lineup of speakers (not just for the keynotes, but ensuring we had diversity across every track) were upset by the accusation that they were not putting the right focus on diversity.

What did we learn?

We learned that in focusing and building a program around diversity and inclusion, employees who care about this self-selected to be part of PagerDuty, and when they saw something off, they rightfully demanded better. We learned that optics matter and to pay attention to them at all levels. And we learned that assumptions of intent are a bad idea (e.g., the organizers don’t care about diversity at our conference or that everyone knows organizers are working hard to create a diverse panel of speakers)—and to keep an open mind around motivations while still questioning what seems wrong. All of this was of course discussed and documented as part of the postmortem process!

4. Individual Empowerment

This brings me to the final core DevOps principle, which is probably my favorite: individual empowerment. Traditional organizations work via command and control, where the decisions are made at the top and cascaded down. In the world of development for example, that would mean code releases would require VP approval, making continuous deployment difficult if not impossible.

DevOps principles rightly assume that the people closest to the code are the most knowledgeable about it. And if you enable them instead of getting in their way, they will be able to innovate and fix issues faster. Because when there’s a problem, the people that touch the code can make better decisions than any executive can, regardless of how capable that executive is. This plays out in best practice incident response processes, where stakeholders are proactively kept up to date during an incident, but are discouraged from disrupting an incident response in progress.

So how does individual empowerment relate to diversity, inclusion, and belonging? The company can put programs in place, but driving programs solely from the top is not enough to promote change. I’ve mostly so far discussed diversity, but when it comes to inclusion and belonging, employees are the key—only individuals can say whether they truly feel included.

To help foster inclusion at PagerDuty, we have a number of employee-run programs, including Employee Resource Groups (ERGs). ERGs host meetings and plan events to provide support to underrepresented populations in the workforce and society. PagerDuty sponsors the ERGs, but these affinity groups are run by employees for employees.

We also have a “Women in Sales” group, which another traditionally male-dominated function. This employee group has hosted a number of panels with women in all levels of sales to talk about their experiences and share advice, serving as great role models for women early in their sales careers.

Additionally, about a year and a half ago, we rolled out some new company values. They were top-down initiatives, and they just didn’t resonate with employees. So we went back to the drawing board and held a number of employee focus groups to get their insights on what matters most. As a result, we rolled out new company values that really connect with the employees (and that I think are very “PagerDuty”). Alex Solomon our co-founder and CTO writes about them here.

Bringing DevOps Into ID&B

It’s common knowledge in the industry that transitioning to DevOps is a difficult journey. And it takes aligning your processes, tooling, culture, and organization so that everything works together. The thing to remember is that it’s not about completing your journey. There will always be mistakes. We’ll always have newer technologies to build and better processes to put in place. The key to success is making progress with each iteration and attempt, and when you don’t, learning from your failures.

Fostering a culture of diversity, inclusion, and belonging is no different, and leaning on the below core DevOps principles will help.

• Change has to come from both the top and the bottom.
• Invest in automation and tooling to make it easy—most people want to be inclusive and will build a diverse organization if you enable them.
• Continuously evaluate how you are doing, blamelessly.
• And lastly, measure your success or failure along the way with the mindset that the only true failure is one that you don’t learn from and take steps to improve—this is a journey.