Fatal Delegation Mistakes

In BCD, Johanna and I wrote a section “Setup for Successful Delegation.” We wanted to help managers think through the boundaries of a task they’re delegating and be clear—with themselves and the other person—about requirements, unacceptable solutions, progress reporting, and desired results.

Delegation can build trust and capacity when done well. When managers screw it up, the person delegated to feels set up and loses trust.

Some common mistakes:

Telling people they have full decision making for the task – when they really don’t

Springing a contradictory requirement when the product is delivered

Using delegation as a secret test --withholding guidelines or requirements to see if the other person will figure it out

Publicly rescinding responsibility for the task

Publicly giving the task to someone else

Changing the decision making rules on a task previously delegated to a person without telling him/her

Asking the rest of the team to approve the product when that wasn’t part of the original delegation

The dictionary definition for delegate is “to commit or entrust to another.” Every time a manager delegates, there’s the possibility to build commitment and trust or erode trust and engagement.

Managers—because they are human—won’t do it perfectly every time. When that happens, managers can maintain trust by owning the part of the miscommunication that’s theirs. That might be:

“I didn’t make it clear that here were some solutions that were out of bounds.”

“I wasn’t clear that I intended that I retained final approval for the product.”

“I wasn’t clear that I wanted you to bring options, not a final product.”

And if you get some bright ideas once you see that product, make that clear, rather than announcing the new idea as a criticism or rejection:

“Now that I see what you’ve produced, I’m getting some new ideas on how do to this. I sure wish I’d thought of this earlier. I think it’s important enough to reconsider.”

"A" work or "C" work

On Friday I gave my talk, The Value-added Manager: 5 Pragmatic Practices at the SQUAD Conference in Denver. I had a great time.

One of the practices I cover in my talk is making a to-do list and a not-to-do list and getting clear on priorities. A woman in the audience offered that she also talks in terms of A work, B work and C work… by which she means that in addition to knowing the priority of a project or task, you need to know the quality that’s required.

Most of us group up with adages such as “If it’s worth doing, it’s worth doing right.” That’s a nice saying, and like most old saws, it leaves out the context.

Sometimes it is worth doing something “right.” Other times 80% “right” is good enough, and the effort and cost required to achieve 100% “right” doesn’t make economic sense.

So along with priority, define what *done* means, and what *good enough* means for the task at hand. A work vs. C work is a nice short hand for the concept: in reality, it's important to be specific on the desired results.

6 Reasons *not* to have a Retrospective

Retrospectives are a great way for teams to inspect and adapt their methods and teamwork after each iteration and release. And they’re a great way for teams to build on success, learn from hard times, or bring closure when a project ends. But they’re not for good for everything. Don’t do a retrospective if you want…

another group to fix the way they do their work

to show that someone isn’t doing his/her job

to find who is to blame for bad design, missed deadlines, disappointing projects etc

to force two individuals to solve a long standing conflict

to give feedback on poor performance

to prove that if those people had done better, everything would be fine.

On the other hand, if you want to learn from experience, build on what works, gain perspective, and decide what to do differently, a retrospective can work for you.

Jerry Weinberg on the AYE blog

Jerry Weinberg finds wisdom in Japanese proverbs in this post on the AYE blog.

If I were to give advice to a young professional starting out in the world, I could do no better than quote three Japanese proverbs:

We learn little from victory, much from defeat.

So, do not think in terms of Win or Lose, because you cannot always win.
Think instead of Learn, for Win or Lose, you can always learn.

Even a thief takes ten years to learn his trade.


There is no quick road to success. Be prepared to persist through some hard times, and you will outlast your competitors who burn themselves out with too quick a start.

If you believe everything you read, better not read.

Take my books, and the books of others, as if they were tempting meals.
Taste everything, but swallow only what tastes right to you.

Smallest Lever

One of my readers asked me to explain how I use Next Action -- which is a little different than described in David Allen's book. So maybe I should call it something else like "Smallest Lever."

I use Smallest Lever for tasks or projects that

a) I don't particularly like to do--ones that feel onerous

b) I tell myself I'm "not good at"

c) I tell myself I don't know how to do

d) I notice I'm avoiding

e) all of the above.

Rather than think about doing the whole thing, which brings on a bout of MDD (Motivational Deficit Disorder) I identify the smallest possible action that will move the task forward-- a task that will take only a minute(or less) and is not at all onerous.

So I might:

look up a phone number

do a google search

recycle one piece of paper

write one sentence

Once I take that small action, I'm usually started with the project and have enough momentum to make significant progress.

Completing the entire task usually takes much less time than I put into finding other things to do so I could feel productive while avoiding this other task.

Some days managing myself takes all my time. ;-)

Retrospective Workshop in Denver

I'll be at the SQUAD Conference in Denver next week doing a full-day workshop on Retrospectives on 2/16 and giving a talk on The Value-Added Manager on the 17th.

Continuing the rif on Managment and Leadership

Blog post grows up to be an article here.

Next Action

A while back I listened to David Allen’s Getting Things Done on audio book. (I remember noticing passive voice—which struck me as odd in a book about taking action.)

I haven’t implemented the system--or purchased the gear.

But I am practicing Next Action. For me, Next Action helps me get started on projects that don’t play to my strength (logistics planning, for example) or I don’t like, but have to do (like taxes).

Rather than having to figure out the entire project or devote hours, I decide on the simplest, smallest action I can take that will move the project forward.

When I take the smallest action, I usually keep going, and complete the project—in much less time than I spent thinking I *should* be working on it.. Next Action busts through inertia and gets the nasty tasks out of the way so I can do something I enjoy.

I suppose I could decide on the Next Action to implement the whole system…

Nah.