The Trusted Advisor is a book by titans of the professional services industry, David Maister, Charles Green and Robert Galford. It verbalises many of the intuitions that I had about working with clients and building client relationships that I built over the years of working as a technical consultant.

The book is not aimed at programmers or developers, but this doesn’t mean we cannot lift the advice on trust and relationship building into our own day-to-day work. Especially those developers that work in agencies, software houses or consultancies (rather than product companies) will find the content most helpful, though I think that much of the advice is also applicable for those working closely with product stakeholders in product-oriented organisations.

The biggest takeaway that I got from this book is the explicit naming of “intimacy” - the intentional steps to build a personal relationship with the client, focusing on his or her approach to the problem and his or her own position in the organisation. This is also the thing that is most lacking in technical consulting and software delivery, resulting experienced development teams degenerating into burnt-out “feature factories,” rather than flourishing into software craftsmen.

Notes

Generally about trust

• Trust is asymmetric - when we say that trust is down in some capacity, this means either that someone can become less trusting (because of some reason to be more suspicious) or someone can become less trustworthy (for example because of some kind of fraudulent behaviour)
• Trust increases not linearly but in a step function - whenever there are moments of difficulty, these are individual opportunities to increase trust with the client.
• Trust is a two way street and both the technical expert and the domain stakeholder needs to resort to various techniques to get on the same page and see the problem the same way. It’s exceptionally important to be able to explain technical concepts to non-technical stakeholders. One way to do this is via metaphor.
  • This goes both ways. When working on a biotech project, the stakeholders usually employed cooking or baking metaphors to explain the process of tissue processing. We might prime the client to use metaphor to explain a domain concept that we might have trouble grasping.
• The clients are usually driven by either pain or inspiration. Most of the time, pain relief is what we’re actually hired to do. The authors say that pain relief is the reason we’re hired about 80% of the time, while inspiration is about 20%.
• There are two kinds of risk - of commission (fear of doing the wrong thing) and of omission (fear of not doing the right thing). Most people are so paralysed by the fear of the first kind of risk that they will often commit the second kind, which is usually more insidious and harmful than simply doing the wrong thing.

Giving advice

• Even if you are right and your advice is good, the client might not be interested in it and will likely not follow it until you have earned the right to discuss the problem statement and provide solutions.
• One of the exceptionally important things when building trust is making sure that the client understands that you understand his problem. To make your advice effective and to be able to be perceived as a good technical partner, you need to show to the client that you understood the assignment.
• Sometimes we feel like the client acts like a petulant child that just needs to be told what is the correct course of action. But a better technique in those cases is to imagine them like an ageing parent. When faced with lack of understanding, it’s easier to act as if we were advising our parents. It’s more likely that we will be able to find the right words to convey the point with respect, and softening any critique. The parents might have trouble understanding, but they have the final say.
• Before we earn the right to give advice, we have to start building trust, and the first step is usually to defuse defensiveness. We have to prove that we’re there to help, not criticise. You can be the first one to let your guard down to demonstrate the willingness to lay bare the problems that the client faces.
• Without shared understanding of the problem and the client’s interests, no good advice can be given.
• Clients don’t always want advice, sometimes they just want a sympathetic ear.

The trust equation

$T = \frac{C + R + I}{S}$

• Components of Trustworthiness:

  • Credibility: how good we are at what we do, and how much we can be believed.
  • Reliability: how good we are at meeting expectations, keeping commitments, promises and deadlines.
  • Intimacy: how invested we are in the project and the relationship with the client, and how much the client can trust us by showing vulnerability.
  • Self-orientation: how much we focus on our own interests and not those of the client.

• For many clients, credibility and reliability will be entry factors at early stages of a trust interaction. They will deal with intimacy and self-orientation only after having been satisfied about credibility and reliability.

On intimacy

Specifically, since developers tend to believe that credibility and reliability is all that’s neecssary from a technical professional:

