Two Approaches to Delegating Tasks

Other than a few useful modules of my engineering degree, I’ve received very little formal management training. When I found myself plonked in the position of general manager of a small office of an industrial service provider aged 29, I took the approach that I would manage people how I’d want people to manage me. I won’t say I didn’t make any mistakes, mainly due to impatience born of immaturity, but I found the approach worked. When later I became a manager in a much larger company, I applied the same principle and, insofar as my management of my subordinates was concerned, I think it worked well. A common complaint I used to hear a lot from my former colleagues is they didn’t like the manner with which various managers handed down work. One of them, I’m not sure why, asked me how I would delegate a job to him if I were his manager. So I told him.

When I receive a piece of work someone in my team needed to carry out, the first thing I’ll do is take a good look at it myself. Is it a reasonable request? Have the other parties done their jobs, or has it come in half-arsed and my guy will spend most of his time running around trying to get information that should have been supplied to him already? What’s my first impression of the job? I’ll then identify the person in my team who I want to lead it and send him an email as follows:

“Fred, can you have a look at this sometime over the next few days when you’ve got a moment. I’ll come and see you on Friday, and we’ll have a chat about it.”

At some point before Friday I’ll wander over and see Fred and say, “did you get that email about the job?” and Fred will reply, “yeah, I’ll have a look at it after lunch.”

On Friday, I’ll sit across a table from Fred and ask him to tell me what he thinks. Is it a big job, a small job, a difficult one, and easy one, an impossible one? How long will it take? How would this fit in with his current workload? Can he squeeze it in next week or will it take a month of dedicated effort? Fred will then say something to the effect of:

“The job itself is do-able, nothing too complicated about it, but it will definitely need a site visit. And we’re going to have to have a meeting with Marine Operations because it’s not clear why they want to install that 2″ line from A to B. I’m busy with that other job now but I should be finished on Wednesday, after that I can start to pull the drawings out and have a proper look. But it really depends on when I can get offshore; once I’ve done that, I reckon it’s about two weeks’ work.”

I’m simplifying, but this gives me what I need to write an execution plan, and go back to my internal client and brief him up on when he can expect the job to get done. I also put in the request for the site visit, and let him know the job can’t properly get going until Fred’s been offshore. In my experience, the internal client is quite happy to have this discussion; half the time their requests disappear into the ether and they expend a lot of effort chasing up where they went. A little two-way communication goes a long way.

I’ve also found taking this approach means Fred is quite happy with the execution plan – which he should be given the bulk of it is his own and we practically agreed it in advance. Moreover, I’ve found engineers feel a lot more valued and respected if you give them an opportunity to propose how they want to do the job, and raise any concerns they have up front. If you don’t like something in their proposal you can argue the point with them before the work starts, so when it does you’re all in agreement. There’s nothing worse than a manager intervening with a bright idea of how things should be done once work has started, particularly if he had ample time to say what he wants beforehand.

If it’s a multi-disciplinary job and other departments are involved, I repeat the process above with each individual and at the end I send the execution plan around for  each person’s review. Then I hold a kick-off meeting which normally lasts 30 mins max as everyone nods their heads and says “yeah, we discussed this already”.

Unfortunately, it seems my approach to work delegation is unusual. In my experience, and that of a fair few of my former colleagues, managers normally distribute work via an email which reads as follows:

“See attached work request, this is urgent, please arrange a kick-off meeting for tomorrow and send invitations today.”

You open the work request and find it’s a garbled pile of incomplete nonsense which makes no sense to anyone. The total effort your manager has spent on it is to click the forward button, enter your address, and write the email. At the same time, you’re already working on three other jobs which you’ve also been told are urgent. If you ask your boss about this clash of priorities he will say “you just have to manage”. So you drop everything and spend  the entire afternoon trying to get the availability of people who you have no interest in talking to, at least not yet, for a meeting you don’t want to hold. Then you have to find a spare meeting room. Oh, and the manager wants a presentation with slides – lots of them.  The kick-off meeting goes on for several hours as each discipline or department bickers with one another as to how the job should be done and tries to solve technical problems there and then, while your manager intervenes at frequent intervals to tell you which tasks you can start “immediately”. Such as construction. Over the course of this meeting it becomes clear the job is only urgent in the sense that a Big Boss has asked for a status report after it’s languished on someone’s desk for months. It wasn’t unusual for me to receive “urgent” requests for work for which the paperwork had taken the offshore and onshore clerks more than a year to complete. Your manager will nonetheless expect you to react as if the platform is on fire.

Insofar as the two approaches to delegating work to team members go, I think I’ll stick with mine.

Liked it? Take a second to support Tim Newman on Patreon!
Share

