You have to be a bit careful with this approach. If there's one thing that annoys me, it's managers constantly asking me for "status emails", making me go to "status meetings", and asking me to do other things with "status" in them.
I find that the best managers are the ones who can get the information they need and create a minimal level of disruption in the developer's workflow (not that it's always possible, I understand that disruptions have to happen at times).
I think the author is trying to encourage the practice in general. There are certainly ways to do it right and ways to do it wrong.
Just blindly asking for status emails so you have some numbers and justifications for your charts would probably not go over well. Asking for status emails regarding real milestones and to verify functionality, check metrics, or suggest current progress be analyzed can be very helpful.
Good management seems to include knowing when someone needs some guidance or help and when they just need you to stay out of their hair.
However, scrum-like standups mitigate it since you always report the status everyday like clockwork, so it doesn't feel personal for that particular task. Projects should be broken down into things that can be done within a day or less, so it is easier for a dev to stay in the zone.
I like the method described by Tim Ferris when he used Indian outsourcers: (1) Have them repeat the task in their own words before the task (2) Set a time limit, 1 - 3 hours into the task before they have to report back and you can make a decision to move forward and complete the task or cut your losses.
Agreed. The "trust" part of "trust but verify" is important, too.
For me, it was learning to build ways where I could invisibly monitor someone's progress without bothering them. Setting up Subversion/Git to alert me at commits. Having the database show me a progress of tasks completed/uncompleted, etc.
But yeah definitely: interrupting people doing good work, asking them to do things with "status" in them, is the worst way to go.
It's a really bad way to say something that's obviously true. It's a bad way to say it because it sounds and feels paradoxical, so it often gets dismissed by people who know how to think, and think they know what it means.
It really comes down to one of the fundamental components of management - communication - which isn't one way.
Communication requires saying things, then confirming that the message arrived without distortion. Further, when this communication is delegation, part of the message should be that you get a message back when it's done. Not least, the delegation should contain a clear statement (verified by having repeated back to you) of what it means for the task to be completed successfully.
Let them do the work, then get confirmation that it's been done. Trust that their statement that it's done is truthful.
I think his message is not so much to trust that their statement about progress is truthful, but rather to trust that others can do a good job and get it done well.
I'm sure many of us have had that feeling of, "I know I can do this better, I should just do it." The point of this is to trust them and instead say, "I know I can do this better, but I need to delegate, so I trust that this other person can do a good job." That's the first part of delegation. The second part is to verify that the work did get done to a high standard, and make it clear what else needs to get done.
You need to be able to trust employees to get the job done, and you need to verify that it did get done in case it did not.
At last an opportunity to get this question answered:
Surely "Trust but Verify" is a joke? Or at least a paradox.
If you trust someone then you don't need to verify, and if you verify then you aren't trusting someone.
And yet many people, such as this post and Ronald Reagan use it as if it just a simple slogan without a dark double-meaning.
Is it just me? I don't see how someone who "trusts but verifies" would act any different from someone who "distrusts and therefore verifies" apart from (falsely) telling the person being checked up on that they are "trusted".
But really it means when you delegate, do it thoroughly. Don't just say it once and assume it's done. Confirm that it's done. Set up a system to make sure that it's done.
There is a similar Russian expression too, less poetic however.
I think "trust but verify" places more emphasis on the "trust" part whereas the other one emphasizes the personal responsibility. Both remind us to seek the balance between personal involvement and personal detachment in a particular project.
You can be verifying that they did what you had in your head that they would do. It may be that you didn't communicate the task well enough so you're really verifying your message.
"Trust, but verify" captures the attitude that you're verifying not because of any suspicion of wrongdoing, but because there is a remote possibility of major problems. So the person who is being checked up on is not under suspicion, and shouldn't be concerned about the verification process. It is just a standard procedure because you'd have to be crazy not to check.
Verification doesn't have to be about trust. It's a feedback loop.
When delegating work, I always trust the people I delegate to. However, I verify what's done in order to make sure we're on the same page in terms of how things got done, and even to make sure that I communicated what I needed done effectively.
You can distrust and verify as well, but you're verifying for different reasons.
I have always hated this phrase. It isn't "wisdom," it's just dumb saying that makes no sense if you think about it for more than two seconds. Either you trust someone, or you do not. People who go around spouting this line as an example of what a sage leader Reagan was annoy me to no end.
I think it can make sense, although I'm not Russian.
It's not that the OP doesn't trust his subordinate. It's that he doesn't trust the communication between them. It could be that the project wasn't described clearly, or that its high priority wasn't understood.
Incidentally, "trust but verify" was the cornerstone of Ronald Reagan's nuclear policy vis-a-vis the Soviet Union, and could effective act as a summary of the INF treaty.
I find that the best managers are the ones who can get the information they need and create a minimal level of disruption in the developer's workflow (not that it's always possible, I understand that disruptions have to happen at times).