Jeff Sussna's book "Designing Delivery" not only takes a deep dive into how organizations should think about their business approach, but also shows deep understanding of the expectations of customers today. These include speed of delivery of new features (or bug fixes), operational excellence (access anytime, anywhere) and active brand engagement (across multiple platforms, device) during the entire customer lifecycle.
In short, today's challenges as a service company (and most have become one by now) put into a coherent narrative and a comprehensive structure of capabilities required to succeed. Although C-level executives are clear target readers (as they should be able to see or have access to the organizations's global picture and its shortcomings), they should be wary that attempting to become a "customer-centric brand" that continuously re-designs itself requires pre-existing levels of maturity. If development teams are not agile, operations don't embrace DevOps or design teams don't value design thinking, then they should start there.
For everyone else, this book is a very interesting read and for many a futuristic prediction of the kind of skills and attitude most service organizations will demand from their people.
Part I explains why service delivery must be a customer centric process: never finished, continuously adapting to customer needs. A paradigm shift is required for roadmap-driven organizations that optimize internal delivery and management processes. Instead, they need to focus on seeing their product value from their customers perspective, and realize how important is is to listen and act swiftly on their feedback.
Part II breaks down the re-definition of quality under this new business modus operandis. It frames customers' expectations (often unaware themselves) on four dimensions: customer outcomes (jobs-to-be-done), access (anytime and anywhere needed), coherency (across time and multiple customer touch points), and continuity (adaptation to evolving customer needs). QA's new role needs to include not only validation of the customer journey but also the internal journeys of the other roles involved in service design: development, operations, customer support, etc.
"QA is about validating a service's ability to harness change and helping them continuously improve"
Part III introduces promise theory as a basis for thinking of services as chains of promises made to customer. Inherent to a promise, is the very possibility of failing to fulfill it. Thus for a service organization thinking in promises is preparing and embracing failure, as long as it leads to active learning which in turn can lead to more successful promises. Tightly linked to this view is the understanding that all socio-technical systems we use today are complex in nature, and thus fail in unpredictable ways.
"Asking whether a service is making the right promises naturally maps to validating requirements. Asking what a service needs to do to keep its promises naturally maps to identifying implementation holes and bugs. Asking what other promises a service needs naturally maps to integration testing."
InfoQ reached out to Jeff Sussna in order to better understand some of the ideas behind this book:
InfoQ: What was your motivation to write this book?
Jeff Sussna:I’d been giving a serious of talks at various conferences over the course of a couple of years. All my talks were essentially about the same thing: the need to integrate design with engineering in today’s IT organizations. During the same period I read a biography of Norbert Wiener and immersed myself in the history and theory of cybernetics. I also encountered Mark Burgess’s work on Promise Theory, which is very cybernetic at heart. These themes all came together in my mind; the book was an attempt to coherently communicate a new way of thinking along with a method for applying that new thinking.
InfoQ: How did your professional experience influence its content?
Sussna: I’ve built systems and led organizations across the entire development-QA-operations spectrum. I’ve worked on everything from compilers to content management systems to data center automation platforms. That background gives me a somewhat unique perspective on IT in general and DevOps in particular.
I also have a liberal arts background. I grew up looking at pictures of Frank Lloyd Wright buildings; in college I studied anthropology, sociology, and art theory. A few year ago I had an epiphany when I read Tim Brown’s book on design thinking, 'Change By Design’. I suddenly understand that, while I was not a designer in the formal, traditional sense, I approached problems from a design thinking perspective. From there I discovered the design thinking offshoot called service design. It occurred that, since IT is more and more about ‘service’, and more and more directly relevant to ordinary people, we need to design it as we would any other service.
In sum, that’s a long-winded way of saying that my background, like the content of the book, is very inter-disciplinary.
InfoQ: You mention Cybernetics is a concept that precedes the "sci-fi" image most of us have of it. Would you like to explain why the original meaning is important in today's world?
Sussna: At its heart, cybernetics views control as circular rather than linear. Even at the simplest level, does the thermostat control the temperature of the air in the room, or does the air control the thermostat? The answer is “yes”. As we move from a product economy, which stressed pushing things and messages towards to customers, to a service economy, which stresses companies and customers co-creating value together, we need to take a more circular approach to control. Also, as our world and the problems we face become more complex, we need to think more in terms of steering our way through complexity rather than engineering static solutions. The word ‘cybernetics’ comes from the Greek ‘kybernetes’, which literally means ‘good steering’. Problem-solving in the face of complexity is less about “does it work?” and more about “are we steering well?”.
InfoQ: The book stresses the idea that today's organizations are defined by how well and quickly they adapt the services they provide to ever changing customer needs. Is it fair to say then that service delivery must encompass multiple areas, not only the technical delivery (IT) area?
Sussna: Absolutely! Customers judge service value by the entirety of their relationship with the provider. Enjoying a restaurant requires not just good food, and not even just good food and service, but also good ambiance, price, parking availability, surrounding neighborhood, and a decent website to look up the menu. As all business becomes service business, and all business becomes digital business, the boundaries between IT and the rest of the organization begin to dissolve. If your functionality is great, but it doesn’t scale, or isn’t secure, or is hard to onboard, or your customer support is poor, or the website that explain what your service actually does and how/why to use it is incomprehensible, or you handle outages or security breaches clumsily, any and all of those defects can degrade quality in your customers’ eyes.
InfoQ: What are the effects, at the organizational level, of this idea of continuously evolving services? Do they require new organizational structures to be successful?
Sussna: They definitely people and groups to work across disciplines in new ways. Personally, I’m less concerned with explicit org charts then with behavior and attitude. I think it’s perfectly fine for designers and developers and testers to report to different managers. What they do need to do is to collaborate and empathize with each other, and to see themselves as providing service to each other, on an ongoing basis, with a greater shared value (serving the customer) in mind.
InfoQ: Your ideal "cocktail" for continuous evolution of digital services includes not only Cybernetics, Agile and DevOps but also Design Thinking. However, it seems that design work is still very disconnected from the technical delivery work. Do you agree and how would you improve those connections?
Sussna: Integrating design with engineering isn’t just about getting designers and developers to work more closely together. It’s also about applying design to IT itself, and approaching IT as a design act. How do we reimagine, for example, ITIL incident management, and helpdesk software and workflows, in user-centered, service-centric ways? Do we focus on closing tickets, or on helping users solve their problems?
InfoQ: Could you briefly explain what is continuous design for you and how it fits with continuous delivery and quality?
Sussna: Continuous design breaks down the boundaries between design and operations. Just as the thermostat continuously responds to changing air temperature, so too the continuous design organization continuously responds to feedback from operations. Continuous design operates on multiple levels:
- Continuous through time: unlike designing a coffee mug that you hope to produce and sell for 40 years, the design process never ends
- Continuous throughout the lifecycle: A/B testing, Game Days, and Chaos Monkeys imply that design happens in production as much as anywhere else
- Continuous throughout the organization: each part of the organization, whether the design or development department, or the 2-pizza microservice team, is a service provider to other parts of the organization, and thus must continuously design and deliver its capabilities on its consumers’ behalf
- Continuous delivery is a necessary but not sufficient component of continuous design. You could say that continuous quality is a measure of the success with which an organization is continuously designing.
InfoQ: The quality of a finished software product used to be characterized by the number of defects found and, in business terms, the number of sales or licences. How does the definition of quality change when thinking in terms of continuously running services?
Sussna: The reason we need to approach digital business cybernetically is that we are actually continuously failing. Even if we design and implement a new feature perfectly, as soon as the customer starts using it their needs begin to change. “This is great; now can you make it do X” is a common customer refrain. The very act of using something changes the user, thus changing the design problem. We are therefore continuously narrowing and then discovering/creating new gaps between needs and capabilities. For this reason, quality has to shift from stability, expressed as mean time between failures, to resiliency/adaptability, or mean time to repair. We are succeeding as long as we are listening and responding to our customers.
InfoQ: You mention every organization is now part of a service ecosystem, where everone plays both producer and consumer roles. What are some good practices for managing your service dependencies?
Sussna: This is precisely where Promise Theory comes in. The use of the word “promise” means first of all that we make commitments, and work hard to honor them, regardless of the promises made to us. On the other hand, it means that we don’t assume the promises we rely on will be kept. Whether we’re talking about human promises (“I promise to help you solve your problem when you call customer support”) or system promises (“I promise to serve web pages in < 10ms, regardless of the number of users”), delivering service as promises creates the loose coupling combined with attractive force that lets coherent systems emerge without causing large-system brittleness.
InfoQ: Do you believe customer centric brands require a new approach to service support in order to re-engage disgruntled customers and channel their feedback to the rest of the organization?
Sussna: I believe the entire service organization, from customer support back, needs to shift their mindset from “making things for customers” to “helping customers achieve desirable outcomes”. Perhaps ironically, ITIL captures this definition of service perfectly. If we make that shift, we create an attitude and set of behaviors that lets that feedback flow through the organization, instead of being blocked by organizational and behavioral silos.
About the Interviewee
Jeff Sussna is an internationally recognized IT consultant and design thinking practitioner. He is known throughout the DevOps community for introducing DevOps to the importance of empathy. Jeff has nearly 30 years of experience in software development, QA, and operations, and has led projects for Fortune 500 enterprises, major technology companies, software service startups, and media conglomerates. He is the the author of Designing Delivery: Rethinking IT In the Digital Service Economy, and is a highly respected teacher, writer, and speaker on topics across the Agile/DevOps/Design Thinking spectrum.