3 ms·

Some of what you said is true, but your analog is a little off. It wasn’t a junior and a senior in the same role, it was a technical team deputized to do what t

by svnt 4y ago

Some of what you said is true, but your analog is a little off. It wasn’t a junior and a senior in the same role, it was a technical team deputized to do what they did, and a management group that apparently thought the deputies would fail, or convinced themselves their conclusions were wrong. The failure here is not one of lack of politics or communication on the part of the author or their team, but on the culture of the management team. Why invite that presentation if all it does is publicly humiliate your PMs? Could the deputies have done more? How is amateur politicking by technical contributors perceived at your place of work?

sillysaurusx 4y ago
For what it’s worth, I don’t think they could have done more. But the conclusion of the story is to heroically drive off a cliff, and say “it’s all I could do.” That’s where I disagree. If it were me, I would have privately (emphasis on private) worked my way up the chain of command, trying to alert more and more people that there was a serious problem brewing. The meeting in the story was obviously going to be a failure. So if you’re in a situation where you know that X is going to fail, doing something other than X is advisable. I would’ve tried to work with the deputized team to come up with a smaller plan that could be executed in, say, three months, and then figured out how to sell it to management in a way that three months isn’t a dealbreaker. Alternatively, I would have gone to management ahead of the meeting and let them know privately what they should expect to hear. That way they’re not completely surprised when you’re in Zoom, presenting a 12 month extension, and they have to say something. “It would be career limiting” is about the best thing they could say. You want to give them a better alternative. And giving management good alternatives is arguably the job of line engineers like us. We’re a part of a team; our job isn’t merely to do what we’re told, nor is it to say blatantly that a project is doomed. There’s usually a middle ground.
- peteradio 4y ago
  I don't understand how the deputized team drove off the cliff. At the very least they surfaced the set of problems which would need to be addressed to meet the contract.
  - sillysaurusx 4y ago
    The end of the story is that they left the company. That’s a fine way to end the story, and maybe that doesn’t seem like defeat. But there tends to be better ways to handle it. Most people can’t afford to leave at a week’s notice, which is what I meant by driving off a cliff.
  - jacobr1 4y ago
    The 12 month extension was going to get the managers who proposed it fired. So they couldn't actually propose it - thus the cliff. Instead they needed an alternative. Of course a better discussion would have been a frank reevaluation with the client, with several options and points of trade-off to consider. But really the best way - presuming everyone is working toward the same ends (NOT a given) - is to identify some kind of MVP/pilot that can been delivered and evaluated and iterated upon. That way you have _some_ kind of success to build upon with the client. This is failure of every badly run waterfall project. Even presuming the original design could be built on time ... how would it know it was actually useful? You also need the more limited success to rebuild trust - otherwise your new estimates will be questioned and looked upon with suspicion. If some tells me an 18 month project is going to take another 12 months, I need to assume the same incompetence really means that the new estimate is behind the curve as well ... not to mention changing requirements in the meantime continuing to push thing things out.
    - jrochkind1 4y ago
      > presuming everyone is working toward the same ends (NOT a given) I have realized that in many cases neither the decision-makers at the client nor the decision-makers at the consultant/vendor are working towards the ends of a succesful product. Their ends are their careers, and benefit to their careers may be pretty orthogonal to actual product success. Once when I was working at a place, I had a discussion: "I think if we use this vendor solution, it's likely to not work very well for our users. I think we have a better chance of meeting our users needs doing it in-house." "You could very well be right, but if we do it in-house and fail, it'll be our fault, everyone will blame us. Everyone is used to using the vendor for this, it's a decision nobody will blame us for, even if it fails. We're going with the vendor." In some cases, everyone can in fact have their goals aligned... their goals simply aren't product success.
- BlargMcLarg 4y ago
  Your solution to a dumpster fire is to play a very risky game of hero, navigating an environment where at any point you could step on someone's toes, in hopes of salvaging a project for which there is absolutely no guarantee you'll get credit, let alone a sizeable reward, while the market is rife with opportunities. For a bunch of capitalists, not some noble goal. Forgive me, but playing hero (really just martyr) sounds like the absolute least logical thing to do.
  - WindyLakeReturn 4y ago
    I have to agree. When the risk is greater than the reward, you have to ask if the project is worth sacrificing for. I find the answer is generally no. Even noble projects are set into situations where it isn't worth the sacrifice. From a purely pragmatic view, you can do better for the world by skipping the sacrifice and finding a similar noble project to keep working at. It is a sort of prisoner's dilemma. Society is worse off because people tend to operate this way, not just in IT but all over. But we aren't going to fix society, so build a small kingdom in your life you can control and try to make things nice within it.
  - jorgesborges 4y ago
    Not necessarily — the person you’re responding to said you can always ride it out if you don’t want to take on more responsibilities. That’s fair to me: look for solutions if it suits you, but otherwise stay silent and don’t introduce negativity (which is bad for you politically in addition to being bad for the project).
