Ingineering.IT @ingineering - Tumblr Blog

Design Thinking Needs to Go Deeper, Not Just Broader

This post got published as I was migrating from Tumblr to Medium. Please see the latest version here.

What Is Failure?

Most of what we know about project management - Gantt charts, Pert charts, red/green lights, cost/schedule/scope control - originated with Robert McNamara’s efforts to rein in a bloated military during the Kennedy administration. The true of roots of modern project management, however, lie in the Manhattan project: the American project to develop an atomic bomb during World War II. The Manhattan project was driven by uncertainty. Not only did they not know how to build a bomb; they weren’t certain it was even possible. Physicists were genuinely concerned that a bomb might trigger an uncontrollable chain reaction that would set the entire atmosphere on fire.

The Manhattan project used a specific project management methodology consisting of two interlocking components. First, it simultaneously pursued multiple different lines of inquiry. Second, each line of inquiry used trial-and-error to decide what to try next. At first glance, this strategy might seem highly wasteful. When project management theorists analyzed it, however, they arrived at a counterintuitive conclusion: for projects characterized by uncertainty about where one is trying to get, and how to get there, the Manhattan project approach provides the fastest, most efficient way to arrive at the best solution.

Such projects aren’t just about developing a solution. They also involve exploration to discover what the solution should be. They thus require a process that interleaves search with implementation. Search is a progressive process. Knowing where not to look is as valuable as knowing where to search. Knowing not to bother looking for your keys in the kitchen, for example, contributes to efficiency by narrowing the scope of your efforts.

Pundits proclaim the need to embrace failure in the new economy. We need to be careful, though, about how we use this word. Rather than becoming tolerant of failure, what we really need is to refine our understanding of success. No longer does success just mean control over the cost/schedule/scope of implementation. Now, it has to expand to include the efficiency of our ability to search for solutions simultaneously with developing them.

From this perspective, anything we do that helps us calibrate the focus of our search efforts is a success. Whether an experiment suggests we should “keep looking in this direction” or “don’t bother looking over here any more” doesn’t matter. Failure only happens when we get no information to help ourselves with the next step in the search. Doing nothing that might provide such information is the ultimate failure.

Uncertainty, unknowability, and continuous change are the central characteristics of 21st-century life and business. In such a world, we encounter fewer and fewer situations that we can navigate without joining search and implementation. Trying to treat them separately, and carve out projects we can manage by minimizing so-called “negative results”, is the true definition of failure in the post-industrial world.

#designthinking #projectmanagement #leanux

Revisiting Empathy

It has been gratifying to see the community take hold of the idea that empathy is the essence of DevOps. Putting empathy at the center of our practice emphasizes the importance of relationships between people in improving service quality. It reminds us that at its heart “DevOps” is about developers and operations engineers working together. DevOps is systems thinking; systems thinking values the connections between things as much as the things themselves; effective connection requires the ability to see yourself from the other’s perspective.

I have noticed, however, a worrisome tendency to treat empathy as a static, binary state: “either you have it or you don’t”. I’ve also encountered subtle implications that certain kinds of people or organizations have the ability to empathize, while others lack it. On the one hand, we all have the capacity for empathy. On the other hand, perfect empathy is impossible. We are all different people, with different lives, histories, and daily experiences. Those experiences also change over time. Even if we could perfectly understand another’s perspective, that perspective would change before our eyes.

I came to understand empathy as the essence of DevOps through cybernetics. The cybernetic worldview sees life, work, and business as a never-ending process of adaptation through conversation with one’s environment. Cybernetics shows us the way to a meaningful approach to empathy. We continually encounter gaps between our beliefs about someone’s perspective, and its reality. Seeing those gaps allows us to narrow them.

As the great cyberneticist Heinz von Foerster put it, “I like cybernetics: its intrinsic circularity helps me see myself through the eyes of the other.” Circular causality defines the nature of things as a process, not a state. Empathy doesn’t exist; it unfolds. Rather than being something we have, empathy is something we practice. Circularity implies the potential for us all to succeed, coupled with the fact that we all continually fail. It challenges us to approach our work and our customers, at whatever level we have them, with both curiosity and humility.

Conversational practices such as design thinking, Agile, and DevOps can enable organizations to practice empathy by continually detecting and narrowing the gap between their customers and their understanding of their customers. It is for this reason that feedback in various forms, from user testing and monitoring to direct communication, are essential to making these practices truly effective. Simply speeding up delivery misses the point. It is only by making design continuous, and unifying design and operations by embedding, respecting, and acting on feedback throughout our organizations, that we can hope to realize empathy in a truly meaningful way.

#devops #designthinking #empathy #cybernetics

