4 ms·

We don't want to manage engineers we want to manage projects and projects have budgets and deadlines. If you can't deliver then maybe you're not a good enough f

We don't want to manage engineers we want to manage projects and projects have budgets and deadlines. If you can't deliver then maybe you're not a good enough for the job. If you can't even promise then why are you still working at our company? One of the best ways to drive away engineers is to make them commit and then watch them fall into misery when they desperately try to somehow make the deadline. Many weak characters break that way. The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave.

SideburnsOfDoom 4y ago
> Many weak characters break that way. The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave. IDK, but this seems just psychopathic?
- threatripper 4y ago
  Yes, very much so. Although I wonder if those involved are aware of this.
someguydave 4y ago
Why would you want to drive away engineers?
hericium 4y ago
> If you can't deliver then maybe you're not a good enough for the job. I've seen more than once projects with ill-equipped team members. I've been one myself, too. Even in established tech corporations, the process of team creation can be screwed up due to multiple reasons. I've seen DevOps engineers tasked with writing apps because PM did not checked what their role was. And that was a high-importance project in a huge, publicly traded, tech corporation. Expecting engineers to estimate work they haven't done before ends up in guesstimation which is almost never correct. PMs asking for estimations in pioneer projects create problems for themself, which they sometimes later blame on team members.
- threatripper 4y ago
  They are asking because they have been asked themselves. To me it seems like a chain of incompetence from top to bottom, from bottom to top. Everyone is stretched beyond their abilities. The whole company is a house of cards. But yet it keeps on working and often it delivers results that keep everything else up and running. I don't understand why it works this way but it does.
ozim 4y ago
You write that you don't want to manage engineers? But from what you write you cannot manage budgets and deadlines. Managing budget and deadlines is not about setting some "ideal world" and then whipping these lazy engineers to deliver exactly that. Managing budget and deadlines is about - well we delivered X/Y at that date it already was $yyy in terms of money. If it went well maybe you can increase work load, maybe look at things again and stop gold-plating to move further. If it went wrong cut the scope - check what went wrong, lower the risk of not delivering by simplifying tasks. Check if maybe you miss some specialistic knowledge to hire someone to help and account that risk against budget or tell customer that you need something specific that they have to deliver.
wildrhythms 4y ago
>The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave. Manipulative, psychopathic behavior, and you are a bad manager.
- SideburnsOfDoom 4y ago
  Yep. "I'm asking you to estimate this unknowable thing, pressure you to give me a small answer, and if you get it wrong, you're 'weak'". This is tinpot-tyrant stuff. I saw that in a movie: "no, the German people have failed _me_, they were weak, and deserve to suffer for it".
jen20 4y ago
Funnily enough, engineers want to do actual work and not manage up for hapless Machiavellian middle managers.
Dudeman112 4y ago
I'm glad you're not my manager and that I can choose not to work for managers like you
FrankyHollywood 4y ago
The question is often 'how long does it take to implement'. Engineers know if it is more or less clear what the functional requirements. In practice, workdays are constantly interrupted by meetings. An 8 hr workday is effectively 2-4hrs product building. Than there are unforseen deployment problems, some requirements change, solve merge conflicts, perform code reviews, frameworks need vulnerability updates, etc. An experienced PM knows this and should not use implementation time as project duration.
mancerayder 4y ago
> Many weak characters break that way. The trick is to make them choose their own deadline and fail. I think I missed the title, main topic or perhaps even what you were replying to when you wrote this. Maybe there is a context. In its absence, this reads like a HowTo for getting someone you already don't like, to quit. Clear communication is a very important managerial skill, by the way.

SideburnsOfDoom 4y ago

> Many weak characters break that way. The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave. IDK, but this seems just psychopathic?

threatripper 4y ago
Yes, very much so. Although I wonder if those involved are aware of this.

someguydave 4y ago

Why would you want to drive away engineers?

hericium 4y ago

> If you can't deliver then maybe you're not a good enough for the job. I've seen more than once projects with ill-equipped team members. I've been one myself, too. Even in established tech corporations, the process of team creation can be screwed up due to multiple reasons. I've seen DevOps engineers tasked with writing apps because PM did not checked what their role was. And that was a high-importance project in a huge, publicly traded, tech corporation. Expecting engineers to estimate work they haven't done before ends up in guesstimation which is almost never correct. PMs asking for estimations in pioneer projects create problems for themself, which they sometimes later blame on team members.

threatripper 4y ago
They are asking because they have been asked themselves. To me it seems like a chain of incompetence from top to bottom, from bottom to top. Everyone is stretched beyond their abilities. The whole company is a house of cards. But yet it keeps on working and often it delivers results that keep everything else up and running. I don't understand why it works this way but it does.

ozim 4y ago

You write that you don't want to manage engineers? But from what you write you cannot manage budgets and deadlines. Managing budget and deadlines is not about setting some "ideal world" and then whipping these lazy engineers to deliver exactly that. Managing budget and deadlines is about - well we delivered X/Y at that date it already was $yyy in terms of money. If it went well maybe you can increase work load, maybe look at things again and stop gold-plating to move further. If it went wrong cut the scope - check what went wrong, lower the risk of not delivering by simplifying tasks. Check if maybe you miss some specialistic knowledge to hire someone to help and account that risk against budget or tell customer that you need something specific that they have to deliver.

wildrhythms 4y ago

>The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave. Manipulative, psychopathic behavior, and you are a bad manager.

SideburnsOfDoom 4y ago
Yep. "I'm asking you to estimate this unknowable thing, pressure you to give me a small answer, and if you get it wrong, you're 'weak'". This is tinpot-tyrant stuff. I saw that in a movie: "no, the German people have failed _me_, they were weak, and deserve to suffer for it".

jen20 4y ago

Funnily enough, engineers want to do actual work and not manage up for hapless Machiavellian middle managers.

Dudeman112 4y ago

I'm glad you're not my manager and that I can choose not to work for managers like you

FrankyHollywood 4y ago

The question is often 'how long does it take to implement'. Engineers know if it is more or less clear what the functional requirements. In practice, workdays are constantly interrupted by meetings. An 8 hr workday is effectively 2-4hrs product building. Than there are unforseen deployment problems, some requirements change, solve merge conflicts, perform code reviews, frameworks need vulnerability updates, etc. An experienced PM knows this and should not use implementation time as project duration.

mancerayder 4y ago

> Many weak characters break that way. The trick is to make them choose their own deadline and fail. I think I missed the title, main topic or perhaps even what you were replying to when you wrote this. Maybe there is a context. In its absence, this reads like a HowTo for getting someone you already don't like, to quit. Clear communication is a very important managerial skill, by the way.