4 ms·

At the same time, how many of us have been burnt when delegation goes wrong? I think managers have a "fool me once shame on you, fool me twice shame on me" atti

At the same time, how many of us have been burnt when delegation goes wrong? I think managers have a "fool me once shame on you, fool me twice shame on me" attitude that inevitably leads to small tasks and less delegation of responsibility after a few bad experiences with developers wandering off in the woods and building what they want and not what is needed.

vorpalhex 6y ago
Delegating and trusting someone doesn't mean a task never goes badly. Part of delegation is meeting and touching base with work that is ongoing. Participate in code reviews, have regular 1:1s with people you are delegating to. And yes, you're not going to end up with your exact vision when you delegate. The question is whether the end goal is sufficient and minimal, and if not then you should evolve that with the other people involved.
- monkeybutton 6y ago
  Absolutely delegation should still mean being involved in the process and being receptive to course correction from the people carrying out the work. This is how things should work. Ideally. In practice I've seen it go the opposite way where management's reaction is trust less and less, making smaller and smaller tasks. Developers aren't innocent either, instead of griping about having less control, they throw up their hands and work-to-rule. Doesn't matter if the task description has obvious problems, that's what is getting implemented. Nothing less and nothing more. Honestly this all comes off as toxic. Maybe it's high time to leave where I am seeing this all go on.
  - lliamander 6y ago
    > Maybe it's high time to leave where I am seeing this all go on. From my own experience, I would say yes.
mobjack 6y ago
It is also really nice to trust a developer enough where I can give a broad tasks and not worry about it. It takes a big cognitive load off of me. I don't enjoy small tasks as a manager but they can be necessary depending on how much I trust someone.
treis 6y ago
The bigger problem is that if you delegate A and B to Vincent as the article suggests is that often it becomes King Vincent lord and ruler of A and B. They are the only one allowed to touch A and B, and worse may be the only one's capable of touching A and B. You can end up with a bunch of these little fiefdoms and getting anything done quickly becomes an issue of appeasing a few petty despots. That's a little bit extreme for example but there's definitely benefits to standardizing things across projects.
- jrumbut 6y ago
  If you don't create the King Vincent, you become the King Vincent.
  - treis 6y ago
    Not really. Even if you have one person architecting the system you will have at least a couple developers implementing. Knowledge will be spread across multiple people preventing any one of them being indespensible.
- tonyarkles 6y ago
  The author has another article about that. They’re allowed to be the lord and ruler of A and B, but also responsible for them. A and B are the consistent bottleneck to release? Maybe B should belong to someone else. Petty despots don’t get to keep their toys.
analog31 6y ago
In my view, if you say, "I'll never trust someone again if they ever make a mistake," then you'll be deservedly miserable as a manager, and you've never raised kids. ;-) You might have to take baby steps. Can you watch someone make a mistake without intervening? Can you do so without severe emotional turmoil? Most managers never break the micromanagement habit, and will always pay the price. Probably the biggest price of not trusting people is that they don't trust you either, and they find ways to keep you out of the loop so they can make decisions and get work done. This in turn causes you to trust them even less. Distrust is a self fulfilling death spiral. You might have no choice, e.g., if you work in a micromanagerial culture. Can your boss watch you, as you are watching someone make a mistake? In other words, are your management habits the source of a culture, or merely its effect? Thus the final step is: Can you stick up for your people after they've made a mistake?
bitwize 6y ago
The answer to that is to sit down with the developer -- like an adult -- and talk to them about priorities in terms of what the user wants and the business needs. Just tell them point blank, "the thing doesn't need to read mail, but we really need features X, Y, and Z to have an MVP, so please concentrate your efforts there." Some of my best jobs involved constructive discussions with my managers just like this. If a developer is any good, they're smart. It's okay to treat them like a fully functioning person.

vorpalhex 6y ago

Delegating and trusting someone doesn't mean a task never goes badly. Part of delegation is meeting and touching base with work that is ongoing. Participate in code reviews, have regular 1:1s with people you are delegating to. And yes, you're not going to end up with your exact vision when you delegate. The question is whether the end goal is sufficient and minimal, and if not then you should evolve that with the other people involved.

monkeybutton 6y ago
Absolutely delegation should still mean being involved in the process and being receptive to course correction from the people carrying out the work. This is how things should work. Ideally. In practice I've seen it go the opposite way where management's reaction is trust less and less, making smaller and smaller tasks. Developers aren't innocent either, instead of griping about having less control, they throw up their hands and work-to-rule. Doesn't matter if the task description has obvious problems, that's what is getting implemented. Nothing less and nothing more. Honestly this all comes off as toxic. Maybe it's high time to leave where I am seeing this all go on.
- lliamander 6y ago
  > Maybe it's high time to leave where I am seeing this all go on. From my own experience, I would say yes.

mobjack 6y ago

It is also really nice to trust a developer enough where I can give a broad tasks and not worry about it. It takes a big cognitive load off of me. I don't enjoy small tasks as a manager but they can be necessary depending on how much I trust someone.

treis 6y ago

The bigger problem is that if you delegate A and B to Vincent as the article suggests is that often it becomes King Vincent lord and ruler of A and B. They are the only one allowed to touch A and B, and worse may be the only one's capable of touching A and B. You can end up with a bunch of these little fiefdoms and getting anything done quickly becomes an issue of appeasing a few petty despots. That's a little bit extreme for example but there's definitely benefits to standardizing things across projects.

jrumbut 6y ago
If you don't create the King Vincent, you become the King Vincent.
- treis 6y ago
  Not really. Even if you have one person architecting the system you will have at least a couple developers implementing. Knowledge will be spread across multiple people preventing any one of them being indespensible.
tonyarkles 6y ago
The author has another article about that. They’re allowed to be the lord and ruler of A and B, but also responsible for them. A and B are the consistent bottleneck to release? Maybe B should belong to someone else. Petty despots don’t get to keep their toys.

analog31 6y ago

In my view, if you say, "I'll never trust someone again if they ever make a mistake," then you'll be deservedly miserable as a manager, and you've never raised kids. ;-) You might have to take baby steps. Can you watch someone make a mistake without intervening? Can you do so without severe emotional turmoil? Most managers never break the micromanagement habit, and will always pay the price. Probably the biggest price of not trusting people is that they don't trust you either, and they find ways to keep you out of the loop so they can make decisions and get work done. This in turn causes you to trust them even less. Distrust is a self fulfilling death spiral. You might have no choice, e.g., if you work in a micromanagerial culture. Can your boss watch you, as you are watching someone make a mistake? In other words, are your management habits the source of a culture, or merely its effect? Thus the final step is: Can you stick up for your people after they've made a mistake?

bitwize 6y ago

The answer to that is to sit down with the developer -- like an adult -- and talk to them about priorities in terms of what the user wants and the business needs. Just tell them point blank, "the thing doesn't need to read mail, but we really need features X, Y, and Z to have an MVP, so please concentrate your efforts there." Some of my best jobs involved constructive discussions with my managers just like this. If a developer is any good, they're smart. It's okay to treat them like a fully functioning person.