Building trust with your customer

Trust means we can depend on future action

It is common to speak of building trust within a project team.

We debate ways to build trust, how we break trust and to what extent this “trust notion” is important anyway.

I have written about trust building with regard to noticing the implicit promises we make each other, and how very “real” they are to us in terms of consequences even though we don’t know they exist.

I know some cynics who say that trust does not exist… but I also accept that is how a true cynic might see it, and I move on.

So in this post, I want to talk about the trust we build with our customers… something relevant to every technology leader. (Actually, the core reference for my post above had to do, in part, with a marketer’s perspective of software developers.)

Revisiting components of trust

I have introduced a distinction for trust as:

An assessment of sincerity, reliability and competence to hold our promises for long horizons of time

You might use a different distinction, but I offer this one as the basis for the rest of this post. It is a standard distinction produced and taught by The Aji Network, which you know if you follow me is an educational discourse of business professionals with whom I have learned and grown professionally.

Actually, when I say “long horizons of time”, it is more specific to say “as long as needed”. If you trust me with a promise not to tell about a surprise birthday party… I am off the hook for that promise after the event.

So what is our task?

You can't keep any promises you don't make

Given that distinction for trust, we only build trust with our customers when they assess we are:

  1. Sincere – we mean what we say
  2. Reliable – we recurrently do what we say
  3. Competent – we’re not claiming a skill we don’t have

AND… we have to hold our promises [for as long as needed].

The thing is, if we don’t make any promises, we can’t build trust.

Now, I’ve heard some people adopt this as an intentional strategy – if we don’t make promises, they can’t distrust us. Actually, the opposite is true — if we don’t make promises, our customers WILL grow to trust us — to NOT take care of them.

We can’t hide demand by ignoring it exists (or saying “no” to everything), and we can’t build trust by saying “yes” and failing to deliver. So what is left for us to do?

The natural human planning cycle: 90 days

Here are two examples from domains outside software projects:

These books have at least one thing in common – they both refer to the human psychological implications of 90 days as a powerful window for planning.

Things change a lot in our business lives, and in the business lives of our customers. That is one reason we gravitate toward agile, or at least to short-cycle projects. Here we have two examples of other domains that suggest a familiar theme – give yourself space for feedback and time to adapt… and don’t pretend to know everything.

So let me offer this natural human planning cycle as consistent with a powerful move to build trust with our customers. Don’t delay a release unless something drastic has happened. Communicate clearly and confidently about what will be “in” the release, but don’t miss the ship date.

Over time, your capacity to recurrently hit ship dates (reliability), with solid features (competence) as you have said you would (sincerity), you create the opening to change the moods and attitudes of customers who might have great reasons not to trust due to historical patterns.

One strategic purpose for building trust with customers

There are many reasons to build trust with customers, but I will leave that to another post.

Today, I just want to link back to a past article I wrote about the role of project managers to hold customers to their end of the bargain – that they take receipt of our products. Not every team has this problem because they have their customers’ trust.

Some teams don’t have the problem because they have psychologically strong coaches who can force acceptance on their customers regardless of trust. (I haven’t directly observed this, but I leave open the possibility that it might exist.)

For the rest of us, not having your customer’s trust means they may become over-demanding, asking for more because they know they won’t get it all. They may get beaten down and stop asking for your help. Or I don’t know if this is worse, but they may take their budgets and look elsewhere for help.

They are not “wrong” in acting that way… but you can get ahead of them by investing in building their trust. Find promises you CAN make, if you can’t do everything. (Who can?)

…and deliver on those promises, consistently, competently, sincerely and recurrently… for as long as needed.

Modeling the world in Post-It notes

A wall of story cards

Neon colors brighten rooms without windows... and make your eyes go buggy.

I decided to take a little break today and write something a little more on the creative and fun side.

I hope you don’t mind.

If you wanted one of my more serious posts, please jump here for another topic or come back tomorrow and enjoy the time I gave back to you today.

Here’s my creative context: I am working through some thinking practices as I deconstruct and reconstruct a client’s business domain.

A bazillion multi-colored Sharpies surround me, plus self-adhesive easel pads, colorful charts, spreadsheets, documents and process flows.

I love being surrounded by information and knowledge, and I love to sprawl. Bringing order to this kind of mess is the Great Puzzle we get to solve every day in IT, right?

(To be clear, when I say “mess”, I mean my war room, not my client. They know the truth!)

How could I ever run out of sticky notes?

But with all this joy surrounding me, I just realized I have no sticky notes (besides the ones on my laptop screen)… which reminded me of one of my newest Cyber-friends out in Australia, Alicia Dudek, and her post titled “Post-Its and the Real World”.

Alicia is pretty creative and though I have only known of her for a few weeks now, her creativity has a contagion to it that I really enjoy. Check her out if you are in that frame of mind. (If you got this far in my post, you just might be…)

So what’s the big deal about stickies?

I’m glad you asked.

When I first learned Extreme Programming, I learned about physical cards. I taught my teams using 4″x6″ cards, figuring they are big enough to see, hold and write on.

They are also more fun to tear up than 3″x5″ cards (which is a ceremony for my teams).

And then when I discovered office supply stores made them in all sorts of colors… including various neon shades, I was STOKED!!!

Story-tracking software

You know, I did use some story tracking software packages on a few projects… but I found that having the physical card was a visual clue to everyone on the team about how we were doing.

In addition, maintaining cards in software carries a fair amount of administrative burden… though it does produce nice reports and graphs.

But I was never a Post-It kinda guy. I rarely stick them anywhere… I just write on the top one, and maybe push it across my desk somewhere. More often, I complete the item or list and throw the sticky in the trash.

It looks like even Winston Churchill had stickies in his (real) war room... look on the back wall. Yes, I know they hadn't been invented yet.

So when I got to Alicia’s “Post-It post”, I realized how much stickies might be used in software development… and not just for site maps

Then I did a little research, and found out that more people use them than I thought:

  • I can see how their smaller form factor might keep your stories smaller.
  • I can see how requirements can’t get too big when your means of recording them is so small.

But how do you write on the back? What happens when the glue stops sticking?

I don’t think I am going to convert.

Oh, and now that I look… I seem to be low on 4″x6″ cards, too.

So this is something of a creative day off for my blog… soon I will write about Sprint holidays (but not yet).

If you got this far, you must have an opinion… stickies or cards? 3″x5″ or 4″x6″? Story software, or physical cards?

And why do you have a preference? There are no wrong answers, as far as I can imagine.