Why We Should Continuously Break Everything

Few things in IT are more painful or nerve-wracking than porting or refactoring a long-lived system. It could involve something as simple as moving an application to new hardware, or as complex as refactoring the application's software architecture, or the architecture of the network beneath it. Exposing rot is an inevitable part of the process. "Oh yeah, we forgot to port the cron jobs we set up and forgot about six years ago." "Oh yeah, the network was set up that way because of this one weird connection between those two weird processes."

Continuous delivery teaches us that small, frequent changes are easier to manage, test, and fix than large, infrequent ones. In the words of Jez Humble, "…continuous delivery becomes even more important when you're risk averse. Big-bang releases are horribly risky." Continuous change may seem to cause continuous failure; counterintuitively, though, it actually reduces the overall cost of failure.

Systems rot over time, even when they sit unchanged. Rot can arise due to human forgetfulness, or due to drift between a past decision and that decision's appropriateness for current conditions. Exposing rot is no different than doing integration testing. The more you try to do at once, the more complex it is to understand and repair the problems you find.

The need for the ability to deliver change is accelerating on all levels. New business needs and technical solutions are both arising ever more quickly. Yesterday it was cloud and VM's. Today it's cloud-native and containers. Tomorrow it will be…who knows?

The expectations for IT's ability to port and refactor its systems is similarly rising. We can no longer look away from our fear by putting it off. Instead, we need to consider applying the principles of continuous delivery to system change altogether. The thought of building in pervasive refactoring, at all levels of the IT stack, may seem like a radical, even foolhardy, proposal. It certainly will cause more continuous failure, as we expose rot more continuously. Just as with continuous delivery, though, it will contribute to less overall failure, less cost due to that failure, and more robust systems. Most importantly, it will do so while increasing our ability to deliver change. That ability is, after all, the prime imperative of 21st-century business.

The CIO, What Is It Good For?

The destiny of the Chief Information Officer is currently up for vigorous debate. Some would replace it with a Chief Digital Officer. Others would merge it with the Chief Marketing Officer. Still others claim that, given 21st-century companies’ ever-increasing reliance on digital technology, the CIO as it currently stands is more relevant and important than ever.

With respect to them all, though, I think we’re putting the cart before the horse. Before we can accurately assess the CIO’s proper role and position, we need to understand the evolution of IT itself. Without knowing how IT is likely to look, and what its relationship to the rest of the business is likely to be, how can we hope to assess the desired function or characteristics of its leader? If, for example, IT were to follow one of the most extreme predicted paths, and fully dissolve itself into the larger business, then the whole question of the CIO's destiny would become moot.

IT and the businesses it serves are both undergoing massive transformations. I question the feasibility of predicting the trajectory of either process, and therefore submit that trying to define the CIO of the future is premature. In fact, I believe the problem cuts even deeper. In my opinion, the time has come to question the relevancy of the term "Information Technology" itself.

IT is no longer in the business of generating or managing "information". Gone are the days where businesses primarily needed nightly inventory reports, or relied on so-called "management information" systems. Instead, IT is becoming the very medium through which companies interact, both internally and with their customers.

The digital realm is increasingly infusing our ordinary lives. We conduct more and more of our interactions with governments, companies, and each other online. Just as we expect our state and city governments to provide and maintain the roads on which we can drive to visit friends and buy groceries, so too customers and employees expect IT to provide and maintain the digital substrate on which they can electronically collaborate, buy, and sell.

The precise structure and location of this thing we call "IT" remains to be seen. However it looks and wherever it lives, though, it now stands more for "Interaction Technology" than "Information Technology". To the extent that the CIO continues to exist, it will be more "Chief Interaction Officer" than "Chief Information Officer".

So what should the CIO do, given the shakiness of their future? Simple: put the horse before the cart. Focus on helping the business understand its needs for digital interaction. Use that understanding to leverage whatever budget and staff it has to enable interaction between employees and with the market as powerfully as possible. Treat the various tools at its disposal, whether they be private or public, cloud or data center, centralized or rogue, as implementation details.

If I turn out to be right about the shift from information to interaction, and if the CIO effectively helps the business interact, then their future will fall out naturally. Just as with the business as a whole, they need the courage and imagination to move forward without being able to predict their precise destination. Ultimately, their nature and their name will follow from their work.

#cio

Why DevOps Really Is About Culture

Emerging methodologies such as Agile, DevOps, cloud, and microservices both reflect and contribute to IT’s growing complexity. It’s no longer possible (assuming it ever was) to fully specify how things work or what people should do. To align IT with 21st-century business imperatives for quickness, innovation, and adaptability, we need to empower and rely on people’s ability to make decisions that are compatible with those needs.

