Whether to delegate | Hacker News Reader

Whether to delegate

johndcook.com

57 pointsColinWright14 comments

I really like this model and framework - most people underestimate the impact of transaction costs, and I think it's partially why many companies overestimate the value they'll get from outsourcing.

But in the real world, I've worked with dozens of leaders and professionals, and I don't think I've ever seen someone with an over-delegation problem, where they had handed off too many tasks that they should have been doing themselves. Most have the opposite problem: mistakenly believing that delegation will take longer, or will result in lower quality work.

Delegation doesn't just help the person delegating, it helps the person receiving the work as well. It gives other people the opportunity to handle new challenges, feel ownership over their work, learn new skills, and apply what they're good at.

"But in the real world, I've worked with dozens of leaders and professionals, and I don't think I've ever seen someone with an over-delegation problem"

Couldn't agree more. I actually think our brains tend to over inflate the transaction costs, not ignore them completely.

I've seen leaders who don't delegate but abdicate. They hand over a project completely, refusing to make decisions that only they are authorized to make. It's as if they're saying "Guess! And if it turns out poorly, I can say I never told you to do whichever course you take."

"most people underestimate the impact of transaction costs"

I think most companies underestimate the impact of transaction costs, but most managers overestimate them. Both problems result from a failure to see the issue played out over the long term. In both cases, people or entities only consider the immediate to near-term impact of the delegation.

A company will look at the present value of outsourcing, which is often highly positive, but underestimate the opportunity costs over a longer horizon (lost institutional knowledge, higher marginal transaction costs, commodification, etc.).

A manager/individual will be hesitant to delegate because he or she only looks at the immediate hassle of having to train someone and get them up to speed. "It'll take Bob six months to really understand this track of work. It'll just be quicker if I get this done." In this case, the manager fails to understand that delegation has high short-term costs but low long-term costs. The learning "curve" is more of a step function. Once Bob is fully competent at Task X, delegating Task X to Bob will create efficiencies for his manager. It's starting Bob off on the task that's the hard part. His manager basically has to invest efficiency: "spending" some efficiency now in order to realize a net gain in efficiency later on.

Another important factor that took me a while to learn and be comfortable with: successful delegation is not the same as defect free delegation.

People will make mistakes. They will do so even if they are competent and you were well justified in delegating a task to them. Nevertheless, screwups are going to happen, and sometimes it'll be something that is beyond the capabilities of the person you delegated the task to deal with.

But it's a mistake to think of these things as failures of delegation, or to use them as an excuse to curtail responsibilities. Delegating properly requires a holistic view. One of the fundamental problems of people who micro-manage or are incapable of delegating is that there will always be fuckups, thus there will always be excuses to do it yourself instead of delegating. But this is because we're comparatively blind to our own fuckups, which we see as recoverable and due to things beyond our control whereas the temptation is to see other people's fuckups as due solely to incompetence.

If nothing ever seems to be going wrong that may actually be a sign that you're not delegating enough. The trick is finding the right balance.

Seconded. I had to delegate the production of cover art for my recent novel, as I could not even pretend to overestimate my art skills. Even then, I managed to let a major error (likely a failure of instruction) get through, which will require one more editorial task for me.

I suppose the corollary of this is that you have to make sure you put in place quality control checkpoints so you can make sure delegated work is done correctly. This sort of thing tends to be ignored when you do something yourself because you'll usually do simple double-checks to verify the work you've done as a matter of course.

Makes sense. I look forward to figuring out how to apply TDD- and BDD-like methodologies to non-software processes.

This distantly reminds me of http://xkcd.com/1205/ , the saving time comic. When I looked at it, I noticed that the time durations surprised me, in that spending time automating (which can be compared to finding someone to delegate to) is often more worth the time than I would have intuitively felt.

I'm not sure if that's just a personality thing, or if people in general are more liable to not-delegate-when-they-should, than delegate-when-they-shouldn't.

Agreed. I might have spent the better part of three or four full work-days refactoring some code at work, but that was only after we spent a week of QA time and my own error-fixing time, all because I had not insisted on such refactoring in the first place. Never mind the time we will save going forward replacing in-browser tests with controller-level unit tests.

Good post. I like the ideas of managing energy, in addition to time. In a similar vein, one has to manage their focus too. This means delegating things so that one can focus on other things. (Or more correctly, delegate and monitor if that takes less attention than doing or actively managing)

I think corporations are similar to supercomputers. For instance delegation makes a lot of sense in embarrassingly parallel tasks, but can sometimes be for the worse if it means excessive io.

If you mean communication by io, then yes, this holds. Similar to parallel computing design, there are organization design principles to minimize handoffs. For instance designing work and organization so that larger tasks can still be handled by individual organizational units.

I'd like to start delegating more. Any suggestions of things to try? What have you found most useful?

Reply on news.ycombinator.com