How to build rapport

rapport
relation; connection, especially harmonious or sympathetic [dictionary.com]

First a confession: ten seconds ago, when I wrote the title of this article, was the first time I ever typed the word rapport. You see, I wrote a blog post about the essence of trust yesterday, and while giving it the last finishing touches, happened to look up the synonyms of “unity”. And there it was: rapport, the word I had heard many times but which somehow hadn’t found its way into my active vocabulary. With the new expressive power I could now compress the post into a single sentence: “Rapport is good.” I considered publishing it but decided to write this instead.

Now that I have established my expertise, let’s move on to the subject matter.

If you read the short Wikipedia article on rapport you will see that it is all about tricks: mirroring, reciprocity, commonality. You may get a feeling that rapport is sleazy or not important. Nothing could be further from the truth.

Rapport is the fundamental building block of trust, and thus the basis of teamwork. In my mind, trust has three aspects:

  1. Trusting that others do as promised.
  2. Trusting others in such a way that you can be yourself without a fear of ridicule.
  3. Rapport.

If you have the first two and not the third, you have a team that functions, but does not function well. You recognize such a team because they don’t talk much to each other. They don’t hang out. It is just eight hours of TODO list and then go home.

Rapport brings joy to our lives. Without rapport, we are just individuals, competing for getting whatever it is that we are after. With rapport comes joint purpose (or it may be the other way around; nevertheless one tends to come with the other) and we are no longer separate.

Rapport comes from honestly trying to understand the other person. By the word honestly I mean that if you don’t really understand, you should say so. Which can build rapport on another level — agreeing that we don’t agree may sometimes be enough.

Rapport exists in interaction, in discussions. I touched this already in an earlier article. While conversing, you are continuously building a framework for that same conversation — an imaginary world if you will. You are allowed to build on top of it, add details to it, and you are allowed to add boundaries around it, but you are not allowed to tear it down, lest you lose the rapport. Every conversation has some framework it exists in. The willingness of participants to accept the framework (even if it is only for the sake of the conversation) largely determines its degree of rapport.

Let’s say you are an atheist and you go to a bible study group and the topic is the meaning of miracles of Jesus. If you say that there is no meaning because there is no god, you destroy the rapport. Why? Because there is an unarticulated but obvious hypothesis in that setting, and the hypothesis is that god exists. By saying that there is no god, you have destroyed the framework that the conversation relies on.

(Out of interest, I did go to a bible study group once, accepted the hypothesis for that evening and it was wonderful. Such warm people.)

The skill of rapport is the skill of imagination. When you talk to someone who thinks differently, what you need to do is to imagine the world where his or her viewpoint is true. You may not agree with it entirely, but you can use your imagination to accept it for the sake of the conversation.

Another skill you need is reading the situation. What is the framework of this conversation, what hypotheses does it rely on? If you cannot read the hypotheses, you don’t know what is allowed in the conversation and what is out of bounds, and you will not build rapport unless you are lucky.

But what if you actually need to say something that is not supported by the current framework of the conversation? What if you feel that the hypotheses of the conversation are wrong? If you are not in a hurry, the easiest thing may be to wait for another opportunity, then carefully craft a conversation with a framework that is right for what you need to say. Intelligent people can imagine a lot of hypotheses, so this should not be a problem.

Continuing from the example above, if you want to talk about the existence of god, the bible study group actually may be a perfect place for that. You just cannot bring that up directly in a discussion about the miracles of Jesus. What you can do instead, is to tell the group beforehand that you don’t believe in god, that you would like to talk about it, but that you would like everyone to discuss it objectively without anyone trying to convert anyone to their side. This is a setting that works, assuming that everyone is sufficiently open-minded for the duration of this conversation.

If you are in a middle of conversation and want to bring up a framework-disputing fact right then, you need considerably more skill. You have to be very clear that you are dismantling some hypothesis of the conversation, and you are only doing that because you feel that the conversation with a new set of hypotheses would be more relevant than the conversation with the current hypotheses. And because on some level your new hypotheses are still competing with the old ones, you have to introduce them in a very engaging way.

So the people with the greatest ability for rapport tend to be those that are good at reading the situation, attempt to honestly understand, have a great imagination, and can rebuild the framework in an engaging way. Here’s an example of all those powers in action. Answering a non-scientist’s question about magnets, Richard Feynman sees the unarticulated and unhelfpful hypothesis that fundamental physics can be meaningfully explained in lay terms. He uses a lot of imagination to engagingly build a framework where that hypothesis is not true, and then goes on to give the best possible answer to the original question, an answer that would have been totally unsatisfactory without the dismantling and rebuilding of the framework. Result: rapport and understanding.

So, Antti’s guide to building and maintaining rapport:

  1. Honestly attempt to understand
  2. Read the situation to see the framework
  3. Use your imagination to work within that framework
  4. Don’t break the framework
  5. Carefully dismantle and rebuild the framework if you need to