How do we do that? According to DevOps, the answer is "culture". But what does that word mean? It's become a bit of a flashpoint within the DevOps discourse. Many critics object that the term "culture" isn't meaningful, or that we don't properly understand what it does mean, or that it's not actionable, or that it isn't even relevant, and instead we should focus on "concrete behavior".

Even anthropologists, for whom culture is at the core of their work, don't entirely agree on its meaning. For the purposes of this discussion, I will lift a definition offered by Clifford Geertz. According to Geertz, "…man is an animal suspended in webs of significance he himself has spun. I take culture to be those webs…" (masculine gender left as is in the original). In other words, culture defines, and is defined by, what we think things mean.

Meaning doesn't just name things. It also constrains and guides what we think we can do with and about things. Put another way, meaning affords action. Changing the name of a meeting from "postmortem" to "learning review", for example, changes your belief about what to expect will happen in the meeting, and what you think will be acceptable to say or do in it.

Culture generates implicit webs of meaning. We reinforce those webs through our actions over time. When we confront repeated similar system failures, for example, do we take their meaning to be that we need to document a standard recovery procedure? Or do they mean we need to investigate the root cause so we can banish the failures from happening again? We pick a path based on the culture surrounding us. Conversely, the path we pick reinforces that culture for ourselves and the rest of our organization.

DevOps as culture is about shifting the web of meanings we use to guide our work in IT. It challenges us, for example, to change our beliefs about the meaning of such things as “snowflake servers”. Instead of viewing them as affording opportunities for careful documentation and tending, DevOps points us instead down an alternative path, wherein we view snowflake servers as affording opportunities to replace them with standardized templates.

The question still remains, though, as to why talking about "culture" is helpful in effecting a transformation such as DevOps. In order to change organizational behavior, we need the ability to see what that behavior is, and how we reinforce it. Making the "web of significance" explicit gives us a handle to start bending it in new directions. It allows us to start asking, "why am I about to do what I am?", and "what might be the implications if I did this other thing instead?"

The tools/culture dichotomy that haunts DevOps is thus a false one. We reinforce culture through our tools and how we use them. At the same time, our culture constrains which tools we use, and what we think they afford. In order to transform IT, we have to confront both simultaneously. We have to build "asking why" and "asking what if" into our daily work. Unless we do so, we are likely doomed to transformation implementations that are ineffectual, cargo-cult, apparent failures.

#devops #culture

LeanUX and DevOps: A Match Made In Heaven

Last week I attended LeanUX15 in Brooklyn. Kudos to Will Evans for putting on a conference that was substantive, stimulating, and fun, and that challenged participants to think across disciplines and intellectual levels. Kudos also to LeanUX in general for generating a community of people who are interesting, thoughtful, open, and delightful.

I came home from LeanUX15 very excited about the potential for cross-pollination between LeanUX and DevOps. On the one hand, I think the DevOps community can learn a lot from the LeanUX community. They grapple with some of them same issues: how much is too much/not enough in terms of defining methodologies? How do you avoid cargo-culting without falling into directionless, fruitless wandering? The design industry has a long history of thinking about the relationship between theory and practice. They have experience and language for tackling these issues that could be very educational for DevOps.

On the other hand, I got an equally strong sense that LeanUX needs DevOps. I had numerous conversations with designers and product managers about trying to conduct lean experiments, only to run into IT operations as a source of friction. With the full dissolving of software into service, any attempt to converse with customers via experimental value delivery is futile without addressing the end-to-end service operations lifecycle.

Fortunately, LeanUX and DevOps are highly compatible. LeanUX talks about validating hypotheses through experimental feedback, and removing waste from the experimental process. DevOps talks about the three ways of flow, feedback, and continual learning. The two approaches are almost begging for synthesis.

DevOps can also inform LeanUX through its concern for operations as first-class corporate citizens. Service dissolves hard boundaries between customer and employee experience. Value arises in their intersection. In my opinion at least, LeanUX needs to incorporate operations and support staff in their designs and experiments.

For next year’s conference, Will is riffing on this year’s keynote by Lean Enterprise Institute’s John Shook and using “Lean Work Experience” (LeanWX) as next year’s theme. This new focus on the inside of the service delivery process creates an opening for DevOps to pursue its aspiration of reaching beyond itself. Over the course of the coming year, I hope that the LeanUX and DevOps communities can take the next step in exploring the intersections between and integration of our respective theories and practices. It is my belief that, unless we do, we can’t hope to fully address the needs of digital service organizations or customers.

#leanux #devops

Tesla and the End of the Physical World