- munificent 4y ago
  I agree with your take on this in general: It's better to be tactful and focus on beneficial outcomes rather than "being right". However, in this specific case, it sounds like: 1. Management was charging a client $60MM for a product they had promised. 2. They were convincingly told that they would be unable to deliver that product. 3. Their response was "Don't let the client find out." And then what ended up happening was they failed to deliver and still charged the client. That's a massive breach of ethics and potentially outright criminal fraud. Quitting and getting the fuck out of there is 100% the right call.
- kelnos 4y ago
  I think the question a senior-level IC needs to ask themselves is how much they care about stuff "above their pay grade" when this sort of thing happens. Personally, I don't have the patience to deal with super-dysfunctional management structures where they just want to ignore reality unless someone takes the time to Jedi-mind-trick them into doing the right thing. I would much rather give them the straight dope, and let them decide if they want to do the right or wrong thing. And if they want to do the wrong thing, that's just a very clear sign that's an organization I don't want to continue to be associated with. And yes, I mournfully agree that this is the state of many organizations and management teams. But life is too short for me to put up with their bullshit.
- spc476 4y ago
  I did what you would have done in my previous job [1]. A larger "enterprise" style company bought us out and was trying to force their Enterprise Agile unto us. I felt it was the wrong development style for the team I was one---for over ten years my team had always been on time, on budget, smooth deployments (four a year was a "busy" year for us [1]) and no show-stopping bugs in production. Once the new company took over, we were blowing our deadlines, disastrous deployments and major bugs in production were found. I raised my concerns up the chain of command, and got to a VP of the new parent company, who was looking into the situation until he was let go (or sacked, depending upon your point of view). All I wanted to do was go back to our previous style of development, which worked. But no, the parent company wants to do it their way. I left shortly thereafter. [1] Our customer was (well, technically still is if they're still a customer) a major cell phone carrier where a sprint for them is two years, not two weeks.
- Aeolun 4y ago
  > nor is it to say blatantly that a project is doomed. There’s usually a middle ground. If you are in a situation where you are presenting 12 man-months of missing work to management and they stick their head in the sand instead of asking ‘how can we accomplish this anyway’ then your project is doomed.
rebuilder 4y ago
The cynical view is that it was a management team who knew the conclusions were correct, but also knew the client was on the hook for years of development time and telling them the project was doomed would result in losing profits.

by svnt 4y ago

sillysaurusx 4y ago

For what it’s worth, I don’t think they could have done more. But the conclusion of the story is to heroically drive off a cliff, and say “it’s all I could do.” That’s where I disagree. If it were me, I would have privately (emphasis on private) worked my way up the chain of command, trying to alert more and more people that there was a serious problem brewing. The meeting in the story was obviously going to be a failure. So if you’re in a situation where you know that X is going to fail, doing something other than X is advisable. I would’ve tried to work with the deputized team to come up with a smaller plan that could be executed in, say, three months, and then figured out how to sell it to management in a way that three months isn’t a dealbreaker. Alternatively, I would have gone to management ahead of the meeting and let them know privately what they should expect to hear. That way they’re not completely surprised when you’re in Zoom, presenting a 12 month extension, and they have to say something. “It would be career limiting” is about the best thing they could say. You want to give them a better alternative. And giving management good alternatives is arguably the job of line engineers like us. We’re a part of a team; our job isn’t merely to do what we’re told, nor is it to say blatantly that a project is doomed. There’s usually a middle ground.

peteradio 4y ago
I don't understand how the deputized team drove off the cliff. At the very least they surfaced the set of problems which would need to be addressed to meet the contract.
- sillysaurusx 4y ago
  The end of the story is that they left the company. That’s a fine way to end the story, and maybe that doesn’t seem like defeat. But there tends to be better ways to handle it. Most people can’t afford to leave at a week’s notice, which is what I meant by driving off a cliff.
- jacobr1 4y ago
  The 12 month extension was going to get the managers who proposed it fired. So they couldn't actually propose it - thus the cliff. Instead they needed an alternative. Of course a better discussion would have been a frank reevaluation with the client, with several options and points of trade-off to consider. But really the best way - presuming everyone is working toward the same ends (NOT a given) - is to identify some kind of MVP/pilot that can been delivered and evaluated and iterated upon. That way you have _some_ kind of success to build upon with the client. This is failure of every badly run waterfall project. Even presuming the original design could be built on time ... how would it know it was actually useful? You also need the more limited success to rebuild trust - otherwise your new estimates will be questioned and looked upon with suspicion. If some tells me an 18 month project is going to take another 12 months, I need to assume the same incompetence really means that the new estimate is behind the curve as well ... not to mention changing requirements in the meantime continuing to push thing things out.
  - jrochkind1 4y ago
    > presuming everyone is working toward the same ends (NOT a given) I have realized that in many cases neither the decision-makers at the client nor the decision-makers at the consultant/vendor are working towards the ends of a succesful product. Their ends are their careers, and benefit to their careers may be pretty orthogonal to actual product success. Once when I was working at a place, I had a discussion: "I think if we use this vendor solution, it's likely to not work very well for our users. I think we have a better chance of meeting our users needs doing it in-house." "You could very well be right, but if we do it in-house and fail, it'll be our fault, everyone will blame us. Everyone is used to using the vendor for this, it's a decision nobody will blame us for, even if it fails. We're going with the vendor." In some cases, everyone can in fact have their goals aligned... their goals simply aren't product success.
BlargMcLarg 4y ago
Your solution to a dumpster fire is to play a very risky game of hero, navigating an environment where at any point you could step on someone's toes, in hopes of salvaging a project for which there is absolutely no guarantee you'll get credit, let alone a sizeable reward, while the market is rife with opportunities. For a bunch of capitalists, not some noble goal. Forgive me, but playing hero (really just martyr) sounds like the absolute least logical thing to do.
- WindyLakeReturn 4y ago
  I have to agree. When the risk is greater than the reward, you have to ask if the project is worth sacrificing for. I find the answer is generally no. Even noble projects are set into situations where it isn't worth the sacrifice. From a purely pragmatic view, you can do better for the world by skipping the sacrifice and finding a similar noble project to keep working at. It is a sort of prisoner's dilemma. Society is worse off because people tend to operate this way, not just in IT but all over. But we aren't going to fix society, so build a small kingdom in your life you can control and try to make things nice within it.
- jorgesborges 4y ago
  Not necessarily — the person you’re responding to said you can always ride it out if you don’t want to take on more responsibilities. That’s fair to me: look for solutions if it suits you, but otherwise stay silent and don’t introduce negativity (which is bad for you politically in addition to being bad for the project).
munificent 4y ago
I agree with your take on this in general: It's better to be tactful and focus on beneficial outcomes rather than "being right". However, in this specific case, it sounds like: 1. Management was charging a client $60MM for a product they had promised. 2. They were convincingly told that they would be unable to deliver that product. 3. Their response was "Don't let the client find out." And then what ended up happening was they failed to deliver and still charged the client. That's a massive breach of ethics and potentially outright criminal fraud. Quitting and getting the fuck out of there is 100% the right call.
kelnos 4y ago
I think the question a senior-level IC needs to ask themselves is how much they care about stuff "above their pay grade" when this sort of thing happens. Personally, I don't have the patience to deal with super-dysfunctional management structures where they just want to ignore reality unless someone takes the time to Jedi-mind-trick them into doing the right thing. I would much rather give them the straight dope, and let them decide if they want to do the right or wrong thing. And if they want to do the wrong thing, that's just a very clear sign that's an organization I don't want to continue to be associated with. And yes, I mournfully agree that this is the state of many organizations and management teams. But life is too short for me to put up with their bullshit.
spc476 4y ago
I did what you would have done in my previous job [1]. A larger "enterprise" style company bought us out and was trying to force their Enterprise Agile unto us. I felt it was the wrong development style for the team I was one---for over ten years my team had always been on time, on budget, smooth deployments (four a year was a "busy" year for us [1]) and no show-stopping bugs in production. Once the new company took over, we were blowing our deadlines, disastrous deployments and major bugs in production were found. I raised my concerns up the chain of command, and got to a VP of the new parent company, who was looking into the situation until he was let go (or sacked, depending upon your point of view). All I wanted to do was go back to our previous style of development, which worked. But no, the parent company wants to do it their way. I left shortly thereafter. [1] Our customer was (well, technically still is if they're still a customer) a major cell phone carrier where a sprint for them is two years, not two weeks.
Aeolun 4y ago
> nor is it to say blatantly that a project is doomed. There’s usually a middle ground. If you are in a situation where you are presenting 12 man-months of missing work to management and they stick their head in the sand instead of asking ‘how can we accomplish this anyway’ then your project is doomed.

rebuilder 4y ago

The cynical view is that it was a management team who knew the conclusions were correct, but also knew the client was on the hook for years of development time and telling them the project was doomed would result in losing profits.