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.