At least in the Western world, we perceive ourselves as inhabiting a world populated with objects. We judge those objects by their stability over time. We don’t expect them to blink in and out of existence from one moment to the next. We assume that the table we see will still be solid when we put our book down on it.

We have traditionally created physical objects with the intention that they’d last for many years. Longevity was an intrinsic part of their value. Medieval churches astound, not just because of their beauty, but also because that beauty remains unchanged for a thousand years. I remember my initial impression on visiting Venice, Italy: as an American, coming from a country that didn’t exist 200 years ago, I was stunned to see 600 year-old buildings still standing and occupied.

Our understanding of the nature of objects influences us as consumers. I’m a long-time, loyal Honda customer due to their cars’ reliability. My current Honda is 10 years old and has 175,000 miles on it: I expect to drive it for at least a few more years. While shopping for a set of headphones for my iPhone, I read negative reviews about products that were great when you bought them, but broke fairly quickly.

Now, though, digital infusion is changing our fundamental understanding of physicality. Tesla recently announced an over-the-air software upgrade that would dramatically extend their cars' battery life. This improvement applies to cars in the field, not just ones being newly purchased. Suddenly, without changing anything you can touch, the physical behavior of your car has changed. It’s as if your iPhone suddenly got a bigger battery without you having to trade in your 5 for a 6-Plus.

Some observers see the Tesla announcement as a disruptive business moment that will change business models, labor, cost, and service processes. To me, though, it’s disruptive on a much deeper level. I see this announcement as a seminal moment in the evolution of our understanding of the nature of reality. We are beginning to relate to physical objects as things we expect, and want, to continually change, rather than as things we expect and want to remain the same. Material becomes fluid. Goods become services. Matter truly becomes equivalent to energy.

Many futurists have envisioned a cybernetic future where computing invades our bodies and makes us into cyborgs. Instead, perhaps the invasion will go the other direction, infusing the dynamic quality of mind into the objects with which we surround ourselves. If so, it will profoundly change everything from how we design to how we live. No longer will we design, sell, or support "things" with the assumption that their characteristics will be fixed at the conclusion of the design process. Nor will we look around ourselves and see "things" that slowly degrade (like my car, which needs new valve cover gaskets). Instead, we will see the world as a reflection of our minds: continually changing, making mistakes, fixing them, and learning.

#design #IoT #digital

Altruism, Profit, and 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.

It is my belief that “service for others” can and should be the driving force behind the new economy. To work, it has to apply equally to relationships between companies and customers, and between employees within companies. The lack of one compromises value co-creation. The lack of the other causes the service organization to crumble from within. In either case, without thinking of others, we can’t hope to operate organizations that continuously provide true service quality. In the post-industrial world we now inhabit, that should be the point of everything we do, whether it’s as mundane as running an online invoicing service, or as exciting as building connected cars and thermostats.

#devops #sdlogic #service #servicedesign #cx

Microservices, Have You Met…DevOps?

Numerous commentators have remarked that microservices trade code complexity for operational complexity. Gary Oliffe referred to it as "services with the guts on the outside". It is true that microservices potentially confront operations with an explosion of moving parts and interdependencies. The key to keeping ops from being buried under this new-found complexity is understanding that microservices represent a new organizational model as much as a new architectural model. The organizational transformation needed to make microservices manageable can't be restricted to development; instead, it needs to happen at the level of DevOps.

Microservices work by reducing the scope of concern. Developers have to worry about fewer lines of code, fewer features, and fewer interfaces. They can deliver functional value more quickly and often, with less fear of breaking things, and rely on higher-order emergent processes to incorporate their work into a coherent global system.

In order for microservices to work, though, ops needs a similar conceptual framework. Trying to manage an entire universe of microservices from the outside increases the scope of concern instead of reducing it. The solution is to take the word "service" seriously. Each microservice is just that: a software service. The team that builds and operates it need only worry about it and its immediate dependencies. Dependent services are customers; services upon which a given microservice depends are vendors.

How do you ensure robustness, and manage failure, when you restrict your operational scope to local concerns? The reason we try to operate microservice architectures monolithically in the first place is because we think “but it all has to work”. The answer is to treat them as the complex systems they are, instead of the complicated systems they're replacing. If each microservice is a first-class service, its dependencies are third-parties, just like Google Maps, or Twilio, or any other external service. Third-party services fail, and systems that depend on them have no choice but to design for failure.

Microservices promise increased agility combined with improved quality. To achieve both goals, organizations have to shift their definition of system-level quality from stability to resilience. If they can do that, they can reflect that definition of quality in their organizational structure. Just as a SaaS company as a whole would use DevOps to deliver service quality and agility, so too each microservice would do the same.

#devops #microservices

Design As Operations, Operations As Design

