Learning from DevOps
What DesignOps Can Learn from DevOps
Jess Sussna, Principla at Ingineering.IT
From the Design Operations Summit website:
Traditional approaches to maintaining consistency break down when confronted by the complexity of digital business. While DesignOps and related approaches such as DevOps can enhance speed and responsiveness, they risk generating their own kinds of silos, blockages, and breakdowns. This talk will present an agile governance model that scales without becoming brittle, slow, or invasive. It will describe principles and practices teams across-the design-operations spectrum can use to balance agility, coherency, and resilience.
He helps organizations join empathy with action. He thinks of himself as a “compulsive synthesist”. In the past few years he discovered two things; one was Design Thinking (service design specifically) and the other was cloud computing.
Ultimately, service is at the core of what we do. He has been trying to help organizations bring agile together with design thinking. He wants to talk about what we’ve learned in DevOps, and what it means to scale systems and organizations. He challenges us to lift our gaze to think more broadly about what it means to scale design.
IT and design both emerged in the industrial age – they are disciplines that are about delivering things at scale. But in a post-industrial economy, we need to shift from making things to managing ongoing relationships, and we are critically dependent on the history of that relationship. Digital is infusing the physical – your relationship with your doctor is about the physician, the staff, the office, the site where you check your results, and all the back-end systems that support that. Your experience reflects all those systems and their interactions.
We have been taught to think about systems as machines – so as long as all the parts work, the car will drive down the road. But in DevOps, those systems look like much more like complex systems in nature and society. Parts are fluidly interconnected, and you can’t separate the front-end from the back-end, nor the inside from the outside. Thus, we need to start thinking in terms of relationships.
Complex systems are very elusive, and hard to control. They have strange, and counter-intuitive properties like emergence. So you can’t design or describe it as you would like. It’s flexible and elastic – groups of birds can split and go around obstacles, but planes cannot. At the same time, these complex systems are prone to cascading, catastrophic failures. We think we can automate problems out of existence. But we can’t quite be sure whether thing are working – and if they’re broken, we can’t always be sure why.
Complex systems are also sensitive to history; very small differences in initial conditions can lead to wildly different outcomes. So, at a certain level, you have to test in production.
The challenge is that the things we make and the environment are both changing. That means we can’t mode or predict or control complex systems the way we’re use to. And furthermore, if we control them too tightly, they have a tendency to shift from being floppily resilient to being dangerously brittle.
That means we need to become accustomed to navigating environments where we have less and less control and visibility. We have to do it by continually sensing what is happening around us. The DevOps principles are
- Flow – optimizing our ability to delier
- Feedback – optimizing our ability to hear back from the environment
- Continuous learning
That is really what DevOps is about. Like the Agile Manifesto, change is something we can harness to our advantage. But that also leaves us with a conundrum. It’s about your customer’s experience – but at the same time, it’s also about creating something consistent, coherent, and holistic.
Agile and DevOps manage change by breaking things down into smaller and smaller pieces. We now release code once a day or a week instead of once a month. We do continuous integration testing, instead of only doing it once every three months. The smaller things are in the time and space, the easier to safely change them. The rule of thumb is that the team should be small enough to feed with two pizzas.
However, with this approach we also risk replacing a few large silos with a thousand little ones.
We address that with service. Rather than disconnected, autonomous units, we treat each other as customers. Shift outwards and upwards towards our customers and helping them accomplish their goals.
ITIL spends a lot of time talking about service management, service operations. It does it with a wonderful phrase “facilitating desirable outcomes”. It’s not about the CRM system, but what the sales team can accomplish with that system. Everyone is a service provider. At every level of the organization you don’t just do what you’re tasked with, but you help others in your organization – and ultimately your customers – create some larger value.
What does this mean for governance? We need to do things in some globally consistent way. We need to change our approach. If it’s a centralized enforcement mechanism, it doesn’t scale – it creates friction and it’s brittle. How do we enable the parts of the organization to align with each other?
We need to shift our emphasis from what it makes or what it does towards helping the rest of the organization leverage your capability. You are helping them do what you want them to do. It is the difference between we defend the company and we help the company defend itself. Design Systems are a means to an end – a process, more than a thing. We need a radically human-centered, service-centered, and ultimately co-created process.
It could be a framework, expertise, or a perspective. The real purpose is to make it possible for innovation, learning, and problem solving to flow across the organization fluidly and with as little friction as possible. The three ways of DevOps are the three ways of Design Ops, too. We have to understand that we’re in the business of delivering digital service. How you make it is part of what you make. Impinging on the public experience can become very visible. If you say the restaurant food was good but the service was terrible, your friends are less likely to try the place. DevOps is combined because when you are delivering software as service, functionality and operability are part of one experience that we need to get right.
We need to expand our perspective beyond UI. What is the UX of Equifax at the moment?
It doesn’t matter how well designed your application is if the experience beyond those confines is bad. So how do we design for service?
What we’ve learned from DevOps is that you can’t engineer failure out of the equation, so you have to learn continuously. Kate Ivy Williams wrote a provocative post called Death by Double Diamond. Digital service is an ever-evolving, iterating thing. It means that we are delivering service by having different disciplines providing service to each other. Being a service provide isn’t enough – they have to continuously improve, and be in the business of service design. Continuously innovating on each other’s behalf needs to become part of the ordinary cadence of our work.
Far too often security fails because we forgot people are involved. For one company, their own technical goals were comprised because they didn’t engage in user-centered design.
So the most profound thing you can do is not build design systems, or building a design culture. The most profound thing is to build user centered, service centered, creative solution discovery into the fabric of your companies.
Jeff spends his time trying to help technical teams think more openly – to think more like designers. In Incident Reviews they have blameless discussions to learn and understand the bigger picture, to come up with a solution that is better, and that makes human operators more effective. We can only try to change existing to preferred – we can only try to design new and better things.