Wednesday, May 12, 2010

Practicing Ceding

I wrote a few days ago about ceding control to your team. And I got a great response: "Okay. How?" The short answer is it depends on you. This is your need for control, so you have to figure out how to cede it.

The longer answer is that there are some things you can do that will likely help:
  • Be aware
  • Understand consequences explicitly
  • Start small
  • Trust publicly
The first key to changing any behavior, really, is to be aware of it. Watch yourself and check for times when you're asserting control. When that happens, ask if you really need to be in control of this thing in this moment. Watch out for thoughts like "I'll just do this myself!" or "if it needs to be done right..." or "Who knows how so-and-so will do it". These are indications you're taking control in an area where maybe you could delegate the task. Whenever you hear yourself thinking one of these phrases, stop, and go to the second key.

The second key is understanding consequences. Like many things, this is a two part question: (1) what is the likelihood of failure; and (2) what is the consequence of failure. In other words, treat this like a bug (you know how to do that!). Once you've noticed a decision where you can take control or delegate (see the first key above), you need to consider what happens if your team member fails, and how likely he is to fail. If the consequence of failure is high - customer embarrassment, public malfeasance, etc. - that's an argument for not letting the work go out without your oversight. If the consequence of failure is low - the test domain gets a name you wouldn't have picked - then it's a prime opportunity to delegate. Consider the same for likelihood of failure. And don't forget it's okay for people to fail, as long as the effects are controllable.

The third key is to start small. Not comfortable delegating an entire test plan to someone? Get them to write a section of it in an area of the product they know well. Really feel like the lab hardware allocation is make or break? Ask a team member for a proposal that you will review before it gets sent to IT for implementation. Start delegating contained tasks. Be a bit of a gatekeeper reviewing work for a while. This allows you to get an idea of what your team members can handle, and it lets you learn that you don't have to control for good things to happen. Build up from there to larger and larger tasks with less and less oversight.

Lastly, be explicit about the trust you're placing in the team. These are testers just like you. They're probably people you've worked with and developed a rapport with. So sit down and confess: "Hey, guys, I'm new at this management stuff. Let's help each other out." Going forward, it's okay to give a task to a team member and tell them, "I'm trusting you with this." Your team will almost certainly work to earn that trust.

Be patient with yourself. Giving up control is hard. You're going to take over and do too much. But you've given up control before; after all, you didn't personally test the entire product did you? Your team mates did a good chunk of it, and you trusted them then. Keep that trust, build that trust, and let them learn and grow. You and your entire team will be better for it.

1 comment:

  1. thanks for this, I'll try to put some of this into practice