I just finished reading Thomas Wendt’s wonderful book, Design for Dasein. I recommend it to anyone who practices, or just is interested in, experience design. Wendt's ideas have profound implications for rethinking and improving our approach to designing experiences. They also have profound implications for how we think about DevOps, and its relationship to design, and how that relationship impacts the nature and purpose of digital business.

Design for Dasein introduces what Wendt calls “phenomenological design thinking”. This is a new approach to design that expands the designer’s attention beyond creating things that people use, to encompass thinking about the ways in which things influence, interact with, and are influenced by how people experience the world. Phenomenological design thinking reflects two key insights about the role of designed objects in peoples’ lives. First, designers create possibilities for use rather than rigid solutions. Wendt cites the example of using an empty coke bottle to hold open a door in an old, crooked apartment. By itself the bottle wasn't heavy enough to keep the door from swinging shut, so he filled it with pennies. At that point, the bottle suddenly had three overlapping uses: containing and drinking soda, holding opening one's bedroom door, and storing spare change. Wendt’s point is that the designer does not entirely control the object’s destiny. That destiny is co-created by the designer and the user.

Second, Wendt points out that designed objects aren’t just passive targets for human usage. Instead, through the very act of being used, they change the user and the user’s world. The impact of smartphones on our personal behavior and our social relationships is an obvious example of this phenomenon. In the process of being used, solutions change the problem space for which they were designed. As I interpret it, phenomenological design thinking undercuts the notion of designers as gods who create stone tablets to be handed down to grateful users. Users, as well as the world that is the context for their usage, become co-designers. They don’t necessarily redesign things themselves (Thomas didn’t melt down his coke bottle to make it into a door stop). They do, however, change the meaning of a solution by influencing how it is used, for what purpose, and in what context.

To me, phenomonological design thinking implies the need for what I’ve begun calling ‘continuous design’. Continuous design takes the view that design is never done. Instead, it becomes a continual, circular process of designing, producing, using, and learning. The usage of a design becomes the input for its redesign, and for the design of new things. We can see a crude version of this process in the history of the iPhone. Its wild success caused other companies to enter the market. Their creation of larger-form factor phones forced Apple to abandon its attachment to the iPhone’s smallness. They responded by advancing the state of so-called “phablets” with the release of the highly regarded iPhone 6+.

Continuous design of physical objects faces certain friction-generating constraints: cost and availability of materials, manufacturing plant retooling, etc. Digital design escapes physical-world constraints, but encounters its own. The constraints that remain involve a) the design process itself and b) the digital delivery lifecycle. DevOps arose to reduce constraints within that lifecycle. As such, I would claim its most powerful value, and perhaps even its essential purpose, is to enable continuous design.

LeanUX is a methodology that addresses the constraints within the design and development process. It takes the view that design needs the ability to quickly, continuously iterate its way towards quality solutions. Phenomenological design thinking challenges digital service organizations go even further. We can’t fully evaluate, or even understand, the meaning of a design until it’s being used in real environments by real people. In other words, the only place you can complete the testing of your design, or understand what needs to be designed next, is in production.

DevOps provides the missing link that connects LeanUX to phenomenological design thinking in order to create continuous design. It serves to minimize friction, and maximize knowledge, by optimizing flow, feedback, and continuous learning between design/development and operations. From a phenomenological design thinking/continuous design perspective, DevOps can only be fully successful to the extent that it loops information about users and their world back to design. Continuous delivery of application code is necessary but not sufficient. The M for monitoring in CAMS is critical. Furthermore, that monitoring has to go beyond infrastructure monitoring. It needs to incorporate behavioral monitoring.

The need for phenomenological feedback (information about how users are experiencing the designs we release) implies the need to infuse design and DevOps into each other. It’s not enough for designers, developers, and system administrators to talk, collaborate, and share tools. They need to embed each others’ sensibilities within themselves. The people who build and operate production monitoring systems need to understand the kinds of feedback that designers need. Futhermore, designers need to treat operations as part of their design problem. Continuous design relies on augmenting product or service functionality with designer learning. Releasing the output of a design process is the beginning, not the end.

If Thomas Wendt and I are right (and assuming I even understand his book properly), a deep integration across design, development, and operations is critical to digital business success. My underlying thesis is the idea that digital business does not sell products, or even services, in the traditional sense. Instead, they sell continuous design: the ability to engage in continuous conversation with customers by creating designs in response to users’ experience of the designs they’ve already created. As Esko Kilpi put it in his excellent blog post on the Internet of Things, “the effectiveness of an offering is related to how well it packages the learnings from past activities”.

#design #devops #leanux

It's Usability All the Way Down

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.