Speed by removal

If the goal is to get software out fast, a way to get there is to remove unnecessary work. Like this:

Contracts over the project scope. Plans change. Contracts either slow work down by necessiating negotiation before change, or speed it up by making change as easy as possible.

Deadlines. They seem like a good idea: by promising we will be ready by some day we commit ourselves to stripping away the unnecessary work. The problem is that committing to a deadline requires us to make guesses about the scope and implementation of the project before we have the required information. If our guess turns out optimistic, we miss the deadline. If it turns out pessimistic, we have unnecessarily postponed the delivery.

Coding. Many problems can be solved with a pen and a paper, or using existing software. Developing code is slow and expensive.

How we measure progress defines how we work

We want to be fast and reliable in our work, so we want to measure our progress. The question is what is the right scope for the measurement? When do we start the clock and when do we stop it? This is a fundamental question that in practice defines the way we work.

Let’s say the phases of our value chain — be they implicit or explicit — are like the picture on the right. To start with a narrow example, if we choose to measure our progress from the start of coding to the end of coding, that drives us towards very careful up-front planning and design of the system. We will want to be sure that when we start the coding, we will have as thorough understanding of the system as possible. We will be using something akin to waterfall as our development method.

On the other hand, if we measure from the start of the idea to the end of coding, we will end up with something like cowboy coding. We want to do as little design as possible, because that takes time from coding, which is the crucial part. We don’t need to care about testing, because that is out of our measurement. (Cowboy coders, almost by definition, don’t measure anything explicitly. But the argument goes in the other direction: if we measure things this way, we end up with something akin to cowboy coding.)

What measure leads you to Scrum? The methodology itself does not mandate where the boundaries are, but the way I have seen most Scrum teams implement it, is from the start of UI design or technical design to the end of testing or deployment. In theory, these kinds of Scrum teams strive to deliver working software but don’t care if it actually produces value or not. Product owner should take care of that part, although it is a bit more complicated than that in practice.

The things we measure set in practice the boundaries of our business. Even though we may focus on a certain part of the process—e.g. from IX design to deployment—if we choose to measure our success more broadly—e.g. from end to end—we will become invested in the result of the broad interpretation. This entails that we will in one way or another want to help our customers and suppliers in doing their part of the work.

So what is the right measure? There are two conflicting forces pushing us to different directions. What the business ultimately wants is quick creation of business value. But on the other hand, work is easier to organize and buy when it is modularized with clean interfaces. For example, if a company modularizes interaction design well enough, so that its input and output are clearly defined and of good quality, then it is easy to buy IX design from that company, and the measure of progress from the start of interaction design to the end of interaction design makes sense.

In my experience, success is often measured too narrowly, leading to many of the problems in our industry. The earlier in the process you start the clock the more adaptative the process will be. Likewise the later in the process you stop the clock the more relevant the feedback. Development of complicated software is not good enough yet to use modularized approach in its value chain. We need a more integrated approach.

Looking in the eyes

When I was in the seventh grade, I used to walk past this dog every day on my way to school. It was a small dog – some kind of a poodle, I suppose – but it guarded a big house and took its job seriously. Every morning and every afternoon when I walked past the house, it barked furiously. I was annoyed so I planned all kinds of schemes how to get rid of the wretched creature. In the end I chose to execute the simplest one of them, which was to stare it to death.

So every day, I would stare at the dog right in the eyes until I had passed the house. At first the dog barked at me like it had before. But in the matter of weeks its barks turned softer and then muted completely. My staring didn’t result in the dog’s death but it did the next best thing: the dog recognized me and didn’t bark at me anymore.

It was autumn then, and for the winter the owner kept the dog inside. At the start of the spring the dog came back to its guarding routine, but it didn’t bark at me anymore. I walked past that house to school for the next two years. Only once I talked to the owner of the dog. She said: “I wonder why the dog barks at everyone else and not you?”

That’s actually a good question. Obviously it was because of my looking the dog in the eyes, but what was the ultimate reason? Had I established that I was the master and it the servant? Or did it consider me someone familiar and of equal status, its pal?

I’ve come to believe the latter. When we look someone in the eyes, we acknowledge that they exist, are worthy looking at, and that we are not afraid. It is a good start.

Answer the Right Questions with Prototypes

Prototypes validate ideas. Rather than basing plans on guesses, you create something concrete and put it to the test. But what kind of a test? That depends on whether you are aiming for a sustaining or a disruptive innovation. The distinction helps us ask the right questions and build the right prototype. As a consequence we eliminate waste and create an effective innovation process.

I posted to Leonidas blog today: Answer the Right Questions with Prototypes.

Camelot is only a model

