11 ms·

Agree with most points but one which is making a manager do coding/shipping. Most of IT managers I met possessed no real IT skills. They wrapped their heads ar

Agree with most points but one which is making a manager do coding/shipping. Most of IT managers I met possessed no real IT skills. They wrapped their heads around only as much theory as needed to _manage_. Most of them did not came from engineering world but from business one. Ideally, manager should be able to do the work their team is doing, but reality is quite different. I stopped expecting managers to understand what I do outside of expected effects. Regarding estimates, it really is frustrating when a non-technical manager cannot understand the inability to state any reasonable time estimation. - so how long will it take you to finish this task? - no idea, haven't done anything like that in the past - ok, so how long?

threatripper 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. 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
  - 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
Closi 4y ago
> Regarding estimates, it really is frustrating when a non-engineering manager cannot understand the inability to state any reasonable time estimation. On the flipside, it can be frustrating for managers that engineers sometimes can’t understand that they have to manage deadlines. If the engineer doesn’t make an educated guess at the time it will take then the manager is put in the position of making a non-educated guess (because you can’t effectively run a company without having any idea of either time or cost to deliver). The idea that it’s possible to have a project with no budget or time constraints just isn’t often the reality of the situation. Imagine going to a customer and having to say “Ok, we’ve talked to the engineering team and in order to deliver that feature you asked for they might be able to deliver it in a day for £2,000 or in a year for £500,000” This doesn’t mean that you can’t give sensical ranges, or state your assumptions when doing the estimate.
- foldr 4y ago
  >The idea that it’s possible to have a project with no budget or time constraints just isn’t often the reality of the situation. It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost. Time is almost always more flexible than the people imposing the deadlines think that it is. As for budget, you just have to choose to keep spending more, or to stop (or wait till you run out of money). Making up an estimate beforehand doesn't alter that process. If management were really in the business of setting budget and time constraints, projects would constantly be getting canceled because they went $100 over budget or a week over time. In reality we all know what usually happens: the project simply continues; the estimates, deadlines, etc. are shifted.
  - Closi 4y ago
    > It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost. Making decisions on the basis of an estimate which could be plus or minus 50% is fine. It’s better than making a decision on the basis of nothing at all, and then managing the project with no clue about how long it should be taking or costing. > If management were really in the business of setting budget and time constraints, projects would constantly be getting canceled because they went $100 over budget or a week over time. This isn’t the idea of estimates - the main idea is so you can effectively allocate resource and understand cost/benefit. All companies have limited resources and must decide if they want to focus on feature A or feature B, and part of that decision will be the likely cost, risk, and timeline to deliver. You aren’t going to cancel a project when it goes (a bit) over budget because the development costs to date are already sunk (ie you only now need to consider remaining development effort in the cost/benefits calc) and the benefits are probably still the same.
bryanrasmussen 4y ago
Most engineers can guestimate, but I do know one that would say the following: no idea, I will have to do two days of research on the matter and come back to you with an estimate in standup the day after tomorrow. (really, he said exactly that one time, it was a wonderful expression of his character I thought) The person who just says no idea, and doesn't have a way to get to an idea, seems to have a very problematic limitation.
- wildrhythms 4y ago
  I don't agree with this. If an engineer can't estimate how long something will take, usually that's an indication that your requirements are unclear, or there's a history of changing up requirements on people. What you've labeled as a limitation is probably an engineer being honest with you.
  - bryanrasmussen 4y ago
    ok so in this case I would probably expect them to say: the requirements are unclear - that right there is them having an idea how they are going to be able to give you an estimate, by forcing you to be clear in your requirements. That would actually be an engineer being honest. or there is a history of changing up requirements on issues like this, I can give you the estimate of what it will be with the current requirements but if the requirements change, as in my experience they are likely to, then that estimate will have to change as well. - this would also be an engineer being honest. Both of those honest examples aside if the engineer replies no I can't make an estimate and I never will be able to it is probably the engineer being a bit pissy. And I know definitely one or two guys who would exactly behave in this manner. unless you are dealing with the first time implementation of something that there is only mathematical theory backing it and no previous implementations in the world, I have a hard time seeing how you can construct a situation in which an engineer cannot come with an estimate AND cannot find a way to figure out what they need to come with an estimate (more specific requirements, research on the matter). If they can't figure out at least one of those things I'm going to think it is probably a limitation on the part of that engineer. Finally, I am an engineer. Although I tend to be one of those arrogant guestimaters, which is a failing in my personality.
