Managing Product Development

I taught a management tutorial at the Better Software conference this week. One of the points I discussed (and asked participants to discuss) was delegation. The managers in my tutorial said they ran into these problems when trying to delegate:

• Being too concerned with how the delegatee did the work, not the results.
• Wanting people new to type of task to perform the task at the same speed that an experienced person would.
• Not wanting to delegate technical work (”because I like it”).
• Not taking the time to think about what to delegate.

Being a great manager takes time. Managers need time for one-on-one meetings, for group problem solving meetings, for dealing with issues around the organization (in meetings, email, and vmail). If you manage people, start thinking about how you’ll delegate the work.

There are plenty of wrong ways to delegate. See How to destroy commitment and motivation for what happens if you delegate badly. I had some tips for how to delegate here.

Delegation, as all other management skills, takes practice. It’s worth thinking about how to delegate, practicing with something small, and continuing to practice. That way you can be a better delegator and your staff can be better delegatees.

We’re in the last stretch of finishing Behind Closed Doors, and now we’re fixing/regenerating pictures.

When Esther and I made the pictures originally, we wrote them on flip charts and took pictures of them. (We were talking about information on flip charts — made sense to us.) Well, it turns out the pictures are not sufficiently high contrast to use in the book.

Esther has much nicer handwriting than I do, so she redrew all the flip chart pictures. To save time, Andy delegated the eps file creation to me.

Here’s my context: I flunked cutting with scissors in Kindergarten. I successfully flunked every other art course I ever took. (In school, I received “A” for effort and whatever the not-quite-failing grade for content.) As soon as possible, I stopped doing anything with pictures.

Fast forward to today. It’s now my job to do a good job with creating eps files. Now to most of you, this does not reek of art — but to me it does. I have to look at contrast, size, rotation, cropping, all things that say “finish a piece of artwork.” Eek.

So how did Andy delegate this to me? He said, “Here, do this and that. Send ‘em to me.” He gave me feedback, explaining I needed to lower the resolution (!). This time, he didn’t say how, but what he wanted as a result. I was successful.

Ok, so this is a small task and I’m not sure I’m over my fear of creating art, but I’m a lot closer. Here’s what Andy did:

• Checked to see I was willing to do the job. (I was.)
• Bounded the work.
• Explained which tools I needed and verified I had them.
• We jointly set a time at which I would check in and verify I had done the right thing.
• Provided feedback so I would know how to modify what I thought success was.

This is almost exactly the same as our checklist for delegation in the book. (In the book, we have a few extra items: knowing when the work is too risky to delegate, and setting boundaries on schedule, cost, quality.)

One of the nicest side effects of delegating is to help other people be aware they have more capabilities than they originally considered. I’m a lot more likely to consider pictures now that I know how to create them and how to electronify them for a book. This was successful delegation–for both of us.