Is DevOps in conflict with remote work?

Immediate answer: no one knows. "DevOps" and "remote work" cover so much territory, and so little of it has been measured scientifically, that the only possible conclusion is "insufficient evidence".

One of the charms and challenges of business is that we move forward even in the absence of conclusive proof. Whatever the world at large eventually decides about DevOps and remote work, here are a few tips for thinking about how you can make the most of DevOps, remoting, and their combinations:

Beyond the Software Factory

The first key to success in this area, as with so many others, is clarity. Some organizations think of "remote" as "freedom from painful commutes": more-or-less local employees work many hours even though they're not in the central office. Marissa Mayer notoriously enforced face-to-face scheduling of Yahoo workers early in her tenure as CEO, and she's not alone in promotion of collaboration that way. At the same time, plenty of individuals and organizations make a case in favor of telecommuting.

A distinct sense of "remote" is the outsourcing model: all the HTML5 coders for a project might be employees of a body shop in Vietnam or Nigeria. Tamlin Magee observes that the factory model of a decade ago largely assumed that IT (Information Technology) is a cost center best managed on the procurement basis systematized principally by outsourcers operating in India and elsewhere. Results were ... mixed. DevOps is all about collaboration and teamwork, and simply doesn't match the the divisions of labor conventional outsourcing entails. Even more forcefully, Peter Bendor-Samuel emphasizes that "distributed DevOps" interferes with " ... getting the full benefit of DevOps". He argues that "... companies such as Amazon, Facebook, LinkedIn and Microsoft ... get huge gains on productivity by ... [siting] teams close to the business decision makers."

On another hand, job boards are currently thick with advertisements for "Remote DevOps" positions, and Martin Smith, among others, claims at least a handful of cultural connections that unite remote work with DevOps.

Two conclusions

In all this mix, I'm surest of two cultural conclusions:

  • Org charts and personality trump geography. I see plenty of employees with adjoining offices who never talk, because their organization says they have nothing to do with each other. I also know partners who team effectively over as many timezones as the planet has. Bringing everyone into the same headquarters doesn't guarantee collaboration; teaming with high-quality specialists half a world away is no certain barrier to it. Whatever policies the larger organization selects, you can help make DevOps work better right where you are.
  • If DevOps teammates are still thinking in terms of "break/fix", I have good news for you: you have room to improve! Even worse, perhaps, is if practitioners think they've moved beyond break/fix, but are still living it: still investing in elaborate on-call schedules, still edgy about deployments and effort estimates, still impotent to secure the resources to make DevOps an effective reality. 'Sound familiar? It just means your team has an opportunity--today--to adjust its habits so IT is a more creative, reliable, and rewarding business function.