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).
> 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?
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. :)
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.
"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".
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.
This article doesn't answer the question put forth in its title. Why DO geeks need to learn how to delegate?
This is a very common behavior used by people who want to distance themselves from technical work. They pick something technical roles don't do and don't have any control over, and then make broad generalizing statements about how technical roles are bad at it (implying that the author is in his or her position because they are good at it). For instance most geeks are in front-line technical roles as individual contributors and don't have anyone to delegate to. It's like a battlefield lieutenant, scared of being sent to the front line and getting shot, proclaiming 'soldiers should learn to simply delegate combat duty.' Dishonest and smug.
A 'geek', being someone who solves problems and therefore does actual work, is a member of the working class.
The middle manager, equivalent to a slave overseer, has a different skillset related to the manipulation and control of personnel, that takes time and practice to develop.
In order for a technical worker to 'learn to delegate', i.e., adopt the ownership mentality and become a member of that class, he must make both a moral adjustment and learn a whole new set of personal manipulation and politicking skills.
But before that is even possible he must gain enough capital to purchase the workers.
Perhaps the secret to gaining capital is simply to appear as if one is already a member of the ownership class, whether that is really true or not.
Well, that really wasn't the point, but now that you bring it up, it really hadn't occurred to me that that might be the case. I'm sure that some middle managers do provide some service of some value to the people they manage.
To bad most entry level managers are really just team leads with supervisor responsibilities. In the past I have had to spend a considerable amount of time getting the team far enough ahead of the day to day minitua so we can focus on more long term strategy. When I fight piddly day to day problems I feel like a supervisor, when I get to focus the team on long term I feel like a manager. I wish I could spend more time as a manager/leader but most businesses have it honed to a science to give you what feels like less resources than the bare minimum, so to step out of that comfort zone and hand off a risky technical problem to a junior employee that is most likely going to fail and make you more behind is very very tough, but I am improving.
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.