34 thoughts on “Two Approaches to Delegating Tasks

  1. I had a manager once who firmly believed that delegating tasks was the sign of a good manager. He got to be such a good manager that he’d managed to delegate almost 100% of his actual day-to-day tasks (other than attending management meetings) to several of his underlings.

    You could always tell when he was going to announce that he’d be at a management meeting at the other site for a few days – the pile of physical dossiers to be signed off on would have reached at least a foot high.

    But I can’t be too hard on him – he always gave us due notice of when he’d be away. He’d always inform us around 4pm on the day before…..

  2. It’s often difficult for managers to get the approach right, especially as regards the amount of oversight and checking up. I had one woman working for me who simply wanted to be told the desired outcome, and then for me to completely leave her alone until she delivered. She was ex-army and an ex-nurse, and said that was what she was used to. There were several misunderstandings at first when she accused me of “interference” and “micro-management”.

    To be fair to her, she did get the tasks done. But her colleagues often needed constant checking, and appreciated reassurance, and that was what I was used to. I guess once you know your team, then you can adopt appropriate approaches for different individuals, but this becomes difficult if there is a lot of movement of staff.

  3. The biggest test is when you have to delegate across a management column and the recipient and his manger don’t want a bar of it. Particularly testing if you are junior in level to the recipients hostile manager.

  4. Engineers and technical people generally make terrible managers as they think in detail terms and direct in detail terms. Many exceptions to that rule though.

  5. A lot of these problems go away if you meet face-to-face at least daily. You must allow your subs to chase you on your promises, just as hard as you follow up their progress. The best CEO I ever worked for (Doug Repton are you reading this) had a weekly management meeting in his office that started at 7 a.m. and ran to 8 a.m. at the very, very latest.

  6. I guess once you know your team, then you can adopt appropriate approaches for different individuals…

    Exactly.

    …but this becomes difficult if there is a lot of movement of staff.

    It’s almost as if management is difficult and thus better paid than ordinary positions and suitable only for certain people.

  7. A lot of these problems go away if you meet face-to-face at least daily.

    Indeed. If you rely on weekly meetings to know what everyone is up to, you’re already in trouble.

  8. Engineers and technical people generally make terrible managers as they think in detail terms and direct in detail terms.

    Yup. The best project engineers are failed discipline engineers, and the best managers are those who couldn’t cut it as a technical engineer. The problem – which has been identified by countless companies but never addressed – is that engineering and technical positions do not carry the same status, benefits, and rewards as managerial positions meaning everyone is chasing management positions they are wholly unsuited to.

  9. and tries to solve technical problems there and then

    My pet hate. My commenting “This is a progress meeting, the answer should be is it done yes or no and if not then when will it be done or what do you need” does not generally go down well. I get snarky because I know it will be my job to deal with the technical problems and the longer the meeting goes, the less time I have to actually fix them.

  10. Your approach is quite good. Sometimes I think trying to find a meeting room and a slot when everyone can attend to be the worst part.

    At Intel Corp., they had separate career tracks, technical and manage,ent. Each could be treated as its own craft with its own skills to master. This worked well. At Daimler, they don’t, so they promote the most technical person to a lead position. That person has no clue how to lead people, create a direction, run an operational plan, or otherwise. They only work on the thorniest technical,problems and become a huge single point of failure because every technical skill or decision lies with them only. So, there are traps everywhere you look when you pick someone to lead your teams.

  11. Moreover, I’ve found engineers feel a lot more valued and respected if you give them an opportunity to propose how they want to do the job

    This only works if they’re competent. If they don’t know how to do the work, but they’re un-sackable, then micro-managing is basically the only option. You could try to pair them with somebody competent, but that will only breed resentment. Any suggestions?

  12. This only works if they’re competent.

    That’s assumed.

    If they don’t know how to do the work, but they’re un-sackable, then micro-managing is basically the only option.

    No, those people you only assign work that doesn’t need doing.

  13. TimN wrote:-“No, those people you only assign work that doesn’t need doing.”

    I’m reminded of a classification system for officers that a Prussian – the elder Moltke? – came up with.

    The officer who is industrious, and intelligent, is a great asset. Make him your Chief of Staff and try not to let him work himself to death as he solves your problems.

    The officer who is lazy, yet intelligent, should be placed in high command: they will seek success, at the lowest cost and effort.

    The officer who is lazy, and ignorant, can be set in many positions where they will do little damage, yet can be goaded to work when required.

    But the officer who is both stupid and hard-working is very dangerous, and should be eliminated before they can cause much harm…

  14. Jason,

    Indeed that is a great quote, applicable to any organisation. What amuses me is I’m happy to say publicly that I’m in the smart and lazy box, while most around me insist they are smart and hard-working.

  15. The two books I’ve found most useful for managing technical teams are The Mythical Man-Month and Just Enough Project Management. Effective meetings is a skill I learned at my very first job, where they Got it Right, but I’ve never seen a good text on that topic. All the ones I’ve seen seem to assume every meeting is exactly the same and has the same purpose, which has not been my experience at all.

  16. I’m clearly in the wrong industry if Fred can take a few days before getting a gentle reminder, giving the task a leisurely look-over when he’s finished his other stuff, chew it over for a while, jet off at the company’s expense for a scout around the site, and then come back with a rough idea of what to do and how much it costs.

  17. Ah, the “if you’re not running around with your arse on fire you can’t be busy” school of management.

  18. Always remember: You can’t delegate responsibility.

    That doesn’t mean don’t delegate at all, nor that you should over supervise, it means don’t let your team think that if they may a mistake they will have to carry the can – they must always believe you have their backs. They must also understand that making the same mistake twice is unacceptable.

  19. There was one company I read about where the ceo had a rule. If you asked someone to do something you had to explain the context. Break the rule once, a warning. Break the rule twice, fired.

    Personally, upwards you think what does your manager need to do his role well and figure out how to deliver that before being explicitly asked. If managing down then what do you need to give the person so they can deliver what you want (1. explain context, 2. discuss what product would make sense, 3. what resources do they need, 4. when is it needed by (flag the non critical then you can get the critical when you need it)). Though I have the benefit of working in an industry with small teams of pretty educated, motivated people, and lots of specialist work outsourced so you are explicitly the customer for those parts of the work.

  20. Though if you read how the kock brothers run a massive organisation they
    1. pay is quite variable and you get paid for value you generate, you get dinged for opportunities you missed and should have seen, people can earn more than their boss
    2. cross departments it is a customer relationship. For many things you can go inhouse, but are not forced to.

  21. “The problem… is that engineering and technical positions do not carry the same status, benefits, and rewards as managerial positions meaning everyone is chasing management positions they are wholly unsuited to.”

    If being the boss doesn’t offer better rewards than being bossed around, then surely it will only attract people for whom bossing around is the reward. (See Gareth, the “team leader” from The Office.)

    Question for management types (not that I’ll ever be in a position to use the advice): in Tim’s scenario, his own manager isn’t breathing down his neck, demanding it all be sorted out yesterday. How do you deal with that – do you pass that pressure on to Fred, or do you stall your own boss? Or both?

  22. How do you deal with that – do you pass that pressure on to Fred, or do you stall your own boss? Or both?

    Subject of tomorrow’s post.

  23. The main conflict in a hf is different people wanting to work on the same trade (when something super interesting comes along) – if management set crude areas of responsibility and then properly referee any border issues then that is fine. Perhaps what you meant is “eat what you kill”, i.e. your pay is 90% determined by how much you make for the firm. That is no different from senior lawyers / bankers / consultants (just the areas I am familiar with) – where they sit inside a company but are effectively running their own business. Given the alternative is that your pay is politically determined, being paid this way lets you dedicate your time to doing your job rather than internal politics.

    Most of the stereo types are badly wrong. The biggest is that hf are seen as being closed minded. In fact, if you are betting money then you care very much about what will happen not what you think should happen. The only way to form accurate views is to have an understanding of how any relevant parties in a situation see the world and thus are likely to behave. You also focus on balancing thinking of ways in which you could be wrong but having enough conviction to actually do something. From what I have seen charity and civil servants (or large bureaucracy) are the opposite where intent and alignment with policy is everything, output isn’t even measured.

  24. @isp001

    Thanks for sharing and dispelling the myths. What I see there is that your remuneration is directly linked to your performance, this has to be a good thing. I work for a private international firm and there are three execs that have major ownership stakes in the firm, all the big decisions are made by them, we are very wary about employees that have no skin in the game making big calls. High performers are invited to join a long term share ownership plan, we find this as effective incentivisation.

  25. The main conflict in a hf is different people wanting to work on the same trade

    I’ve heard this in large law firms, when both Company A and Company B are both major clients of the firm, with two entirely separate teams representing each company. And then Company A sues Company B. The same law firm can’t represent both, so who gets the job? I’ve heard these internal wars get so bad people stop talking to each other in the corridors.

  26. There are benefits to using someone else’s platform. Conflicts are one of the costs. Main conflicts are which clients you can take, what positions you can adopt publicly. Sometimes you don’t go nuclear on suing someone for wider reputational reasons.

    That explains the 10% bit of the compensation.

    In general getting responsiblities / compensation / etc properly aligned is the difference between an organisation that runs itself and one that consumes huge amounts of effort to get nothing done.

  27. “I’ve received very little formal management training.”

    Ah, the joys of management. When I was first given a manager’s job, I went to the head of Human Resources and said, “Look, I have been handed this job and I could with some guidance.”

    His sneering reaction was: “You are a manager. You don’t ask for help.”

    So, I was left to largely figure it out for myself. But I learned two things: first, the job was mostly about making sure people knew what to do and had the resources to help them do it and, second, the head of HR was a prat who I never need talk to again.

Comments are closed.