3 ms·
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 ma
by InclinedPlane 13y ago
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.
- thirdtruck 13y agoSeconded. 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.
- InclinedPlane 13y agoI 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.
- thirdtruck 13y agoMakes sense. I look forward to figuring out how to apply TDD- and BDD-like methodologies to non-software processes.