Skip to content

Can DevOps and Remote Work learn from each other?

More people than ever are working from home. Estimates range from 10% (in the least remote-work-friendly countries) to 60% in the United States. Even global data shows that half of all workers may be remote by 2020. DevOps, the cultural movement towards more agile systems administration, has also been gaining traction. Gartner estimates that 25% of global 2000 businesses will employ DevOps as a mainstream strategy by 2016.

So what can DevOps and Remote Work learn from each other?

Are there spots where DevOps and Remote Work overlap? Are there things that they can teach each other? Places where they are incompatible? Maybe they are at odds? Just off the top of my head, I know remote work can complicate sitting together (co-location) and pair programming. Digging a little deeper, and trying to find some data to back up my initial assessment, I found a more mixed message. Other than a paper for the Agile 2008 conference, I couldn’t find much published about this. I presented what I found at the first DevOpsDays Oslo in September 2016.

Defining Remote Work and DevOps

Martin Fowler goes into detail on how different configurations of teams are all considered remote — Single site, Multi-site, Satellite model, and Remote First. There’s also folks who might do all of the different configurations of remote work on different days of the same week, and digital nomads who are so remote that they might need an entirely different category.

Everyone has a different definition of DevOps, from Wikipedia to NewRelic to TechCrunch. My own definition of DevOps is, “an agile culture around operations and development working together.” One of my favorite definitions can be found here.

On Culture

Netflix’s culture deck made news last year and started a discussion of company culture across the Internet. They listed things like honesty and impact as the culture they wanted to create. Facebook has said that it’s culture centers around every employee taking responsibility for its success, from the receptionists to the CEO. Culture is clearly important in the tech industry, and even more so in DevOps; in fact, DevOps is often described as a culture that emphasizes communication and collaboration.

While it’s hard to quantify culture, I think the remote work movement also is heavily focused on culture. Specifically, a culture of trust, transparency, and accountability.

On Communication

Communication is a key pillar for DevOps and Remote Work. And in both, concerns about communication often become a search for good tools. Whether it’s Slack or Giphy, or even just a prompt for meetings (“What’s the worst thing you’ve seen today?”), just having communications amongst the team is critical, even if it’s not about work. Be sure you continuously iterate and improve on this item, because it can quickly fall apart. And always assume ignorance before malice when it comes to digital communications (not unlike a blameless postmortem).

On Happy Employees

This is an area where we do have better data. Specifically, the 2016 State of DevOps report states that:

Employees at high performing DevOps organizations are:

  • 2.2x more likely to recommend their organization to a friend as a great place to work
  • 1.8x more likely to recommend their team to a friend as a great working environment

The same report indicates that high performing organizations have better employee loyalty (NPS), and that loyalty correlates with better business outcomes! Forbes and Harvard Business Review have published similar statistics:

Remote employees are:

  • 50% less likely to quit
  • 87% more engaged compared to peers
  • 1.9x more likely to say they love their job (45% vs. 27%)

These numbers show that remote workers are happier and more productive, and that the highest performing DevOps organizations have happier and more productive workers as well. I think this is an interesting correlation, and I love the idea that it’s so correlated with business outcomes.

On Diversity

“Diversity matters. Research shows that teams with more women members have higher collective intelligence and achieve better business outcomes. […] We recommend that teams wanting to achieve high performance do their best to recruit and retain more women, and improve diversity in other areas, too.” – 2015 State of DevOps report.

Remote work is also a boon to diversity. It offers geographic, socioeconomic, and cultural diversity that would not otherwise be possible. Remote work also has lots of other socially minded benefits, like being good for the environment.

On Data-driven Decisions

I love data. I’m always asking for more data, or wishing I had data on specific behaviors or use cases. A recent study conducted by WorldAtWork and FlexJobs had this to say about measurement and data in the remote work world:

  • 64% had no formal policy or philosophy on flexible work location
  • 3% of organizations measure performance, engagement, and productivity

Face time is a traditional management technique, and most remote work advice recommends that we organize around business priorities and customer results instead. I think this is somewhere that DevOps has some good advice to offer.

Specifically, the advice in the DevOps community is to start using customer-facing metrics and real world, measurable outcomes to make decisions. If we are evaluating staff and decisions based on real data, then the DevOps and Remote Work movements are pretty much aligned already on this point. Except for the lack of data being collected in the Remote Work world.

Conclusion

When considering the similarities and differences between DevOps and Remote Work, we should probably limit comparisons technical remote work, and not other types of remote work like writing or graphic designers. However, I think the same general questions can be used to evaluate both DevOps culture and Remote Work culture:

  • Is there trust within the team?
  • Does the team work collaboratively?
  • How does the team handle decision making and conflict resolution?
  • How do managers interact with the team?

These are all essentially questions about communication and trust. My best recommendation is to pretend to be fully distributed, even if you aren’t. Skip the meeting room and try a VC meeting. That kind of exercise will quickly show you the culture of your team, and quickly indicate if you’re on the right path for a DevOps culture and a culture that embraces and supports remote work.

The more remote colleagues I have, the easier it is to have equal access to information, be on equal footing for scheduling and meetings, and just generally make the team a little more aware of everyone’s time and communication.

What do you think?

Published inRemote WorkTechnology