Jeff Sussna is a leading voice in the DevOps community. Advocating the approach of “moving fast without breaking things,” he helps organizations evolve toward high-performing teams in an agile ecosystem of people, products, practices, and promises. I spoke to Jeff recently about the most effective techniques he’s seeing and how they can be employed at an organization implementing an API program.
Thanks for taking the time to speak with us today! In your 2015 book, Designing Delivery, you emphasize the importance of design thinking in software delivery organizations. Where do you think software organizations can benefit most from this approach?
Jeff Sussna: In modern IT, whatever we do, at whatever level, is for the purpose of providing service to customers. Whether we run a database or VM farm, or oversee security, or operate a helpdesk, or build internal or customer-facing applications, we do it to help others accomplish their goals. We thus need to build human-centered design principles and practices into the fabric of our work.
We need ways to ask and creatively answer questions such as:
“Who will benefit from this capability and how?”
“What’s missing that we can provide that will make their struggle easier?”
“What do they need so they can easily and successfully use whatever service we provide?”
In the API community, we’re always talking about “managing APIs as products” to shift the mindset of technical teams away from viewing APIs just as interfaces to software services. You have been talking recently about shifting from product to service thinking. Can you elaborate on the goal of that shift?
JS: The goal of that shift is to transform our approach from being centered around making things to being centered around helping users accomplish jobs. To truly be helpful we need to think beyond just features. I can’t tell you how many startups I’ve worked with that polished their feature set, but never designed or really thought through the onboarding process. It’s your first experience of a service; if it’s a bad experience it might be your last one. Outages are another aspect of service that require good design and operations. Outages happen; service providers that manage them well, and communicate well around them, increase trust whereas providers that don’t decrease trust.
With respect to API’s in particular, one of the things that frustrates me is teams that view API test servers as their private business. “It’s just a test server; if it’s down for weeks that’s because we have more important things to do.” Other teams that use your API need to test against it. For them, your test server may be a production asset, because they need it to be available to do their development work, which is part of their service delivery process. One of the aspects of the product-to-service shift is the realization that delivering change is part of operating your service.
You have created the concept of “promise-driven design.” Can you explain what that is, and what value it brings to an organization?
JS: A promise is an intention to facilitate a desired customer outcome. Security scanning software, for example, might promise to help you find threats in minutes, rather than hours. Promises capture two important aspects of service. The first is the connection to outcomes, not just features. The compelling value of finding security threats in minutes rather than hours is clear. I can easily understand why I should buy that software. The second aspect has to do with the fact that promises don’t always get kept; sometimes we break our promises. This is actually really good: by forcing us to account for the possibility of failure, promises help us increase our chances of success.
Promise-driven design uses a simple set of questions to build continuous, customer-centered improvement into the fabric of our work:
1. What promises are we making? What have we signed up for and what do people expect from us?
2. How well are we keeping our promises? How could we improve our ability to keep them?
3. Are they the right promises to make? Are we making promises we can’t keep, or can we make more valuable ones?
These questions drive opportunities for user-centered design. We can weave the promise-driven design process into everything from product marketing, to API design, to resilient system architecture, to incident reviews and retrospectives.
Would you consider API contracts to be a “visible promise” that organizations make?
JS: Yes. Those promises go beyond just the level of functional expectations (“this REST call promises to show you account details you’re authorized to see, and none that you’re not authorized to see”) and also express so-called non-functional requirements (“our API promises 5-9’s availability,” “our API promises to return results in < 50 milliseconds,” etc.)
You are a well-known expert in the Agile and DevOps communities, and much of your work comes from the perspective of methodology and culture. Have you seen a correlation in the organizations you work with between Agile and DevOps practices and API first architecture?
JS: At their heart, Agile and DevOps are about participating effectively within complex ecosystems, not just as standalone teams. The most useful information is information that your customers, whether internal or external, can use in the most flexible and accessible ways possible. High-performing teams use API-first architectures to enable rich, dynamic value-delivery systems that help their organizations continuously adapt and innovate.
Thanks again for your time! Do you have any events you’ll be speaking at soon or activities you would like people to know about?
JS: I just finished a whirlwind tour of Europe (Oslo, Reykjavik, and Berlin) speaking and running workshops about promise-driven design. I’m available this fall and winter for workshops and speaking engagements that teach people how to use promise-driven design to move fast without breaking things. You can learn more about my company at https://www.sussna-associates.com. We offer end-to-end coaching expertise that connects UX design, product management, development, QA, and operations.
Great stuff! I know our readers will benefit from your insights.
You can learn more about creating a high-performing software organization in the “Way of the API Workshop,” one of MuleSoft’s API Program Workshops.