We can use that language to help ourselves achieve true quality in the mind of the customer. Customers define service quality in terms of their experience. They care whether they can use the service to accomplish their jobs-to-be-done. Which service layer, or organizational silo, compromised usability is uninteresting to them. We need to match that perspective with our own conceptual model, language, and behavior. Revising our approach to ‘usability’ to cross design-development-operations boundaries can, IMHO, help make that transition.

#servicedesign #devops #sdlogic #ux #jtbd

In Defense of Empathy

I have previously espoused the view that empathy is the essence of DevOps. Not everyone agrees that empathy is necessary, or even desirable. Before we can explore this question further, we need to understand what the word “empathy” really does and doesn't mean.

Dictionary.com defines empathy as "the intellectual identification with or vicarious experiencing of the feelings, thoughts, or attitudes of another”. This definition doesn’t imply wallowing in another’s pain. Just because we can empathize with a depressed friend doesn’t mean we become similarly paralyzed by gloom. Even though explanations of empathy often use painful experiences to differentiate it from sympathy, this definition doesn’t necessarily imply a relation to pain at all. One can empathize with another’s aspirations as well as their frustrations.

Empathy can also function on a much more mundane level. Why does someone navigate a user interface the way they do, even though there are “more efficient” ways to do it? Why do they take a certain route to work, even though there’s a shorter way?

On a more abstract level, empathy is the basis for systems thinking. Systems emerge from relationships between components. Relationships happen through conversation. Conversation requires the ability to comprehend what another party “is trying to say to you”; in other words, the ability to see things from the other’s perspective. Otherwise, the conversants in a relationship are just talking at each other, with out actually relating to one another. Without relationship, there is no system.

This kind of conversation takes place, not just between people, but also between people and systems, and even between systems themselves. To be effective, a user interface must encode an understanding of how its consumer approaches the world and the tasks they want to accomplish. It must allow its consumer to use it in ways that are meaningful to the consumer, not just the designer.

The need for user-centered design applies to API’s just as much as UI’s. The point of an API is to help another piece of code accomplish its own goals. We all know how frustrating it is to try to write code against an API that wasn’t designed with us in mind.

Even the word “DevOps” reflects its roots in systems thinking. DevOps is a system that arises from the relationship between Dev and Ops. Some people view DevOps as an application of Lean or Theory of Constraints. These techniques can provide tremendous benefit. It certainly isn’t my belief that all one needs is to “rub a little empathy on it”.

The fact remains, however, that exercises in mapping value streams or identifying constraints generally result in changing how people work together. In the context of DevOps, they usually remove waste and improve quality by putting people into more intimate contact with each other. This new intimacy often crosses traditional boundaries of organization and expertise.

Without the ability to create a higher-order system out of empathic, conversational relationships, it is questionable how effective these changes can be. On the one hand, having developers and sysadmins hold joint standups can foster empathy by letting them hear each others’ challenges and needs. On the other hand, without some baseline capacity to empathize on the part of its participants, joint standups can end up merely ossifying existing suspicion and mistrust. Interpersonal conflict and passive resistance generate their own kinds of waste.

Alternately, DevOps implementations demote both dev and ops into disembodied cogs in the continuous delivery machine. DevOps as assembly line is the greatest downside of a focus on automation that ignores culture. Process optimization that ignores the importance of empathy risks obsession with speed that degrades user-centeredness while at the same time contributing to employee burnout.

#devops #empathy

We Get the Enterprise DevOps We Deserve

Design thinking expresses traditional design principles in a form that can be used for non-traditional activities. According to Herbert Simon’s definition of design as “changing current situations into preferred ones”, nearly anything can be designed, including DevOps. One could view DevOps as a thing, and argue about the definition of that thing. Alternatively, one could view it as an unfolding discourse, which can continually change from its current situation into a preferred one.

Empathy is central to design thinking. In practical terms, empathy means testing your assumptions against users’ perspectives. Design thinking projects often start by looking for a new solution, only to discover the need to reframe the problem itself. I believe this approach can help us navigate the current debate regarding the nature of DevOps and the relevancy of Enterprise DevOps.

Some of us dismiss Enterprise DevOps as, at best misguided, and at worst “snake oil”. Perhaps, though, we might be better served by listening to it for possible glints of wisdom. Could there be any truth to the claim that DevOps is “handwavy” when it comes to talking about culture? Might IT organizations gain genuine benefit from efforts to explain more concretely how to address the C in CAMS? Does denigrating people with the “snake oil” moniker miss the fact that salesmen go where the money is, and that money points to a perceived need? If we believe that Enterprise DevOps is “wrong”, might addressing the underlying real need be the best way to “discredit” it?

