We've all known the manager that refuses to delegate. They want to be involved in EVERY decision. They want to be "presented to" and (if your lucky) given a recommendation. It's usually either a VERY capable person (who is super-duper smart and works super hard), or a VERY nervous/worried person who is constantly thinking about CYA (Cover Your Ass). In the first case, they are doing it because they probably DO have great ideas and maybe could do it better/make it better. In the latter, they are doing it because they are worried that if it gets screwed up, they will lose their job. In either case, they are doing it wrong. Refusal to delegate means you ARE the bottleneck in your system.
There are two principles that are being ignored here. First, the principle of trust. In both cases, they are not trusting their co-workers (or subordinates) to do the work right (well). The second is efficiency. In both cases, the manager has sacrificed "efficiency" by putting themselves in the work-flow.
I can't change your manager over night...but here is how you can change him (and/or yourself)!
1. introduce the concept of "guidelines".. pre-approved guides within which one can operate without approval. Budgets, schedules, milestones, and boundaries. (e.g. $500 per month spending maximum for needed stuff)
2. introduce the concept of "good enough".. a standard that is admittedly below your BEST's best, but that is good enough to get the job done without taking your Best's time away. (note: works well when the BEST is the manager in question, or he thinks he is). [not that I know from personal experience] :)
3. introduce the concept of "front man".. a front man not only has ownership of the project, but gets exposure as the leader to higher-ups. This concept is a win-win-win... the CYA guys, get to CYA. The subordinates get higher-up exposure, and the higher-ups, get to see new faces!
Now, start delegating, and work on the stuff that really matters.
Posts
Larry R. Said:
ReplyDelete"you asked for comment, so here's my $0.02:
A corollary to this is the Bungee Hero. This exists mostly in mid-sized companies. A Bungee Hero (BH) is someone the upper management assigns to troubled projects to get them back on track, and then when they are turning around, bungees out to the next project. It's a great position to be in, because the BH can take all the credit for successful projects and none of the blame for failed projects. However, within any particular project, the BH will act exactly as a manager/hero who can not delegate, mostly because there is an initial assumption that all the people the BH is there to help are incompetent, or they wouldn't need the BH. It never matters if the project was originally failing because of worker shortcomings or bad expectations/resources/specifications from the management.
The fundamental flaw of any company that falls into the BH trap is that it does not scale, and eventually the Hero burns out, gets bored and moves on.
Another comment I have for your article is that you hit on one of the two Engineering Mantras you have heard me (re)state over the years: "good enough" and "slow down, you'll get done faster". When something is good enough to successfully sell in the market, you're done. When you take your time and plan things out carefully, you get done sooner. The "shoot-from-the-hip quick demoware and we'll fix it later for production" method that so many of us use is NEVER the fastest to production, although a good counter-argument could be made about early demos capturing sales."