3 ms·

When you have a particular task at hand, and you also have someone available who you trust can do that task better than you can, delegation is easy. Sure, ther

by jtheory 15y ago

When you have a particular task at hand, and you also have someone available who you trust can do that task better than you can, delegation is easy. Sure, there's a minor jolt to letting anything go, but it's a no-brainer. Harder: delegating a task you don't understand well, to someone you aren't sure you can trust to handle it well (whatever they claim). This one's stressful, and sometimes you'll screw it up, but your hand is forced; you can't do it yourself. Hardest: delegating a task you understand well and could knock out of the park (if you had the time) to someone you're fairly sure will have to battle with it. The insidious aspect of that last one is that you're likely to overestimate how well you'd do the task, and underestimate how the other person will do (as well as the benefits to you and your company if they do it). You're still up at the high level, for one thing (not down in the dirty details where the complexities turn up...). But secondly, if you're the only one in the company who has done X-difficult-task before, think about that for a second. Wouldn't you like to have two people in your company who've done X-difficult-thing before? And how did you end up doing it the first time? (Was it a disaster? Probably not.) If you're surrounding yourself with talented people, there are huge benefits in letting them do as much of the "hard stuff" as possible (you're transforming them into better people through experience). Still hard as hell to let go, though.

sneak 15y ago
> If you're surrounding yourself with talented people In certain contexts, Yours Truly isn't the one doing the surrounding, so that's a pretty major assumption to make. Any tips for delegating to merely-proficient people?
- jerf 15y ago
  For those, the mental model I'd suggest using would be "mentoring" rather than "delegation". Details vary greatly depending on the people (mentor and, err, mentee?), of course, but check in frequently and expect to spend some time talking through some of the hairier details. Hopefully you'll still spend significantly less time on the task, take only a minor quality penalty, and create a stronger team member as a result. Of course, flip all three of those and that's what can go wrong, too. :)
  - rickmb 15y ago
    The initial process of mentoring takes considerably more time and effort than doing it yourself, and it can feel like a waste of time if the "merely proficient" never reach the level of competence you have. It may be the best thing to do under the circumstances, but it's hard, especially if you are a geek who has spend most of his live doing stuff rather than delegating the doing part.
    - jerf 15y ago
      "The initial process of mentoring takes considerably more time and effort than doing it yourself," Well, I suppose I can't honestly say "you're doing it wrong", but I can say "you're doing it differently than me". But then, even when I'm mentoring I tend to expect that I'm mentoring someone who fundamentally wants to know, and is willing to put time in to learning whatever it is on their own, and I'm just coming in every so often and saving time on pointing them to the next place to go. I am lucky enough to be in a position where I can essentially count on that, and thus "mentoring" != "hand holding".
- jtheory 15y ago
  I think you can cross out the bit you quoted and it still adds up. Whether you're working with the "merely proficient" or "coder deities" you still want to give them tasks that will push them to expand their skills, rather than just a never-ending stream of what you already know they do proficiently. I'm not sure how much to generalize beyond that -- you'll want to be sure they're making steady progress and not spinning their wheels, so check in periodically or sort out some other way to know how they're doing. I personally keep a running text file for hard problems I'm figuring out -- tracking research/links, debugging results, POC details, etc., with a "status/do this next" list at the top that I review each time I pick it up again. When I want other people to be able to learn from what I'm doing (i.e., I'm doing something hard but will want others to work on it later), OR track where I'm headed (if they may have input to offer), I do this on a shared wiki page. There are lots of ways to keep that info flowing; just do something so you know ASAP when someone gets saddled with something they hate, don't understand, can't get through, or even find boring.

by jtheory 15y ago

sneak 15y ago

> If you're surrounding yourself with talented people In certain contexts, Yours Truly isn't the one doing the surrounding, so that's a pretty major assumption to make. Any tips for delegating to merely-proficient people?

jerf 15y ago
For those, the mental model I'd suggest using would be "mentoring" rather than "delegation". Details vary greatly depending on the people (mentor and, err, mentee?), of course, but check in frequently and expect to spend some time talking through some of the hairier details. Hopefully you'll still spend significantly less time on the task, take only a minor quality penalty, and create a stronger team member as a result. Of course, flip all three of those and that's what can go wrong, too. :)
- rickmb 15y ago
  The initial process of mentoring takes considerably more time and effort than doing it yourself, and it can feel like a waste of time if the "merely proficient" never reach the level of competence you have. It may be the best thing to do under the circumstances, but it's hard, especially if you are a geek who has spend most of his live doing stuff rather than delegating the doing part.
  - jerf 15y ago
    "The initial process of mentoring takes considerably more time and effort than doing it yourself," Well, I suppose I can't honestly say "you're doing it wrong", but I can say "you're doing it differently than me". But then, even when I'm mentoring I tend to expect that I'm mentoring someone who fundamentally wants to know, and is willing to put time in to learning whatever it is on their own, and I'm just coming in every so often and saving time on pointing them to the next place to go. I am lucky enough to be in a position where I can essentially count on that, and thus "mentoring" != "hand holding".
jtheory 15y ago
I think you can cross out the bit you quoted and it still adds up. Whether you're working with the "merely proficient" or "coder deities" you still want to give them tasks that will push them to expand their skills, rather than just a never-ending stream of what you already know they do proficiently. I'm not sure how much to generalize beyond that -- you'll want to be sure they're making steady progress and not spinning their wheels, so check in periodically or sort out some other way to know how they're doing. I personally keep a running text file for hard problems I'm figuring out -- tracking research/links, debugging results, POC details, etc., with a "status/do this next" list at the top that I review each time I pick it up again. When I want other people to be able to learn from what I'm doing (i.e., I'm doing something hard but will want others to work on it later), OR track where I'm headed (if they may have input to offer), I do this on a shared wiki page. There are lots of ways to keep that info flowing; just do something so you know ASAP when someone gets saddled with something they hate, don't understand, can't get through, or even find boring.