Building trust is essential to teamwork. It’s critical to working with clients and vital to survival in human nature. Show me a team that doesn’t trust each other, and I’ll show you a team that doesn’t operate at capacity.
Trust is a Prerequisite for Value Delivery
Building trust is the first step in delivering value. Don’t believe me? Here is a strange example, (stolen from Seth Godin) but it illustrates the point. Try this:
Go up to a random house in your neighborhood, (someone you don’t know that well). Knock on the door, and offer them a 10 dollar bill for free. What will happen? They’ll say no, close the door, and peer back at you from between the blinds to make sure that you’re leaving. They will immediately start thinking that you are trying to give them counterfeit currency. “Why is this nut trying to give me money for free?”
Next, pick a different house, and put a 10 dollar bill in their mailbox. The next day, do it again, and again the third day. On the fourth, knock on the door and say “Hey, I’m the person who has been sticking $10 bills in your mailbox. Here’s another one.” This time, they’re likely to take the cash from you with a smile and say “thank you,” because now they know you’re crazy. You’ve built the trust. Now you can deliver the value.
Applying Trust to Software Delivery
Let’s make this more applicable to the software value delivery pipeline. You build a software application, and low and behold you’ve somehow magically delivered every one of your client’s requirements — it’s exactly what they asked of you. When it comes time to do your demo, will the client accept the work?
We don’t know. How much trust is there between your team and your client? If the client has convinced themselves beyond a shadow of a doubt that you are incompetent, incapable of delivering, and intentionally trying to screw him, will it make a difference if your work is of high quality or not?
Are there undiscovered bugs in the system that prevents it from functioning in the way that you understand it too? If there is a lack of trust and transparency within the software team, you probably can’t know the answer to this.
Build Trust First
You only get one chance at a first impression, but the last impression is the lasting impression. In the critical early phases of a new software project, it’s essential to do a few things well.
Empathize
Take the time to understand the situation of your client fully. You’ll want to figure out the following, but you might not be able to ask these questions outright.
– What is their business situation?
– Their place in their organization?
– Who is the person who pays the bills?
– Are they trying to make themselves look good to their boss?
– Are they trying to make their boss look good?
– What is their motivation?
– What is the business goal of the software project?
– Where have they been as a business?
– Where are they headed now?
– Where do they want to be in six months? A year?
– How does your project fit into their picture of reality?
As you increase your effectiveness working with clients, you will eventually learn to be able to answer all of the questions listed under “Empathize” within the first two meetings. You should document this information in an appropriate locale that your team will have access to as they come onboard to the project.
Define
A high-level overview of what the client is looking for is a good place to start. As you begin to unpack the project at a high level, pay attention for ways that you can deliver exceptional value as a team within the shortest possible timeline.
Questions to answer
- What are the most important features that must work for the project to be a success?
- What’s a rough estimate of how long it would take to build out those features as a functioning proof of concept?
- What are the important dates in the future we must hit to be successful as a team?
ProTip™: There is always a deadline. You may have to ask three or more times, each time in a different way before your client finally spills the beans on the drop-dead date.
Get Early Wins
On a Blue Field project, don’t start with Authentication. User authentication is not value-additive, it’s table stakes. If your team is unable to deliver authentication in the first week, it doesn’t mean that your team is terrible, it proves that authentication is a table-stakes feature which includes a constellation of sub-features and every client is going to assume that authentication works (for most web-based applications). There are third-party libraries that you can leverage, but the bottom line is that building Authentication is not value-additive for the client’s software project. If you want to prove your team can build the software the client is paying for, focus on the features that are unique and cannot be serviced by off-the-shelf software packages.
Depending on the Frame of the Project this phase will always look a bit different, but some things don’t change.
Ship something in the first week.
If the project isn’t running on the internet, that’s not a deal breaker, as long as it’s easy for someone to run the project locally. As developers come online to the project, it’s important to give them the same sense of accomplishment by giving them an opportunity to deliver something to whatever the “production” environment is within the first day of joining the project.
Keep Your Client in the Loop
As the course of the project proceeds, there will be good news, bad news, and discoveries that your team makes along the way.
To build trust, it’s critical to keep the client well informed.
I don’t know a whole lot of people who think delivering bad news is fun. You need to give unpleasant news to clients as quickly as possible. Being quick to disclose adversity will help to prove that you’ve got their best interests at heart. Hesitating to provide a lousy update can easily be misperceived as your willingness to be untruthful. Clients need to know that you are working for them with their best interest in mind. That means keeping them informed in an extremely timely manner especially when things are going poorly.
Good news can always wait a couple of days or over the weekend. Clients will already be happy with good news so if it takes you a few days to deliver it, there’s not much risk of the interaction going poorly.
The amount of time that passes in-between when you learn of bad news and when you deliver that report to the client is inversely proportional to the amount of trust you will receive in return.