In 2006, Stephen M.R. Covey and Rebecca Merrill authored the book “The Speed of Trust: The One Thing That Changes Everything”. The authors make a compelling business case for the real and quantifiable effects of building trust in organizations. They state “When trust goes up, speed will also go up and cost will go down.” The inverse is also true. “When trust goes down, speed will go down and cost will go up.” High trust organizations demonstrate less bureaucracy, lower turnover, enhanced innovation, and better execution. Our modern global, knowledge worker economy revolves around partnering and relationships. Covey goes on to assert that the ability to establish, grow, extend and restore trust with all stakeholders is the key leadership competency of the new, global economy.
The book discusses how trust can be built, or rebuilt, by improving thirteen relationship trust building behaviors. The following are my comments on four of them: keeping commitments, practicing accountability, confronting reality, and delivering results.
1.) Keeping commitments is what Covey and Merrill call the “Big Kahuna” of all trust-building behaviors. While that may be self-evident, what is less obvious, and more interesting, is how rarely real commitments are actually formed in most business relationships. In place of real commitments most people substitute loose, mostly implicit statements of “Well, I’ll do my best” or “I’ll try”. The reasons for this behavior are also obvious – the person being asked to do something wants as much “wiggle room” as possible within which to make the delivery so they will not disappoint the customer; and the customer, knowing this, does not want to press for a firm commitment. Each of the parties is complicit in the vagueness: the performer fears non-completion and the customer fears confrontation. The truth is in our modern business culture we stink at making commitments. Most of the time commitments are vague or never actually made in the first place. This is not to say that performing “best efforts” does not build trust, but forming and delivering on real commitments builds trust a lot faster and a lot better.
2.) Practicing accountability is much more than honoring due dates. Yes, practicing accountability entails saying what you’re going to do and doing what you said, but underlying the obvious is the nature of the dialog that is going on between two people. A complete conversation between a requester and a performer with the power to really build trust depends on factors such as:
- how well the request was formed,
- whether the intended performer was given the opportunity to negotiate the terms of the delivery,
- whether an explicit agreement was made,
- the degree to which the dialog continued throughout the delivery, and
- whether the delivery was formally acknowledged.
The quality of the dialog between the two parties is even more important than recording the assigned due date. (See other posts that expand the discussion on Accountability)
3.) Confronting reality often means sharing “bad news”. The performer has the burden for demonstrating this behavior right from the start of the conversation with the requester. While the request is being formulated and an agreement to deliver is being crafted, the performer is bound to forthrightly relay their concerns, problems, and contingencies so the requester has a clear sense of the expectations of the performer.
The performer should not accept a task they do not believe can be achieved. Standing up for reality at the outset builds trust. Must of us have run across counter examples of this – a work colleague who always agrees, although he knows he cannot do everything to complete the request. Some components of the request will not be completed, not fully completed or completed on time and to the expectation of the requestor. Sadly the requestor or customer will often not know this until very late in the game. Through fear of being viewed as not a team player, or of losing his job, he believes he cannot say no up front.
Once an explicit agreement is forged, the subsequent delivery of “bad news” is even more important. The project is properly planned, tasks have been assigned, and then, as we all know, s- – t happens. It is common knowledge and more or less taken for granted that we learn more about the nature of the task after it has been taken it on. That new information comes to light is not the issue. The key to building trust is how quickly and clearly the new information is shared with the requester/customer. Waiting to report problems until the Friday staff meeting builds far less trust than a private communication on Tuesday.
Effective software design can facilitate sharing “bad news” during the delivery stage. Simple tools like red/yellow/green “traffic lights” enable the performer to quickly and easily signal concerns to the requester. The goal is to prompt earlier and earlier notice of problems when working around “bad news” or changing plans is easier.
The manager/requester is as important to the entire process and shares the burden of confronting reality when it comes time to acknowledge and assess the delivery. Performers learn very fast how much they can trust their manager by the consistency and honesty with which deliveries are assessed. If it is good work, the message should be clearly and succinctly delivered – at the right time; conversely if it is not good work, the requestor/manager should provide in a proper dialog what was not satisfactory and how to improve on delivery and possibly help in the delivery for the next set of deliverables.. Trust is not built, and the organization does not learn, unless clear feedback is provided on whether the requester was satisfied with each delivery.
4.) Delivering results is the natural outcome following from the above three behaviors. The performer and requester have made a clear agreement, accountability is palpable and shared in the conversation, and each of the parties openly discuss in a straightforward manner any problems or concerns as they come up.
Note, however, that this behavior is about more than just completing the task by the agreed due date. Sure, the baseline for measuring results is tracking that the task was completed on time, but one should consider a broader definition of what constitutes results. In the context of this discussion, an additional result is the degree to which your “trust account” was added to or debited during the entire conversation. There is also a virtuous cycle of trust – those you trust are monitored less closely (i.e. management productivity gain), their confidence builds, they feel more empowered, they perform better (i.e. staff productivity gain), and they earn more trust.
Delivering results on a consistent basis builds a reputation for trust. The requester as well as the performer benefit from having a robust historical record of past deliveries. Reputations should be built as much as possible on objective data, not subjective and imperfect memory. It is surprising to note how few task and project management applications actually save records of completed deliveries that can provide this objective, historical view of deliveries.
In summary, work management applications that are sensitive to the issue of trust can effectively facilitate and encourage the practice of these trust-building behaviors. Software can help individuals and organizations build trust – the one thing that changes everything.
Pingback: Trust Bestowed or Earned – Which Comes First? | Conversations about Commitments