4 ms·

Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often sta

Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. A total nightmare for project management.

jen20 4y ago
> A total nightmare for project management. If there is not enough information to make informed schedules, the only reasonable option is to DO MORE RESEARCH, not guess. Better still is to not try to create some master plan that requires things like this to be known at all.
bratbag 4y ago
I don't agree. Its perfectly reasonable not to have any idea about an estimate until after an investigation or prototype has been produced. Demanding an estimate up front for something totally new just makes you look inexperianced or bad at managing engineers.
- threatripper 4y ago
  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.
- blowski 4y ago
  The Cynefin framework can be really useful for having this conversation. https://lizkeogh.com/cynefin-for-developers/ https://lizkeogh.com/cynefin-for-developers/ How well do the people executing the project know the codebase, data, and tech stack they're working with? How understood and confirmed are the requirements? The less those things are true, the less certain you can be with estimates. At the extreme, all you can do is poke the system and commit to providing feedback on what you've learned. At the same time, you should be trying to make the system more lucid, both for yourself and new joiners on the team, such that estimates can become more accurate. The more senior you are as an engineer, the quicker you should be able to do that.
- magicalhippo 4y ago
  When I'm asked by my boss to estimate, I break it down for him. This part here I'm confident is 1-2 days of work, this part here can potentially be tricky so could be 1 day could be a week, and this part here I can't tell without digging into the details. If this is based on a customer request I'll try to find some restrictions he could take back to the customer to narrow the scope and provide a better estimate assuming those restrictions. Most of the time this is all he needs.
  - threatripper 4y ago
    What if he asks you for a number instead of a range? After all you have to use the company template to present your project and that does not have ranges on it.
    - magicalhippo 4y ago
      If for example, I say 3-7 days and he wants a single number because customer wants a date, he'll ask me "ok, so if I say to the customer they'll get the change in 10 days, we should be able to deliver?" Then I say yes, under the assumption of X, Y and Z that sounds realistic to me. Of course, sometimes the numbers are to high. That's where narrowing the scope or even finding a different solution comes in.
SideburnsOfDoom 4y ago
> Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. So you're saying that 1) engineers have to be forced to "commit to a schedule" and b) that schedule then turns out to be fantasy. I want you to think harder about what you said and where the problem actually lies. Maybe the engineers know something, about what's knowable upfront, that you don't.
- threatripper 4y ago
  True, the problem lies somewhere else. Maybe the project should not exist at all if it's not manageable. The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time?" and if you cannot then you should not take the project. The problem is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the engineers we have and that means to push them harder than they are used to. If they succeed, then great.
  - SideburnsOfDoom 4y ago
    > The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time? Incorrect, it implies "can you do it in a reasonable time, that is as yet unknown and unknowable" - which might even be quite small, but no-one really knows, so committing to a fixed deadline is at best fooling yourself, and is more likely a trap. > is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the engineers we have and that means to push them harder than they are used to. If they succeed, then great. I think that problem is that this is an intentionally deceptive, demented burnout-factory, and no decent engineer would want to work for you.
    - threatripper 4y ago
      How could you make project management plans that imply deadlines if you don't have deadlines? Yeah, maybe it's not such a smart idea to start with commitments that imply dates. But that's how it is. If you want to work in your own way then start your own company, I guess. Maybe it's time to do that.