Conversely, those of us who dismiss “pure DevOps” as a fantasy for startup unicorns might benefit from testing our own assumptions that underlie that opinion. Ironically, DevOps came into being to solve a legacy problem, not to present a golden utopia to the masses. Just because we can’t get a handle on what feels like hand-waving doesn’t necessarily mean it's empty of content or value. That being said, if we think the “pure DevOps” discourse around culture is a call for “cultural revolution”, maybe that’s exactly what enterprises need. They are besieged by demands to change their notion of themselves and how they relate to their customers. Is it strange to think they’d need equally profound transformations within IT? If we try to translate the strange and foreign into something more accessible, are we really addressing the right problem? Finally, if we want to present Enterprise DevOps as something “different”, we need to do more than just elaborate its ostensibly unique challenges. "Enterprises are different" is a question, not an answer. Assuming it's the right question, we then need to answer it by describing what Enterprise DevOps practices actually look like, and explaining their unique applicability to large organizations. It doesn't help if we're as equally handwavy as the "other side". Im my humble opinion, DevOps is good, and we all deserve good DevOps. The best DevOps is that which concretely, empathically addresses its customers’ needs. Time will tell whether that results in a single set of practices you can buy from a certification body, or in infinitely many, where every shop does it a little differently, or something in between. I believe that empathy is the essence of DevOps, just as it is the essence of Design Thinking. As such it needs to characterize, not just specific practices in specific IT organizations, but also the ongoing design of DevOps itself. The Tibetan Buddhist teacher Dzigar Kongtrul recently tweeted, "When we are hit with suffering we generally focus on the outer causes instead of looking at the inner causes of our suffering.” This comment seems like wise advice for us all. The more willing we are to expose ourselves to feedback, however it comes, and however confusing or distasteful it may seem, the better chance we'll have of changing current situations into ones that really are preferred.

#devops #empathy #designthinking

How to Fix Agile (and Cloud and DevOps) With This One Neat Trick

The Agile community seems to be going through a renewed bout of soul-searching. On what seems like a daily basis I see posts questioning the relationship between formal, "capital-A" Agile practices and "small-a" agility. Debaters search for meaning in the Agile Manifesto like constitutional lawyers. I decided to reread the manifesto for myself. It quickly occurred to me that its framers might have made a tactical error. The heart of the manifesto, which makes up page one, is a set of four values. The problem is that these values are really practices. They are things to do: collaborate, respond to change, emphasize software over documentation. They focus on what and how, not why. Page two of the manifesto is a set of twelve principles. Reading the principles, I suddenly saw it, as if glowing in golden light: the holy grail, the key to the kingdom, the answer to all questions. "Agile processes harness change for the customer's competitive advantage." If I were asked to rewrite the manifesto, I would make that sentence the entirety of page one. It answers all the questions about why we should use Agile, how we know if we're doing it right, how we communicate its ultimate value, and so on. In fact, this principle goes beyond just agile software development. It captures the underlying purpose and benefit of all of 21st-century IT, from Agile to Cloud to DevOps to PaaS to Microservices to Continuous Delivery. When we say that any of these practices or technologies makes a business more agile, or helps it tighten its OODA Loop, what we're really saying is that it helps the business harness change for competitive advantage. We can use this principle to address objections to particular practices. To those who complain that Agile or DevOps tosses discipline and quality out with the rigidity bathwater, we can respond that the goal is to “harness” change, as one would a horse, to make it work for us, not to surrender to it. Conversely, we can use this principle as our own guide and conscience. We can use 2nd-order Agile practices such as retrospectives to ask ourselves whether we’re harnessing change or just unleashing it. Many development organizations still struggle communicate Agile’s business value. If you don’t express yourself in terms of business benefit, business people likely won’t understand you. “Harnessing change for competitive advantage” is all about business benefit. It enables straightforward discussions of value and relevance. If, for example, a company doesn’t want to harness change, or doesn’t believe doing so will confer competitive advantage, then it shouldn’t use Agile (or, for that matter, Cloud or DevOps or …). Plain and simple. I believe that all of the 21st-century IT domains suffer from a certain amount of arguing at the wrong level. What’s the difference between SOA and microservices? Does DevOps work for enterprises? Is PaaS really just orchestration + containers? Agile seems to suffer from this problem even more egregiously than other domains. The centrality of the Agile Manifesto’s Four Values seems to exacerbate the problem. How much documentation is enough/too much? Are ticketing systems evil because they value process over individuals? In general, we get mired in arguments about details when we lose sight of the purpose of those details. Rewriting the Agile Manifesto to just say “harnessing change for competitive advantage” won’t make all the arguments go away. There will still be plenty of room to debate the extent to which any given practice is harnessing change, or resisting it, or just mindlessly unleashing it. I think, though, that this is precisely the level of argument we want to be having.