theshrike79 4y ago
In those cases the correct answer is "Dunno, but I'll have an estimate by tomorrow after I do some prototyping". Then you do the janky prototype and try to extrapolate how long will it take to finish it properly. Then double that and be the miracle worker who delivers in half the time :)
- greenbit 4y ago
  But do not under any circumstances be tempted to demonstrate said janky prototype, unless you want to get re-tasked while said janky prototype gets merged into the build because 'schedule' .. and then be haunted by the damned thing for at least the next three years
  - threatripper 4y ago
    I know exactly what you're talking about. The first rule of the meeting is "shut up" and the second rule is "keep silent" and "watch your mouth". I don't know why it is so hard to stick to those simple rules when the solution to the engineering problem seems so obvious.
  - theshrike79 4y ago
    Yep, janky needs to look janky and be slow and break. Otherwise they'll think it already works :D That's also why you always keep the UI on par with the backend as far as completion goes. If the UI looks complete -> people think the backend is complete too. Only Coder GUIs until the backend is done :)
hibernator149 4y ago
- Manager: How long would it take to migrate from A to let's say B? - Me: How would I know that? - Manager: Just make an educated guess. - Me: Maybe X months? I really don't know. - Manager writes down X. - Me makes a mental note to not trust Manager again... Maybe it's better to have any plan than to have no plan, but having a plan based on known bad data can't be the solution. Dear Managers, if your plan requires data that just isn't available, please take the time to ask yoursevles if you are micromanaging. Going with a less concrete plan is definitely better than going with a plan based on wrong assumptions! Maybe you are in a position where deadlines just make no sense and you need to be more agile?
- Ensorceled 4y ago
  - Manager: How long would it take to migrate from A to let's say B? - Me: What do we want to accomplish from the migration? I'm assuming cost reduction? - Manager: Yeah, the guys at B are much cheaper. - Me: Ok, give me until EOD Friday to do some investigation. - Manager: EOD Thursday would be better, don't need a full roadmap, just enough for an ROI. I'll flip over the CEO's spreadsheet that she's using for the calculation. - Me: This means Feature X is dropping from this sprint. - Manager: Yep. Dear Mes: Grow up and participate in the process rather than starting off with snark.
  - switch007 4y ago
    Hah if only managers were that grown up too. I’ve tried those conversations. Firstly, that Friday deadline likely would have been fine, it was just a power play. Secondly, when the manager said “yep” to dropping the feature, you’ll still be expected to make progress. (Of course most of the time they try to make you do double the work. A quick “yep” wouldn’t happen IRL)
    - Ensorceled 4y ago
      Get a new manager. Seriously.
      - 4y ago
sokoloff 4y ago
I think the mismatch is partly that your early experiences (family, teachers, and team leads) are with leaders who literally know more than you about most topics and could do any task they’re asking you to do. That imprinting is strong. Then, when you get to interact with Directors and VPs who have teams across 5-20 disciplines and the senior leader could be an expert in a maximum of one of them, you start to question why this person can’t do your job and therefore think, they must be an idiot. They might be, but it’s more likely they’re past the point where they are more subject matter expert in the field than the people they lead.

threatripper 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. 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
- 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

Closi 4y ago

> Regarding estimates, it really is frustrating when a non-engineering manager cannot understand the inability to state any reasonable time estimation. On the flipside, it can be frustrating for managers that engineers sometimes can’t understand that they have to manage deadlines. If the engineer doesn’t make an educated guess at the time it will take then the manager is put in the position of making a non-educated guess (because you can’t effectively run a company without having any idea of either time or cost to deliver). The idea that it’s possible to have a project with no budget or time constraints just isn’t often the reality of the situation. Imagine going to a customer and having to say “Ok, we’ve talked to the engineering team and in order to deliver that feature you asked for they might be able to deliver it in a day for £2,000 or in a year for £500,000” This doesn’t mean that you can’t give sensical ranges, or state your assumptions when doing the estimate.

foldr 4y ago
>The idea that it’s possible to have a project with no budget or time constraints just isn’t often the reality of the situation. It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost. Time is almost always more flexible than the people imposing the deadlines think that it is. As for budget, you just have to choose to keep spending more, or to stop (or wait till you run out of money). Making up an estimate beforehand doesn't alter that process. If management were really in the business of setting budget and time constraints, projects would constantly be getting canceled because they went $100 over budget or a week over time. In reality we all know what usually happens: the project simply continues; the estimates, deadlines, etc. are shifted.
- Closi 4y ago
  > It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost. Making decisions on the basis of an estimate which could be plus or minus 50% is fine. It’s better than making a decision on the basis of nothing at all, and then managing the project with no clue about how long it should be taking or costing. > If management were really in the business of setting budget and time constraints, projects would constantly be getting canceled because they went $100 over budget or a week over time. This isn’t the idea of estimates - the main idea is so you can effectively allocate resource and understand cost/benefit. All companies have limited resources and must decide if they want to focus on feature A or feature B, and part of that decision will be the likely cost, risk, and timeline to deliver. You aren’t going to cancel a project when it goes (a bit) over budget because the development costs to date are already sunk (ie you only now need to consider remaining development effort in the cost/benefits calc) and the benefits are probably still the same.