hericium 4y ago
> Nobody can work with engineers who are unwilling to commit to a schedule Inability to state a time estimate is not the same as unwillingness to commit to a schedule. You sometimes do pioneering work which you really have no clue how long can take. Estimating just writing code or doing something repetitive is easier than estimating research + prototyping/engineering.
hibernator149 4y ago
If engineers are unwilling to commit to a schedule, then here are some things that might help: - Make sure that the requirements are solid (you can't commit if you don't know to what you are committing) - Make sure that the environment is consistent (I can't commit to a timeline if the people on my team are constantly rotated around) - Ask the enigneers why they can't or don't want to commit and fix that

jen20 4y ago

> A total nightmare for project management. If there is not enough information to make informed schedules, the only reasonable option is to DO MORE RESEARCH, not guess. Better still is to not try to create some master plan that requires things like this to be known at all.

bratbag 4y ago

I don't agree. Its perfectly reasonable not to have any idea about an estimate until after an investigation or prototype has been produced. Demanding an estimate up front for something totally new just makes you look inexperianced or bad at managing engineers.

threatripper 4y ago
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.
blowski 4y ago
The Cynefin framework can be really useful for having this conversation. https://lizkeogh.com/cynefin-for-developers/ https://lizkeogh.com/cynefin-for-developers/ How well do the people executing the project know the codebase, data, and tech stack they're working with? How understood and confirmed are the requirements? The less those things are true, the less certain you can be with estimates. At the extreme, all you can do is poke the system and commit to providing feedback on what you've learned. At the same time, you should be trying to make the system more lucid, both for yourself and new joiners on the team, such that estimates can become more accurate. The more senior you are as an engineer, the quicker you should be able to do that.
magicalhippo 4y ago
When I'm asked by my boss to estimate, I break it down for him. This part here I'm confident is 1-2 days of work, this part here can potentially be tricky so could be 1 day could be a week, and this part here I can't tell without digging into the details. If this is based on a customer request I'll try to find some restrictions he could take back to the customer to narrow the scope and provide a better estimate assuming those restrictions. Most of the time this is all he needs.
- threatripper 4y ago
  What if he asks you for a number instead of a range? After all you have to use the company template to present your project and that does not have ranges on it.
  - magicalhippo 4y ago
    If for example, I say 3-7 days and he wants a single number because customer wants a date, he'll ask me "ok, so if I say to the customer they'll get the change in 10 days, we should be able to deliver?" Then I say yes, under the assumption of X, Y and Z that sounds realistic to me. Of course, sometimes the numbers are to high. That's where narrowing the scope or even finding a different solution comes in.

SideburnsOfDoom 4y ago

> Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. So you're saying that 1) engineers have to be forced to "commit to a schedule" and b) that schedule then turns out to be fantasy. I want you to think harder about what you said and where the problem actually lies. Maybe the engineers know something, about what's knowable upfront, that you don't.

threatripper 4y ago
True, the problem lies somewhere else. Maybe the project should not exist at all if it's not manageable. The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time?" and if you cannot then you should not take the project. The problem is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the engineers we have and that means to push them harder than they are used to. If they succeed, then great.
- SideburnsOfDoom 4y ago
  > The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time? Incorrect, it implies "can you do it in a reasonable time, that is as yet unknown and unknowable" - which might even be quite small, but no-one really knows, so committing to a fixed deadline is at best fooling yourself, and is more likely a trap. > is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the engineers we have and that means to push them harder than they are used to. If they succeed, then great. I think that problem is that this is an intentionally deceptive, demented burnout-factory, and no decent engineer would want to work for you.
  - threatripper 4y ago
    How could you make project management plans that imply deadlines if you don't have deadlines? Yeah, maybe it's not such a smart idea to start with commitments that imply dates. But that's how it is. If you want to work in your own way then start your own company, I guess. Maybe it's time to do that.

hericium 4y ago

> Nobody can work with engineers who are unwilling to commit to a schedule Inability to state a time estimate is not the same as unwillingness to commit to a schedule. You sometimes do pioneering work which you really have no clue how long can take. Estimating just writing code or doing something repetitive is easier than estimating research + prototyping/engineering.

hibernator149 4y ago

If engineers are unwilling to commit to a schedule, then here are some things that might help: - Make sure that the requirements are solid (you can't commit if you don't know to what you are committing) - Make sure that the environment is consistent (I can't commit to a timeline if the people on my team are constantly rotated around) - Ask the enigneers why they can't or don't want to commit and fix that