• Intimacy, notably, does not refer to anything personal. We are invested emotionally in our professions and in the business, and in those cases we seek understanding and the human connection. We can build intimacy and have a close relationship with the client without knowing anything about his life outside of work.
• Clients will not volunteer the idea that they want a deeper, more intimate relationship with their service providers. But at the same time, they will be the first to say that a primary criterion for engaging the services of a developer is the understanding the provider has of their specific situation (not just “situations like this in general”). This is what intimacy means in this context.
• Creating intimacy requires courage, not just for you, but for everyone.
• Curiosity is a good driver of intimacy.
• A tactic to demonstrate willingness to invest in your client and to build intimacy is (to make an analogy to romantic relationships) to bring a gift on a random weekday rather than a birthday or anniversary. So for example you can cook up a quick demo that you show them outside the usual cycle - not during your regularly scheduled demo or iteration review. “Hey, I’ve been thinking about the problem that we had and I brought you a little something that I’ve been toying with to explore this further.” This shows that you are personally invested in the problem, and, simply, that you care.
• You don’t need to spend a lot of time to start building intimacy.
  • An example of building intimacy from the very outset is joking about name pronunciation - either being self-deprecating about the difficulty of Polish surnames, or putting in the extra effort to correctly pronounce the names of the interlocutors. Example - working with the Portuguese they really appreciated that I was able to pronounce their names correctly, because I put in the ten minutes before the call to practice.
• You can build intimacy even as a technical professional. It is not just your project or account manager’s job to build intimacy with the client.
• Intimacy is often mischaracterised as just “politics.” However, it is required to understand problems in all their emotional and political complexity.
• One of the most important qualities in a trusted advisor is that he is not a sycophant. He is not Claude who tells you “you’re absolutely right” all the time. It is very important as a trusted advisor to be able to tell the client that he is wrong, and you need to be able to do it with tact and care.
• Socialising with the client is not necessary, but being sociable is. In my experience, relationships with clients improved tremendously when we had an opportunity to meet in person. Socialising is the window into the client’s needs, hopes, and fears.

On credibility and reliability

We build credibility by increasing our technical skills (learning new languages, frameworks, workflows, technologies…), but we often fail to showcase them properly to the client.

Credibility

• Figure out how to tell as much truth as possible, except where doing so would injure others.
• Don’t tell lies, or even exaggerate. At all. Ever.
• Avoid saying things that others might construe as lies.
• Speak with expression, not monotonically. Use body language, eye contact, and vocal range. Show the client you have energy around the subject at hand.
• When you don’t know something, say so, quickly and directly.
• Make sure you’ve done absolutely all your homework.
• There’s no reason to show off.
• Use silence to your advantage. When you said what had to be said, wait for a response.¹Marginnote voss1Silence is a powerful conversational technique. It’s also terribly unintuitive. For non-native Engilsh speakers, or those unfamiliar with the conversational styles of Americans specifically, or those otherwise finding client conversations stressful, Chris Voss’s book Never Split the Difference and associated material is a useful toolbox of conversational tricks that help with keeping cool, extracting information and making discussions more productive. They don’t work that well outside of the anglophone culture, curiously. ↩
• Relax.

Reliability

• Make specific commitments to your client around small things: getting that feature out by tomorrow, writing down that Jira ticket today, looking up a reference right after the call. And then deliver on them, quietly, and on time.
• Don’t “overpromise and underdeliver.” Promise what is manageable and deliver what was agreed upon.
• Set the meeting agenda and send the materials in advance, so that the client has the option of reviewing them in advance, saving meeting time for substantive discussions. This is even more important if there is small or no timezone overlap.
• Make sure the client meetings have clear goals, not just agendas. At the end of the meeting, summarise what was said, restate the action items, and make sure the goals have been met.
• Review agendas with your client: before meetings, before discussions, before workshops. Clients should know that they can expect you to always ask their opinion about how their time will be spent.
• Respect the client’s deadline, even if it’s artificial or arbitrary. If it’s unreasonable, it’s better to ask for an extension, or even argue about it, than miss it. If you know you’re going to miss a deadline, or it’s very likely, make it known as soon as possible.

Stages of building trust

1. Engage: use the language of interest and concern: “I’ve been thinking about your problem…”
2. Listen: use the language of understanding and empathy: “Tell me more about…”
3. Frame: use the language of perspective and candor: “So what I’m seeing emerging here is…”
4. Envision: use the language of possibility: “How do we know that the problem is solved? What will your work look like, then?”
5. Commit: use the language of joint exploration: “What would it take for each of us to…”