My recent post on fixing the real problem reminded me of an earlier post on the rapid prototyping of life, where I said “The qualities which point towards rapid prototyping are where the final goal is poorly defined, where only experimentation, not theory, will help define that final goal, and where there are no irreversible consequences for trying something.”

Can we apply these iteration and feedback tactics to management? It seems like an appropriate solution, as managers are often in situations where the real problem is “poorly defined”. Perhaps the only thing a manager can do is to guess what the problem is, try something to fix it, see what happens and then repeat the process.

Unfortunately, people are involved, and people have memories. My statement on the applicability of rapid prototyping included a clause about “no irreversible consequences”. That doesn’t apply here. If a manager decides that the problem is that employees aren’t working hard enough, and the real problem was a technology issue, then that manager loses credibility in the eyes of the employees, opening an irrecoverable breach of trust.

Another problem is that the feedback received as a manager may be untrustworthy. In rapid prototyping, evaluation is an integral part of the process, because the feedback drives the direction of the next iteration. In a management situation, the relevant feedback would have to come from the employees being managed, and that feedback is inherently suspect because of the power differential. Very few employees will provide critical feedback to their manager, even in anonymous forums, for fear of retributive consequences. Even positive feedback can’t be trusted because employees may be deceivingly flattering in hopes of currying favor.

I think there are ways in which iteration and feedback can be incorporated into a management setting, but they depend on a having already built a team. When there’s a problem with a project, the manager can’t unilaterally make a decision without risking losing the team. He has to consult the team to collect possible ideas and create a consensus around one of those proposed solutions. There has to be a foundation of trust between the team and the manager for iteration and feedback to work, and for the employees to believe that their feedback will be included in the next iteration. That trust takes time and several iterations of projects to establish, so hopefully you’re not a bungee boss.

There’s also an element of iteration as a new manager. You’re going to mis-read situations and make the wrong choice sometimes, and you have to learn from those mistakes. The team also has to see you accept feedback and change your behavior, which will make it easier to get better feedback the next time, creating a virtuous circle of trust and improvement. One critical tactic for earning that trust is to take the blame, not only for yourself, but for the team.

Wow, this post ended up in a different place than where it started. I meant to write about how to use rapid prototyping and Trust but Verify methods in management and spent an hour yesterday on a draft that wasn’t working. But after writing a comment about trust this morning, I realized that the whole approach was bogus, so I ended up writing a post about how those tactics _won’t_ work. Ah, the joy of thinking in public.