It was one of my father’s favourite phrases.
“Trust, but verify.”
I’m pretty sure it was something close to a mantra for him. I remember when he was in the hospital for the very last time, and he asked me what day it was. I told him, and we carried on. About an hour later, though, while a nurse was on her rounds, he asked the question again. “What day is it today?” He had forgotten, and as I watched, he remembered that he had forgotten. Then he remembered remembering, and who had told him. He looked at me, winked, gave his little sarcastic grin, and offered up, “Trust, but verify.”
That encounter has stuck with me over the years. The statement has endured, as well. It’s one that I have come back to many times since. Interestingly, it’s not a saying that I have used a great deal. But I have thought about it a lot, and reflected on its purpose and its intent.
It’s a very simple statement. Only three words (and one of them is “but,” so you would think it’s not going to be that difficult a concept to unravel). But it hides a great deal of complexity. You can spend a lot of time thinking through the statement’s implications (trust me, I have).
To trust is to put your faith in another. It presumes that they are honest, reliable, committed and capable. When you trust someone, you are placing confidence in their abilities, and their capacity to deliver. You are assuming that they will meet your expectations and deliver the results that you seek and that you value.
To verify is to test and confirm that you have received what you expected. You are validating the accuracy of information, the relevance of advice or the quality of what has been produced. Verification is confirming and substantiating what has been delivered is what was sought.
There is an inherent tension here, which is what gives the phrase its power and significance. Absolute trust shouldn’t require verification. The implication of trust is that you take on faith what you have been provided or what you have been told. To question that—to take independent action to confirm—is to theoretically undermine that trust. The act of verification suggests that you might not trust at all.
If we take heed of both dimensions of “trust, but verify” we are left with a conundrum. How much do you trust? How much do you verify? How much can you believe, and how much do you need to confirm for yourself? Moreover, how much verification is really needed in the face of trust? And how much verification ultimately undermines trust and how it is perceived? This is the delicate balance that we have to find. As always, there is no single, clear, right answer. It once again depends.
Ultimately, “trust, but verify” is a sliding scale. The right answer is going to depend on degrees. The more you trust, the less you may need to verify. The more that you lack confidence, however, the more follow-up you are going to require. You may need to test, to evaluate, to confirm and to contest. Where trust is very low, the amount of follow up required may be very high indeed. Somewhere along that scale is also the tipping point of, “it’s easier if I just do it myself.”
It’s also a scale that works both ways. It is a caution, but it is also a signal. The more that you verify, the more that you may also be communicating that you do not trust. That has its own overtones to be managed An excess amount of oversight, scrutiny or questioning may well be perceived as not just lacking in trust, but being downright hostile. By the same token, not verifying at all—theoretically trusting completely—may come across as neglect, indifference or simply not valuing what is being done. “Trust, but verify” is a concept with consequences.
The idea of “trust, but verify” has practical implications in my consulting as well. This is particularly true in the area of client involvement, and client feedback.
In a statement that will be unsurprising to many, I am not a fan of micromanagement. In particular, I am not a fan of being micromanaged. I do not take to it well at all. Those few instances where a client has attempted to micromanage my work have not gone awesomely. The relationship suffered, and the work suffered.
One client demanded a statement of work that detailed out each of the interim deliverables to be produced, and then expected to see each interim deliverable, done, complete and on time. The work was a project audit, which by its nature is an exploratory and evolutionary process. Audits are not linear. You do not review, investigate, analyze and report, proceeding from one step to another in logical sequence.
As written down on paper, of course, audit processes—like so many others—appear to be exactly this linear. This is an inherent fault with how we explain process, rather than how we live process. The actual reality of doing the work is always messier, more complicated and more convoluted than it looks on paper. You go backwards and forwards, you reach branches and jumping off points, you hit roadblocks, and you double back and try again. This is the normal process of doing work, and it is the absolute opposite of being linear.
What the client was looking for in this instance was verification that I was in fact proceeding through the linear process I was in theory following. He wanted to see an outline, and then a detailed outline, and then an early draft, followed by a refined draft, followed by the finished product. This is not unlike how creative writing is theoretically taught in grade school, and involves the same stages. The problem is that I don’t work that way, and I never have.
Apart from the investigation of an audit being convoluted (as later findings may cause you to circle back and revisit earlier assumptions and observations), very often so is the writing. Reports require a logical cohesion, and there is an art to writing plainly and clearly what you have observed, what it means and what you recommend. Theory once again says that this is best supported by working through the linear process of building structure and filling it out. I just don’t write that way. Any time that I have been required to produce an outline—or worse, a detailed outline—I have done so after the fact.
Outlines are not part of my design process, apart from the roughest understanding of the structure of what I am producing. They are not instrumental to how I write. I cannot start writing until the whole picture of what I am producing is clear in my head, and once it is then it is coming out whole in one complete brain dump (and before you ask, my books and my doctoral thesis pretty much worked this way, too). If you want an outline, I need to get to the end to discover what I’ve been writing, and then go back to build out the structure of what got produced.
This brings us back to micromanagement and my challenge with the client’s expectations. What they wanted in deliverables wasn’t just contrary to how the audit process generally worked, it was also contrary to how I personally work. This was not a recipe for a productive relationship, and I am well aware that it frustrated both of us enormously.
The desire for interim deliverables was about trust. Principally, it was about not trusting and wanting proof. It was about verifying. Seeing the building blocks being produced progressively and on time should be a point of assurance. You are demonstrating that headway is being made, that interim steps are of sufficient quality, and that the schedule is being adhered to. As a consequence, you should have some belief that you will get what you want, when you want it, and the result will be complete and satisfactory.
While this is true in theory, it is very often not true in practice. The only time that interim deliverables really work well is when you are dealing with a completely linear, well-understood and stable process. Once you get into work that requires thought, creativity and inspiration—what gets lumped under the label “knowledge work”—that visibility breaks down badly.
Overall, I enjoy a high degree of trust with my clients. In fact, I would have to describe the level of trust that I enjoy as exceptional. Those who I work with know that they are going to get my best work. They have confidence that deliverables will be produced, deadlines will be met and I will proactively raise any concerns or questions with them. Without being detailed or overly bureaucratic, they know where things are, how progress is unfolding and that the results, once delivered, will meet or exceed their expectations.
The consequence of that is that I experience an enormous amount of latitude. For a consultant, I often have an unusual degree of discretion and autonomy in my work. I have been in situations where I have been empowered to speak on behalf of my clients, to advocate for change, to address difficult topics and to answer complicated questions. There are engagements where I have been considered a part of the organization, exercising influence that would normally be the domain of a senior executive. I’m gratified that I am able to instill that level of confidence, and it is a level of trust that I do not take lightly.
The interesting effect , however, is that while trust is high there can actually be precious little in terms of verification. The work that I do gets acknowledged, of course. There is appreciation and gratification for what I do, how I do it and the impact that my work has on their organization. Constructive feedback, however, is surprisingly infrequent. There is an enormous amount of trust, and comparatively little in terms of verification.
While all of this might be great for my ego—and it is incredibly nice to know that I am valued and appreciated to that extent by my clients—what it means is that most of my improvement is self-motivated. I don’t get a lot of guidance on what could be done better, and so I have in large part evolved into my own worst critic. I will see the faults, the errors and the things that could be improved. I will strive to produce better deliverables. I will work to build more relevant presentations. I will endeavour to have a greater impact. The motive to do that, however, and the critical input that prompts it, comes at this point in my career more from me than the clients I engage with.
“Trust, but verify” sound like a caution or an admonishment. It is in fact a promise, and a valuable one. It is a guiding framework for thinking about work, and particularly the work that you give to others. It encourages you to think about the trust you hold, and what you need to do to ensure that you get the results that you want. It also prompts thinking about the communication that others need. What feedback is useful and constructive, and when does it become unhelpful, disruptive and overbearing? Even for those you trust implicitly, what do they need to hear from you to know they have been seen, that you value their work and that you are grateful for the degree of confidence you are able to bestow?
Do trust. But do verify, as well. Just do so in a way that is appropriate to the work, and to the person you are working with.
Michael Hilbert says
I have found from my own experience that, as you indicated, the amount of verification is proportional to the current level of trust. While I may trust a new team member, I feel the need to verify (not all, but some of) their work, especially where customer expectations are concerned. I don’t see this as micromanagement, as that level of verification drops over time as my trust in them is confirmed.
I was curious about the origin of the phase and was surprised to find that it came from a Russian proverb, Doveryai, no proveryai (Доверяй, но проверяй) meaning ‘trust, but verify’. The proverb was adopted as a signature phrase by President Ronald Reagan, who used it frequently when discussing U.S. relations with the Soviet Union. (Source > Wikipedia). Talk about ironic!