Delegation before understanding?

 I've recently been put over two new groups in the organization in addition to my current responsibilities.  Fundamentally it's a huge influx of new information and work, which means delegation becomes very important.

That said a few questions/concerns pop into mind:

  1. It feels ineffective to delegate to directs in the new departments when I don't have a thorough understand of all of their "balls" and the work and how it flows through this part of the organization - if I delegate without an understanding of their daily jobs jobs (and their small balls) then I fear we may be headed for trouble.
  2. Given #1 (possibly this is a more general question) - how do you avoid over-delegating?  If requests come in quickly it's easy to delegate it off and quickly forget that someone is on day 2 of a ~5 day task and delegate again.  If the cycle repeats balls have the propensity to get dropped - in the long run if the work is understood, some ball dropping is fine, but what if these are all great initiatives but we're just taking them on at a too-fast rate?

 Thanks for your help in advance.


Shared responsibility

I've recently been reflecting on my core principles of workload management, both for myself and my team, and with the help of some MT podcasts I've come to the conclusion that workload management isn't *just* your responsibility.  My thoughts have always previously revolved around the manager not overloading their team with work; for that you need to know exactly what they're doing and how long it's going to take -- which ends up feeling very, very much like micromanagement.  It's also not practical, especially if work requests can come from other people in the organisation.

I'm not in a position to find the exact podcast(s) I was listening to just now (I'm sorry about that; if you need some help finding them, ping back and I'll find them, but I'll bet someone reading this knows exactly which cast(s) I'm talking to and has them bookmarked), but they centred around the process of assigning work: giving tasks which include reporting as part of the task and with an explicit deadline, and -- most importantly -- always getting a verbal confirmation from the assignee that they are willing to accept the work.

The key point I got from the casts is that you never just *give* someone a task -- you *ask* them if they can take it, and you abide by their answer.  I remember Mark saying, "Never ask a direct a question if you're not willing to abide by the answer", which I've taken deeply to heart.  By asking, you give them the chance to say no, and/or to engage in a dialogue about the task which may teach you a thing or two about what's going on.

There is a key difficulty here, though, and that's getting your people to effectively manage their time (which is something that very few people are good at, myself included), and also to have the courage to say "no" if they legitimately can't do it -- without going the other way of just saying "no" to everything and having the cruisey life.  Coaching (including possibly getting in outside help to teach everyone good time management practices) and a "gradual" handover of time management responsibilities should work to help with the first problem; the rest is about relationship.  Asking people to do things, also, helps with your understanding of the work that your team is doing -- when Suzie wrinkles her nose and says "I don't know if I can, Alice needs these TPS reports by 2pm" you now know that your team is responsible for getting TPS reports to Alice.

To apply all this more specifically to your situation, I think you need to make sure everyone knows that they're responsible for meeting their own commitments, and you'll be asking people to do work and commit to deadlines, and if they cannot meet the deadlines they need to tell you that up front, before they accept the work.  You then need to stick to that, and (preferably) do the same thing to wherever you're getting your work requests from -- ask for deadlines, make a realistic estimate of how people are situated for workload (including *asking* them before you commit to accepting a task), and say no if things cannot be worked out.

The links are here


Personal Use


 The very valuable podcasts mentioned by MattPalmer start with

 I would also add

 This is a new philosophy I am struggling to integrate in my team. It will be valuable once I get it into the work flow.