#sdlogic

© 2015 Jeff Sussna, Ingineering.IT

A number of loosely related things have been simultaneously bothering me lately. John Willis’ brave and generous post about burnout brought them to a head in my mind. This tweet from the Dalai Lama: 

"Idealistic as it may sound, altruism should be the driving force in business, not just competition and a desire for wealth”.

prodded me to go ahead and speak my mind.

Why do ops engineers burn out from overwork and feeling ever-increasing pressure? Why do Agile teams get sidetracked from a focus on delivering customer value to an obsession with “velocity”? Why are DevOps and Continuous Delivery misunderstood as ways to make shit flow downhill faster, rather than as ways to improve the ability to hear and respond? Why does the question of whether massive security breaches really impact corporate behavior even merit debate?

I believe these problems all derive from misunderstanding the true meaning of service. We’ve fully entered the service economy, so understanding what it means is critical to all our lives. Service increasingly happens through digital means, so IT has to be an integral part of the discussion.

We may have transitioned from a product economy to a service economy, but we bring hangovers from the past along with us. We still often see our purpose as being to create things, fill them with value, and give them to customers in exchange for money. From that perspective, digital service just lets us make more things and deliver them faster. 

Service, though, is really about helping people accomplish their goals. The dictionary definition of “to serve” includes “to render assistance; be of use; help”. A waiter in a restaurant doesn’t just keep delivering plates to your table; they start by asking you what you want. You might order a full breakfast, or just a cup of coffee. Seen from a product-centric perspective, software as service creates unattainable pressure to push ever more functionality at users. 

That perspective misses the critical point that customers hire services to operate that functionality on their behalf. You don't judge a restaurant based purely on whether you get what you want or how fast it comes. You also judge it based on whether the food is any good when it arrives, and how courteous and helpful the waiter is.

Operations includes non-functional quality (resilience, security, etc.) as well as human assistance (training, support, onboarding, etc.). These “features” all contribute to helping customers use a service to accomplish their goals. They are part of the benefit for which customers pay, and need to be treated as first-class needs. If I have to waste time and suffer anxiety getting a new credit card number, the company that suffered the breach has done the opposite of helping me. 

One might object that customer benefit isn’t the real purpose of business. Business is inherently selfish; its purpose is profit, not help. Service, however, makes the two inseparable. Furthermore, service makes customer and employee benefit inseparable. A company’s internal functioning is no longer an irrelevant black box. Uninformed, unmotivated, disempowered employees make lousy customer support agents. Burned-out system administrators make mistakes that impact customers. 

© 2015 Jeff Sussna, Ingineering.IT

We often tend to think about “usability” as applying to a separate layer of digital service from functionality or operability. We treat it as a characteristic of an interface which intermediates between the user and an application’s utility. Operational concerns such as performance, resilience, or security are even further removed. This approach gets reflected in siloed design-development-operations practices. From the perspective of service quality, though, I think it may be more constructive to view usability as a characteristic of service as a whole.

What is service, anyway? In the language of service-dominant logic, it’s something that helps a customer accomplish a job-to-be-done. From that perspective, usability refers to the customer’s ability to ‘use’ the service to accomplish their goals. Everything that contributes to, or compromises, that ability, impacts usability.

Imagine an application that’s incredibly well design and implemented. Every feature works well and looks good. Its functionality, however, doesn’t match what the customer is trying to do. In that case, the customer can’t ‘use’ it very well; thus, it isn’t usable.

Now imagine an application that’s well designed and implemented, and excels at supporting the customer’s job-to-be-done. The infrastructure that hosts it, however, is very unstable. The application goes offline on a regular basis. During an outage, the customer can’t use it; thus, it isn’t usable.

Next, imagine the application service provider has fixed their infrastructure stability problems. They still, though, have weak security practices, and suffer a major breach resulting in the theft of customers’ personal information and credit card numbers. As a result, customers flee the service. In this case, they can use it, but they won’t. It still isn’t usable. Trustworthiness is a major component of usability.

I believe that designing, building, and operating services from the perspective of customer goals helps improve quality. When we take that view, we define usability as a characteristic of the service-customer interaction rather than of the service itself, or any particular layer of that service. In the process, we gain a common language that unifies, not just internal layers and silos, but also service and customer vantage points.  

© 2014 Jeff Sussna, Ingineering.IT