bryanrasmussen 4y ago

Most engineers can guestimate, but I do know one that would say the following: no idea, I will have to do two days of research on the matter and come back to you with an estimate in standup the day after tomorrow. (really, he said exactly that one time, it was a wonderful expression of his character I thought) The person who just says no idea, and doesn't have a way to get to an idea, seems to have a very problematic limitation.

wildrhythms 4y ago
I don't agree with this. If an engineer can't estimate how long something will take, usually that's an indication that your requirements are unclear, or there's a history of changing up requirements on people. What you've labeled as a limitation is probably an engineer being honest with you.
- bryanrasmussen 4y ago
  ok so in this case I would probably expect them to say: the requirements are unclear - that right there is them having an idea how they are going to be able to give you an estimate, by forcing you to be clear in your requirements. That would actually be an engineer being honest. or there is a history of changing up requirements on issues like this, I can give you the estimate of what it will be with the current requirements but if the requirements change, as in my experience they are likely to, then that estimate will have to change as well. - this would also be an engineer being honest. Both of those honest examples aside if the engineer replies no I can't make an estimate and I never will be able to it is probably the engineer being a bit pissy. And I know definitely one or two guys who would exactly behave in this manner. unless you are dealing with the first time implementation of something that there is only mathematical theory backing it and no previous implementations in the world, I have a hard time seeing how you can construct a situation in which an engineer cannot come with an estimate AND cannot find a way to figure out what they need to come with an estimate (more specific requirements, research on the matter). If they can't figure out at least one of those things I'm going to think it is probably a limitation on the part of that engineer. Finally, I am an engineer. Although I tend to be one of those arrogant guestimaters, which is a failing in my personality.

theshrike79 4y ago

In those cases the correct answer is "Dunno, but I'll have an estimate by tomorrow after I do some prototyping". Then you do the janky prototype and try to extrapolate how long will it take to finish it properly. Then double that and be the miracle worker who delivers in half the time :)

greenbit 4y ago
But do not under any circumstances be tempted to demonstrate said janky prototype, unless you want to get re-tasked while said janky prototype gets merged into the build because 'schedule' .. and then be haunted by the damned thing for at least the next three years
- threatripper 4y ago
  I know exactly what you're talking about. The first rule of the meeting is "shut up" and the second rule is "keep silent" and "watch your mouth". I don't know why it is so hard to stick to those simple rules when the solution to the engineering problem seems so obvious.
- theshrike79 4y ago
  Yep, janky needs to look janky and be slow and break. Otherwise they'll think it already works :D That's also why you always keep the UI on par with the backend as far as completion goes. If the UI looks complete -> people think the backend is complete too. Only Coder GUIs until the backend is done :)

hibernator149 4y ago

- Manager: How long would it take to migrate from A to let's say B? - Me: How would I know that? - Manager: Just make an educated guess. - Me: Maybe X months? I really don't know. - Manager writes down X. - Me makes a mental note to not trust Manager again... Maybe it's better to have any plan than to have no plan, but having a plan based on known bad data can't be the solution. Dear Managers, if your plan requires data that just isn't available, please take the time to ask yoursevles if you are micromanaging. Going with a less concrete plan is definitely better than going with a plan based on wrong assumptions! Maybe you are in a position where deadlines just make no sense and you need to be more agile?

Ensorceled 4y ago
- Manager: How long would it take to migrate from A to let's say B? - Me: What do we want to accomplish from the migration? I'm assuming cost reduction? - Manager: Yeah, the guys at B are much cheaper. - Me: Ok, give me until EOD Friday to do some investigation. - Manager: EOD Thursday would be better, don't need a full roadmap, just enough for an ROI. I'll flip over the CEO's spreadsheet that she's using for the calculation. - Me: This means Feature X is dropping from this sprint. - Manager: Yep. Dear Mes: Grow up and participate in the process rather than starting off with snark.
- switch007 4y ago
  Hah if only managers were that grown up too. I’ve tried those conversations. Firstly, that Friday deadline likely would have been fine, it was just a power play. Secondly, when the manager said “yep” to dropping the feature, you’ll still be expected to make progress. (Of course most of the time they try to make you do double the work. A quick “yep” wouldn’t happen IRL)
  - Ensorceled 4y ago
    Get a new manager. Seriously.
    - 4y ago

sokoloff 4y ago

I think the mismatch is partly that your early experiences (family, teachers, and team leads) are with leaders who literally know more than you about most topics and could do any task they’re asking you to do. That imprinting is strong. Then, when you get to interact with Directors and VPs who have teams across 5-20 disciplines and the senior leader could be an expert in a maximum of one of them, you start to question why this person can’t do your job and therefore think, they must be an idiot. They might be, but it’s more likely they’re past the point where they are more subject matter expert in the field than the people they lead.