Sir Lancelot: Look, my liege!
[trumpets play a fanfare as the camera cuts briefly to the sight of a majestic castle]
King Arthur: [in awe] Camelot!
Sir Galahad: [in awe] Camelot!
Sir Lancelot: [in awe] Camelot!
Patsy: [derisively] It’s only a model!
King Arthur: Shh! [imdb]

Forbes has an article of Clayton Christensen’s recent keynote. It’s easy to read as a crititicism of profit maximization and business schools.

But they are not the real problem. The real problem is taking a model and thinking it is a precise description of reality. Every model has its limits.

The last thing we need now is blind following of a new model. As much as customer centricism and net promoter score are good things, profit maximization and ROI are still as useful as before. All of them are tools that help us understand the reality better, not replacements of reality. They are not more than that, but not less than that either.

Let’s not go to Camelot. It is a silly place.

Arguments don’t create decisions

Arguments don’t work like we would want them to. It is essentially impossible to change someone’s mind with factual claims. Why is that?

Here’s an example. I happened to read a book by Stephen Hawking and Leonard Mlodinow yesterday. It is called The Grand Design and it tells about recent advances of modern physics and their philosophical implications. Let’s say we have an argument whether reading this book is good for my career as a software developer. I come up with these arguments:

  • Reading something out of my field is good exercise for my brain.
  • If I ever write software for related to modern physics, I understand a bit of the background already.
  • There must be non-obvious parallels from physics to the software world. Reading this book gives an opportunity to see software development from a new point of view.
  • Understanding the deep questions about our existence gives truer purpose to the work we do.
  • If quantum computing becomes available during my career, I already understand a bit more of its background.
  • If it turns out some client or partner is interested in this kind of stuff, understanding a bit about this provides an opportunity to strike an interesting conversation with them, improving trust etc.

The arguments I present here are probably all true to some extent. The problem is that I could come up with a similar list of arguments about any book, or pretty much any activity I do.

It is not enough that arguments are true, you must weigh the arguments too. Each person gives weights according to their own priorities and values. Presented with the same arguments, two people will come to different conclusions.

There is value in arguments, but in the end, decisions are made with intuition.

Agile charted

Here’s how I think of agile.

Traditional software development has the problem that it gets feedback only after it has lost its ability to make relevant changes.

Agile on the other hand aims to get the feedback quickly while still having room to maneuver.

The upper right-hand corner of the chart is the sweet spot for development. It is the place where learning is possible and true innovation can occur. This is the heart of agile development. If your agile process leads you to the lower left side for whatever reason, you are doing it wrong.

I’ve pessimistically drawn both arrows’ ends’ in the lower right. From innovation point of view, the goal of course is to stay as long as possible on the upper right, and for example Facebook has kept in that general area for admirably long. But there seems to be a very real gravity that takes successful products down on the chart. This is The Innovator’s Dilemma: successful competition in an established market requires sustaining innovation, and companies that invest heavily in it tend to lose their ability to change direction. (Example: Nokia’s phones in 2000-2010.)

But while the individual products and product families are brought down by gravity, a company may escape it by cultivating disruptive innovation. Apple and 3M show that it is possible, but it appears to be very hard, since there are not many companies like that.

Great conversations

Some conversations have this warm sense of companionship. Why do some discourse have that and some do not? I talked about it with my girlfriend the other day and I think we found something. Let me try to describe how I see it now.

Talk is just talk. It is not a description of reality, not even a description of our understanding; these are more complex than can be put into words. True agreement is an illusion – we cannot understand each other fully.

The surest way to kill a conversation, therefore, is to aim for absolute truth. When you try to make sure everything you say is correct, a few unfortunate things happen: the pace of the conversation slows down, it becomes very serious, and you become irritated when the conversation doesn’t lead to the way you see the world. Consequently the conversation becomes less stimulating and attendees start to drift off.

When you accept that you will not be able to convey your exact thoughts or feelings to others, a positive feedback loop appears:

Another way to look at it is that great conversation is story-telling. The number one thing for a good story is suspension of disbelief. As long as the reader accepts that the events are believable in this story, the story makes sense. In great stories most events stem from the story itself, and are not introduced by the author’s will.

So it is in great conversations. First you create the setting, and then you go wherever the conversation takes you. You accept that you don’t know where it will end, and you dive in. Isn’t that stimulating?

Business vs. development

A friend said to me this week that he left his previous job because the balance between business and software development was skewed too much towards business. It was all about the profits for the company, he said.

If you think this way you have already lost the game, and you will not be satisfied with your job.

First of all, you are missing the most important player from the picture: the client.

Secondly, this isn’t a zero-sum game. We are not dividing a pie into three, we are creating new, larger pies. In every software project I’ve experienced there have been huge untapped opportunities to help the client, to push the boundaries of how we are helping him. (And this includes some very unsuccesful and very succesful projects.)

As long as you focus on the division of the pie, you miss the opportunity to do truly valuable work.

Follow

Get every new post delivered to your Inbox.