DevOps for Designers

I’ve recently discovered an emerging area of inquiry called DesignOps. The definition of DesignOps is still very much being worked out, which is not surprising given its newness. There seems to be some agreement, though, that DesignOps takes inspiration from DevOps.

This inspiration is very pleasing. It’s important, though, for designers to understand what DevOps is, and more importantly, what it isn’t. Unfortunately, I’m seeing some misunderstanding in this area, which I believe warrants clarification.

First of all, DevOps doesn’t stand for “developer operations”, or for that matter, for anything else aside from itself. Its name reflects the view of development and operations as intimately linked, collaborating, and mutually influencing parts of a larger whole. That larger whole is, quite simply, “DevOps”. DevOps applies systems thinking to IT by treating the relationship between development and operations as being just as important as, if not more so than, the individual roles and activities.

DevOps also is not an attempt to “remove QA and Sysadmin from the operations equation”. The point is to get Dev and QA and Sysadmin working together and influencing each other. Different organizations of different sizes may have different mixes of people with particular roles and or titles. Especially in startups, it may be the case that people with one title do all three jobs. It is often the case that automation reduces the number of people of a given role you need to do a given amount of work. But getting rid of people or roles is not the point.

DevOps’s core insight is that reducing the distance between people, teams, and activities, combined with reducing the batch size of your work, allows you to deliver more value, more continuously, with greater quality. Furthermore, you do so, not just to go faster, but to make the feedback loop between the customer and the company more intimate. Or, to express it in the language of the Three Ways of DevOps, Flow + Feedback enable Continuous Learning. Enabling adaption is thus DevOps’ end goal.

It is my hope that DevOps will provide DesignOps with inspiration on this level. What I really hope is that a conversation will happen between them about how to apply systems thinking to the entire digital service delivery lifecycle. As Kate Ivey-Williams said in her wonderful post about service design, “a service is an ever-evolving, iterative thing”. For that model to work, we need to unify our understanding and practices from design all the way through to operations (and back again). In fact, when I first saw the word “DesignOps”, I thought it referred to getting designers and IT operations folks understanding and working with each other.

Those of you who follow my work will recognize a broken record in my use of the phrase “unifying design and operations”. Nonetheless, I see it as a critical next step in our efforts to create adaptive, continuously learning organizations. I want to encourage everyone, whether designers, product managers, or DevOps practitioners, to help create a conversation that both pursues and expresses this vision. If my call to action strikes a chord, I’d love to hear from you at https://ingineering.it or on Twitter at @jeffsussna.