Relationship Design

Relationship design is an odd phrase. It can call to mind Vance Packard’s The Hidden Persuaders, George Orwell’s 1984, or Aldous Huxley’s Brave New World. But there is a critically important idea embedded in the phrase that deserves all of our attention as we move into an increasingly digitally transformed world.

The idea is a simple one. Designs structure relationships in ways that are unconsciously assimilated. Take education, for example. When I was in grammar school, students sat at individual desks with built in chairs that were aligned in rows, all facing the teacher who stood at the head of the class. This created a relationship in which learning was an individual endeavor supervised by a single authority. When my children entered K-8, they encountered a very different classroom, where students sat at tables in groups of four, and the teacher roamed the classroom. This created a relationship in which learning was a collaborative effort orchestrated by a single authority. How big a difference does this make? Well, when I went to school, collaboration was called cheating, and you were expelled for it! By the way, Bill Gates and I were in school during the same era, so let’s see how this played out in software.

Microsoft grew to prominence on the principle of personal computing focused on authoring and publishing documents, be they in Word, PowerPoint, or Excel, later to be stored in SharePoint (a single authority at the front of the class). Stewart Butterfield went to school with my children’s generation. He founded Slack based on the principle of collaborative communication focused on conversational threads linked to actionable callouts. In between, Drew Houston and Aaron Levie, founders of Dropbox and Box respectively, helped bridge the gap by democratizing file sharing, freeing it from the constricting relationships imposed by SharePoint.

Now, none of these relationships are necessarily better or worse than any of the others. Each is fit for a certain set of purposes. The point to register is simply that design structures relationships that are unconsciously assimilated. This frees the mind to focus on matters closer to hand, all the while benefitting from norms and expectations that are implicitly understood by everyone involved. 

Historically we did this through physical artifacts—library shelves, steering and braking systems, remote controls, and the like. Now, however, in our digitally transforming world, we are doing more and more of this through software itself. But wait, there’s more. With the advent of machine learning and artificial intelligence, powered by ubiquitous real-time computing, we are enabling dynamic relationship design, designs that adapt to changing situations, as a self-driving car must be able to do, designs that can lead to emergent organization in response to novel interactions.

This is heady stuff indeed, and for us mere mortals working in Earth time, we need some kind of framework to help us grasp what is going on and see how it might facilitate our goals and objectives. Now, as anyone who has ever seen my graphic diagrams will testify, I am not a design guy. But I am a frameworks guy, and with that thought in mind, let me propose the following model as a way to get our arms around relationship design as something we can use in the world:

The idea here is to start with outcomes and then work backward from there all the way around to the empowerment needed to achieve them. 

Outcomes come in many forms, and some do not require the full cycle diagrammed above. For example, designing for an instrumental outcome such as an ATM or a vending machine, would focus primarily on structure, and then on empowerment. It wouldn’t worry about relationship or experiences (although both would be present) because the main point is just to get a simple repetitive task done as efficiently as possible. But such is not the case with a communication outcome such as a video conference or a conversational thread. Here interpersonal experiences are core to the outcomes we want to achieve, so it is critical they get lots of design attention. It is no accident that Customer Experience Design and User Experience Design have become fundamental roles on any software scrum team building user-oriented applications. 

The odd man out in this sequence has been the one we are calling out in this blog—relationship design. Given decades of building instrumental software programs to achieve deterministic goals that are relatively static, we tend to go straight from outcomes to structure, letting the relationship chips fall where they may. But how much sense is there in that when, say, you are building CRM applications, for example? The R does stand for relationship—remember? But, to be fair, when CRM software first came out it was never really about the customer relationship at all. It was about a sales relationship, or a services relationship, or a marketing relationship, in which the only person who really mattered was the salesperson, the services rep, or the marketer. Putting in the word customer was our way of putting lipstick on the pig.

Nowadays, that just won’t cut it. Customers have too many choices to put up with abusive or neglectful relationships. If we are truly going to engage and enlist them in our endeavors, we need to apply some creative intelligence to understanding the kind of relationships that empower customers (or patients, or students, or employees, or partners) to contribute successfully to the outcomes we seek. For example, consider the difference between the following pairs of words, each of which can describe the same transaction: selling and buying, teaching and learning, supplying and consuming. Again, this isn’t about a right or a wrong approach, it’s about how each approach might impact empowerment to achieve desired outcomes. Making something easy to sell is not the same thing as making it easy to buy. Making a subject easy to teach is not the same thing as making it easy to learn. Supplying something like a vaccine is not the same as people actually getting themselves vaccinated. In this last case, consider, for example, the recent move from command-and-control distribution through governmental channels to an increasing emphasis on community outreach to engage those alienated by the earlier relationship.

Now, to close, as I have already noted, most of us reading this blog are not designers. But all of us engage in funding outcomes, if with nothing more than our own time, talent, and management attention. And many of those outcomes are dependent upon establishing relationships that are supportive and lasting. Where we fail to specify is exactly what attributes those relationships need to have in order to be truly functional. We talk a lot about values, about mission, even about culture, but we need more design thinking about the dynamics of the relationships that will empower the outcomes we seek. The design community needs to lead us here. We just need to hold them accountable for doing so.

That’s what I think. What do you think?

Follow Geoff on LinkedIn | Geoffrey Moore Mailing List

_________________________________________________________________________

Geoffrey Moore | Zone to Win | Geoffrey Moore Twitter | Geoffrey Moore YouTube