#agile #devops #cloud

Brands As Promise-Marks

Yesterday I read a tweet that said something about “engaging with brands”. That statement struck me as odd. I hypothesized that a brand isn’t something you can do anything to or with; nor can it do anything to or with you. Instead, I thought, a brand is the result of what you do with and to a company, and what what it does with and to you. Peter Laudenslager made the comment that “a brand is a package of assumptions and expectations…what people assume and expect, true or no, intentional or not”. Something struck me as right about that statement. But where do the particular assumptions/expectations associated with a brand come from? Customers don’t make them up out of thin air. You don’t expect an airline to help you lose weight. You do expect it to get you to your destination on time, with a minimum of hassle. The package of assumptions and expectations you have about the airline evolves over time based on your experience. You may come to assume, for example, that United won’t get you to your destination on time, and that they’ll do it with maximum rather than minimum hassle. This line of inquiry led me to think we might be able to use Promise Theory to model the concept of “brand". Promise Theory treats systems as consisting of autonomous agents that voluntarily cooperate by making, and sometimes keeping promises to each other. Promise recipients are responsible for evaluating the trustworthiness of the promises they receive. Based on their evaluations, they can plan contingencies that help them improve certainty and reliability in the face uncertain, unreliable relationships. Agents' ability to keep their promises changes over time. Evaluation of trustworthiness and contingency planning thus must be dynamic activities. In the language of Promise Theory, a brand starts as a set of promises. These promises constrain customers’ initial assumptions and expectations. United does not promise to help passengers lose weight. It does promise to transport them safely from one city to another. It makes various promises about timeliness, convenience, etc. In the course of doing business, it sometimes keeps some of its promises, and sometimes breaks some of them. The bad news is that United often breaks its promises of timeliness and convenience. The good news is that it seldom if ever breaks it promise of basic safety. A United customer might evaluate the airline's promises and leave extra time in their travel schedule. They likely wouldn't, though, feel the need to update their will. A “brand” is thus “a package of promises made, kept, and broken”. This definition captures the dynamic nature of brands. They can get better and worse over time. It also captures their individual, experiential quality. Not everyone has a lousy impression of United. Some people are lucky enough to have a good flight nearly every time they use the airline. To return to the metaphor behind the word “brand”, we could say that a brand is the “mark” a company makes on each customer. In the language of Promise Theory, that mark is the trace of the promises it's made, kept, and broken with that customer.

Promise Theory intends to be useful, not just pretty. If my understanding of brand is correct, then it would seem to follow that companies can use Promise Theory to help themselves improve the marks they leave on their customers. They can ask themselves questions such as:

What promises are we making?

Are we keeping them?

What promises are we breaking because we don't even realize we should be making them?

Are we keeping the most important promises to the most important customers?

#promisetheory

Designing for Operations

Service-dominant logic tells us that service providers and customers create value collaboratively. Digital infusion means that every business is a digital business, and every service has a digital component. Value co-creation therefore requires holistic, mutual engagement all the way from the customer back to the IT operations organization. Customer satisfaction depends as much on IT system scalability, resilience, and other non-functional requirements as it does on functionality or UX quality. We can see the growing impact of operability on business in Target's recent firing of its CEO, in part because of a security breach. Digital system operability depends on human operators’ ability to manage systems. System administrators need to be able control infrastructure in response to customer needs. In some cases, control implies proactively changing systems: adding servers, tuning databases, etc. In other cases, it means responding to potential and actual problems: a disk is about to fill up, an application has crashed, etc. Sysadmins use a variety of tools to help themselves understand and control infrastructure. These tools are generally not designed from a usability perspective, nor with the participation of UX designers. They tend to be somewhat crude and utilitarian. They arrange their interfaces around data rather than tasks, ideas, or processes. As a result, they offer sysadmins clumsy affordances which do less than they could to help maximize operability. Ryan Frantz's 'Alert Design' post inspired me to think about design for operations. The opening sentence, “alert design is not a solved problem”, grabbed my attention. I realized that, for the most part, design for operations isn’t even an identified problem, let alone a solved one. It occurred to me that operations could benefit from design thinking. We consider challenges such as minimizing cognitive load all the time in the context of consumer interfaces, whether they be websites, mobile apps, or automobile interfaces. Why not do the same in the context of IT operations? If we truly believe in service-dominant logic, and the reality of digital infusion, tackling the problem of designing for operations would seem to be a crucial component of developing quality services.

#devops #servicedesign #sdlogic

Trending Blogs

Recently Viewed Blogs

Ingineering.IT