I mean this story is cathartic, but I don't get what the "rabble rousers" expected to happen. You don't go into a meeting like that to present problems, but to present solutions. And a 12 month delay on a $60 million contract isn't a solution, it's another problem for the sales/client success people. And doing it in front of a group of management, no less - that's like firing a shot across the bow, declaring that the current PM team is incompetent.
It doesn't matter if you're right, it matters how you communicate and strategize. This seems to be a skill that many people lack. This sounds like a conversation that should be had with a handful of managers who you can convince to your side, and concoct a plan to stage the product development and release such that it gets done and you don't cost a giant contract (and people's jobs).
People talk shit about office politics, but sometimes you need to read the room...
> concoct a plan to stage the product development and release such that it gets done and you don't cost a giant contract
Yes, always showing up with a solution to problems that you've surfaced is a good idea and good for your career,
... BUT:
isn't coming up with a solution to this problem literally the job of the management team that they presented to? If management hears "the thing you think will happen will absolutely not happen" and then says "I wasn't handed an actionable plan by my subordinates so we'll just pretend I never heard all this", then they kind of suck. How well is an IC or lower level manager going to know what tradeoffs could be made without jeopardizing the contract or what kind of staging would be acceptable to the client?
If your boss is ok with riding a project off a cliff when you've warned them then it's not your fault. That's when you either hang out, don't stress, and wait for it to explode, or you go find a new job.
Suppose you were a junior engineer working with a senior engineer. They gave you a task, and you came to a similar conclusion: it was their job to do X, but they weren't doing it.
Would you simply tell them they're not doing their job, or would you ask questions, talk in private, and try to dig in tactfully?
When I was 22 or so, I did go around telling a certain senior engineer that they weren't doing their job. I still cringe at how headstrong I was back then. The people around me were trying to hint that things aren't quite as clear cut as it seems, but it took a swift kick in my backside to reboot my worldview.
You're right that the optimal strategy is not to stress about it, though. That would've saved me a lot of heartache.
My point is (and the point of many other commenters here) is that you can't really show up to a meeting and say "This project is doomed." That's arguably one of the core advantages of startups over bigcos -- you can pivot.
Your options are to climb the politics ladder, or ride it out and see what happens. It depends how much you care, or how much responsibility you want.
> The people around me were trying to hint that things aren't quite as clear cut as it seems, but it took a swift kick in my backside to reboot my worldview.
Was your rebooted worldview that you had been factually incorrect (i.e. the senior dev actually did do his work) or was it that you were factually correct, but hierarchy and office culture demanded that everyone pretend you weren't?
I wanted to touch on that: one of the things you learn is that it’s better to be liked than right. We devs often fixate on whether we’re right and the other person is wrong.
One specific incident comes to mind. I was working on Heroes of Newerth, a DotA clone. We achieved a bit of popularity in those days, and we reached around 50k concurrent users. So our servers tended to melt.
One day, the servers went south, and although games were being completed, none of the stats were being recorded. (Think of it like, the database was in read only mode.)
I remember it feeling a little surreal how they decided to handle it. They kept cool, looked into the problem, and got the servers back up within a couple hours. Then they went back to their usual jobs and didn’t seem bothered by the ticking time bomb.
I think in my usual 22yo fashion, I said that it was dumb that no one seemed to care that the servers were going down, and that we had to do better for the players.
What I should have done was ask questions. Should we try to figure out the root cause, and make sure this doesn’t happen again? Or was it really not a big deal?
A few hours’ downtime may or may not have been a big deal. We did end up suffering from some pretty serious server malfunctions which limited our ability to scale. But I certainly mishandled how to approach it, and won no friends.
Every team is dysfunctional in their own way. It’s important to adapt to the dysfunction and push things in a positive direction, not merely to be right.
If it makes you feel any better, I don't think technical issues were the reason HoN failed. For context, I have played a lot of DotA2 and HoN (5.2k hours in DotA2, probably 1k hours in HoN). This is anecdotal, but I was never really bothered by outages and neither were the other people that I played with.
Instead, I think HoN made some very bad decisions regarding cosmetics and fostered an extremely toxic playerbase. At least for me, those were the 2 main factors that drove me away to play DotA2 (even though I thought HoN's gameplay was superior).
Surprisingly, what killed the company was the lack of competitive scene. We sort of expected players to organize themselves. We also had a lot of the DotA pros at the time.
The moment icefrog and valve dropped their $1M tournament prize pool, the company in hindsight was doomed. But it took a couple years to sink.
Players follow pros, and if the pros are playing DotA, they’ll switch to DotA. Our only chance was to keep the pros. It would have been smart to make an exclusive contact with as many pros as possible. But of course, that’s with hindsight.
The rise of twitch happened to coincide with the rise of pro DotA, which I think was a factor in shifting popularity.
I think the difference comes down to a few things:
* the existence of behaviour score together with a functional report system, which I don't think was a thing in HoN. I'm at 10k behaviour score (max) and there are generally no game ruining griefers. Some people do trash talk sometimes, but nothing too obscene.
* HoN cosmetics actively encouraged players to BM one anther. e.g. the Dumpster Taunt https://www.youtube.com/watch?v=VC4j4U7K6mc If you die while taunted you have a dumpster thrown on you and the global announcer tells you to get "dumpstered". Taunting a player right when they die (which is a strongly negative emotional moment) is a great way to tilt them and, in turn, make them grief, com abuse or generally bm. That negatively affects the rest of the players and the cycle goes on.
* A bunch of players in the HoN pro scene had really bad manners, e.g. Moonmeander was notorious for his trash talking, taunting and general BM. He actually significantly toned it down when he moved over to DotA - unclear if that was because he grew up or because the DotA pro scene is a different environment. Regardless, the behaviour of pro players sets the tone for how the community at large behaves, and the DotA pro scene is much nicer. (incidentally, this is why I believe pro players should be held at much higher standards of manners than the rest of the player base. Stuff like saying glhf, gg and generally not acting dickish should be mandatory)
Broadly, maybe. At work, I don't care about being liked by people that can't admit they are wrong.
That doesn't being a dick to anyone I think is wrong. The whole point of telling someone that they're wrong is to correct course and fix things, and bullheaded, righteous, approaches never accomplish that.
But it does mean you don't keep quite. You don't give up. You ask questions, you try to learn. Because part of the process of saying that something is wrong is being willing to learn that maybe you are the wrong one.
I understand being unwilling to bulge to people that come in thinking they know better about everything. But I do not accept not even listening to someone that disagrees, that's a red flag,and I am out asap.
> Broadly, maybe. At work, I don't care about being liked by people that can't admit they are wrong.
Why do you presume all outcomes of your eggregious interactions is placing blame on others?
It seems you are totally oblivious to some of the most basic principles of working in a professional environment: if you antagonize and attack your team members, you are not trusted to help out and have their backs. This means you are not an asset but a liability. Working close to you is making them vulnerable to being stabbed in the back by you at the slightest issue. And that's why you are not liked, even if/when you are right.
All the people can be right, but that doesn't justify you insisting on pissing on everyone else's cereals.
Maybe I'm not expressing myself well enough, but I'm not sure why you jumped from "telling someone they are wrong" to "antagonize and attack". I feel like you can almost always do the first without incurring in the second.
I 100% agree that if you tell people they are wrong aggressively and arrogantly, that will backfire, and they are probably justified in ignoring your correction.
But some people, and particularly some organizations, seem incapable of accepting even the most thoughtful correction, and that's the kind of place/people I'd rather keep a distance.
Because part of the process of saying that something is wrong is being willing to learn that maybe you are the wrong one.
Ironically, you are wrong.
Not only are there better ways to let people know they're wrong when you're 100% right, but in your example you aren't even sure you're 100% right, yet telling others they're wrong.
Saying that something is wrong doesn't imply (at least for me) that you're 100% sure that it's wrong. I always consider colloquial affirmations to carry an implicit degree of confidence, which is rarely 100%, and I often try to make that explicit by phrasing it like "I think that ...", etc.
So, yeah, I don't see a conflict on thinking something is wrong, pointing it out, and arguing for change, and at the same time be open to be convinced that it wasn't, in fact, wrong.
I'm sorry, I genuinely do not understand your point. If I think something you say is incorrect, and I say "Hey, I think this is not right. Not 100% sure, but I think it isn't", you're saying that this is not "saying that something is wrong"? English is my second language, so, I might be missing some nuance.
English is my second language, so, I might be missing some nuance.
Indeed you are, but had I known English was your 2nd language it would have made more sense and I probably wouldn't have even corrected you since your English is very good.
You are conflating "ask questions before jumping to conclusions" with "ignore inconvenient truths that are politically/organizationally uncomfortable" and using the obvious merits of the former to defend what I would describe as a toxic culture.
This comment just brought me back to the League of Legends <=> Heroes of Newerth arguments. Complete with both games having server stability problems. (But obviously one is worse than the other!)
It is easy to be right. What is hard is being actually helpful, coming up with a viable solution (vs. an idea).
In the posted article there simply was no such solution. It was not viable. Unacceptable.
Yes, an outsider with fresh eyes might see things differently and without bias, but most certainly the experienced team knows damn right that you're right (to some degree), but also knows that it's just not that easy.
Throwing "We are doing this all wrong" around is often just short of saying: "I just came here and I immediately saw that you all are idiots, you should listen to me!".
I'm not saying that fresh input can't be helpful, outsiders might bring in new tricks and ways, but being humble is way more helpful than being loud.
In the article, the management team had already failed to do their jobs.
They had already failed to notice (or ignored) obvious problems, and the company clearly had a culture that discouraged raising or acknowledging such issues.
They also had failed to work with the client to establish a complete set of requirements - 9 months before the end of a multi-year project.
> It was not viable. Unacceptable.
The option that they suggested, letting the project slip, was a significantly more viable option than what they actually took.
Re-evaluating the requirements and coming up with a viable subset of deliverables would also have been a sane choice.
But since the company had no intention of letting the client know they were having trouble, sane solutions were banned from the table.
And it is cinsiderably harder to be actually helpful.
While everything you said is true, we and the author do not know what was previously discussed with the client. We don't know what was promised by either party, we don't know what the client messed up
Heck, I attended meetings with partners/clients that were simply impossible to get an output from, since the expectations in general were on completely different sides of the book.
But you air this out, realize that everyone agrees, most people resignate, and really helpful is this one guy, that offers to invest effort and time to work closely with a well chosen peer from the other side to get them on your side and finally work on the interesting things.
> "I just came here and I immediately saw that you all are idiots, you should listen to me!".
i may be a total outlier, but personally, i kinda like this type of person... regardless if they are wrong or right, it shows they have passion and really care (though i will admit this may be a naive point of view!)
There could be dozens of other reasons beyond just these two...
The single most common fault that I see is perspective. Individual sections have limited context or visibility of the whole picture to assess the importance of their section's dysfunction. This isn't necessarily a bad thing -- in a highly-fluid environment, it's often important for sections to achieve their own objectives without N^2 comms overhead (e.g. military command & control). Firefighting provides a useful analogy. One section's 4-alarm fire might actually be a 1-alarm or 2-alarm fire for the broader organization -- which means that other sections might get top exec billing.
For example: If this $60M contract was at Boeing during the last few years, it will rightfully be deemphasized while executives deal with the existential threat of 737 Max matters.
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?
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.
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.
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.
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.
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).
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.
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.
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.
> 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.
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.
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.
> 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.
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.
I was hired on as a full-stack developer to help a 2 person team (dev and designer) get a year-long project over the finish line. This was a November and the project was slated to go live on January 1. My first week was getting my PC configured, orientations, onboarding meetings with various external departments and perusing the project to get familiar.
Week 2 I was supposed to get assignments from the lead developer, but they were holding things close to their chest. I was given very, very menial things to do, or just told to continue to study the code. When we'd have project meetings and they'd ask how things were going overall, the lead developer would assure them we were on target - even in the face of ongoing bugs, missing features and incorrect functionality during QA testing. I'd offer the Lead my help, but they hadn't found the right task yet.
By the end of week 2, beginning of week 3, I was fairly confident the code I was researching was not lining up with the status reports in the project meetings. I started to speak up and ask questions to surface concerns in attempt to get something thrown my way. Again, the Lead Dev continued to assure management we were on target and that seemingly huge TODO items were trivial and would be handled in short order. I was kept on standby.
As things continued to progress in this direction, management finally bypassed the Lead and came directly to me to my feel for where were at. At this point I had only been with the company 3 to 4 weeks, but I had been a developer for 11 years. I told them in not so uncertain terms, "this project is doomed". The Lead dev is wildly overpromising deliverables, minimizing outstanding work and shielding the management team from truly understanding how behind he was. I honestly had no idea what his plan was to meet the deadline, but based on my estimates we were easily 4 to 6 months out. They were flabbergasted.
I continued to provide direct status reports at management's request. It felt like politics, but what else could I do? By the 2nd week in December, 6 weeks into my employment, the writing was on the wall. The project was canned, the Lead Dev was fired and I was wondering if I had still had a job myself as the only developer and no projects on the timeline.
By the end of the following year, I had been promoted to management overseeing a team of 3 and still developing myself. We rebuilt the project from scratch and implemented it exactly 1 year after its initial planned release.
I never wanted management and certainly never wanted to get anyone fired, but sometimes you have to put it all out there in black and white.
I'm baffled when people (the lead) behave this way. I'm not asking this sarcastically and you probably wouldn't know, but were they on some heavy sedatives or psych drugs?
I didn't get to know them well enough to really say. There were anecdotes from other employees (before I started) about him falling asleep at his desk (during work hours) on several occasions. I'd be lying if I said I hadn't done that a few times in my career, so certainly not a smoking gun. It's hard to explain, he just wasn't very excitable and had no sense of urgency. "It's fine, it's fine. No big deal. I'll do it."
I think the confusion is, if their job is to execute a $60M contract successfully, and you tell them that it’s going to require an extra 12 months, you’re almost literally telling them they aren’t doing their job. Because arguably they weren’t. Their job was to guide the project successfully, which they didn’t do.
In a situation like that, you can recover, but it requires tact. The end of this story was that they left the company. An alternate ending is that they may have been let go.
If they’re paying you to work on a doomed project, you have to work on it, or change it. And if you want to change it, political maneuvering is necessary.
Well, yeeeeees... If management, whose job it is to swallow their pride when given a nasty surprise like this, isn't up to the task. I'm sure that OP could, with great political skill and subtlety, have had a very decent shot at turning this thing around.
But what's their incentive? They're probably paid as a regular IC, and saving a double-digit million dollar fiasco like this from disaster is super annoying and unrewarding work! You're effectively doing the job of five managers and not even getting their salary -- let alone a percentage of the disaster you're averting! This kind of political-technical skill combination can probably be fruitfully applied in a place that properly rewards the contributor!
I very much agree that this thing could have been handled better, when seen externally. But I'm also pretty sure it wasn't in OP's personal interest to do so! That's a very stupid state of affairs, of course, but I guess that might be par for the course of a failed $60 million project.
This isn't really how big dollar consulting works. Everyone under estimates in order to be the lowest bid and win the deal. Once won then you slowly and gracefully tweak scope/budget to get something done without pissing off the customer too much. That's how the game is played.
Pointing out that you've underestimated by X is pointing out something everyone already knows. And advocating to blow up the estimate by X so early in the project is arguing to piss the customer off and possibly walk away from $60 million. That's why everyone patted them on the head and blew them off. Everyone else understood the game but it's a bit gauche for them to explicitly explain what's going on.
You just tell them it will take 12 months more. Your the development team. Let them rewrite contracts or lose business. You do not get a bonus for contracts sold or kept.
If necessary someone else will tell them they are not doing there job. Stick to your role.
I prefer to work for companies where this is the case. I get enough equity compensation that finding creative solution to deliver business value _is_ my job and thus am indirectly compensated with the success of the company (even if the overall success is still dependent on other areas of the company succeeding too).
I think what a lot of comments are missing is that they tried to raise this with management, and eventually management responded by asking them to conduct a review and deliver the results, which they did. Maybe they could have played it better but it doesn’t sound like it was their idea to do it this way.
It doesn't matter whose responsibility coming up with a solution is. If it isn't you but you have one and they don't, then go ahead and step on their toes -- be diplomatic and kind, but go ahead, because a) you'll be saving the firm's bacon, b) you'll be saving the customer's too, c) you'll be making your career.
In TFA's case I suspect there really was no solution short of sinking a pile more cash into the project, and that was probably not an option. Though, who besides TFA knows, TFA gave us too little detail to be able to tell.
Oh for sure if you have a solution then get it in front of a person who should care about it. But a lot of times they _don't_ care because they know they're going to be promoted or leave the company before the pound of flesh is due.
The problem described in TFA is that leadership was happy to ignore a problem rather than do anything. In that kind of culture you don't make your career by raising attention to issues (even with solutions, because remember, they don't really care), you get sidelined. In that kind of culture it's better to just compliment the emperor on his new duds.
I assume the leadership structure and culture just didn't lend itself well to handling crises discovered in the trenches. But also, the crisis in TFA seems like a complete failure to properly understand the problem and solution spaces from the get-go, and that can just be very difficult even on good organizations.
Your take is exactly what is wrong with the culture. An existential problem is not a problem because you didn't sell it correctly. You first need to "massage" the individuals to create some kind of coalition. A coalition willing to accept basic facts or responsibility.
If a CEO were to be a fly on the wall in this room and overhear it all, they ought to fire every single manager in the room. Quite obviously they are willing to bury important facts.
I'm well familiar with these "career limiting" types. I once was in a similar position, on an architectural board dropping a few truth bombs. One of the leaders of the many political kingdoms said to me in private: please know that I think that you're 100% right, but I can't commit to that in public or writing.
These people gladly tank a company for as long as they keep their hands clean.
Middle management games. If your company grows to the size as to have middle management, for god's sake split it up.
I think you're taking it in a different direction than I meant. It's not about massaging anyone. Information can only be acted on to effect change if it's delivered with the context to do so.
I've been in similar situations. The fallacy is thinking that "truth bombs" are an effective communication style. If you want to effect change you need to do some social engineering and politicking. Hate it all you want, but the human psyche isn't a technical problem to solve with data and figures. What you do is manage expectations and present ideas that let people walk out of the meeting feeling like there's some direction that can be taken without disaster. Otherwise you're Chicken Little.
Good management responds to bad situations by negotiating scope and translating delays into milestones that are achievable. Like the story makes ICs feel like heroes for dropping truth bombs and quitting before seeing anything change, then seeming to be proven correct is an example of that. In my opinion they failed at the task given to them, which was to analyze the state of the project and implicitly give management something to do about it.
And that was a lesson I learned early in my career, being tasked with analyzing the state of a project and assessing why it was shit. The mistake was concluding that it was shit, because someone got fired afterwards who could have actually done a good job. What I didn't do was deliver information in a context that could have translated into change. The same is true of the ICs in the story. This is bragging about failure.
I like your take and it resonates a lot with me. But companies splitting up to remove the need of middle management - has that ever happened to anyone? A more realistic advice is probably to get a different job once you see managers start playing their status games and climbing their career ladders while ignoring often uncomfortable facts.
Test what? There is a massive problem. The priority is to acknowledge and solve it, not to spend a huge amount of time shooting the messenger or managing feelings.
I think the irony here is that OP _did_ do that anyway, he basically says he spent a year informing more and more management and others that the project was not on track. He played the game for a year, eventually got approval to make this report, and still half the people on here are going "well he didn't play the game long enough".
At the rate things were going, by the time OP "carefully" worked his way up on tactfully convincing everyone that the project was not on track it would have been release day.
I just think middle management is a recipe for disaster. Their perceived high status means they aren't easily criticized or managed for rational output in a way normal workers are managed.
For some, middle management is a mere bus stop on the way to the top. So they play it hard. Elbow tactics. Other knows they end in middle management and forever try to sustain artificial kingdoms by any means necessary.
It is too distant from common workers and it's not the top either. It's the one place in the organization where the most vile and unproductive behavior goes unchecked.
Isn't this the ironic part of the post? The "middle managers" empowered the common workers who were ostensibly in the best position to identify and solve the problem. Yet those common workers seem to interpret their role as just messengers and not wholly owning the situation by also offering alternative solutions. It's not even clear to me that they identified the root problem so that it wouldn't happen elsewhere *
* yes, they said it was performing work that wasn't spec'd. But why were they doing it? Bad requirements management? Bad contract management? Something else?
Not specific, but I have some friends who are involved in highly successful private equity firms. I was talking to one of them about the work and he was saying that one of the primary strategies large firms use is buying existing large companies and firing all the middle management, because that’s the fastest way to create value after the acquisition.
This seems to be in the vein of PE acquiring companies and cutting cost to extract value - just a sensible more strategy of firing middle management haha.
But this reminded me of a podcast episode with some PE guys. The PE was able to enhance an acquisition by issuing ESOPs to all employees and educating the employees about the structure and value of the ESOPs - Inverse of firing folks.
No, but companies internally re-org all the time. And one of the big motivating factors is to re-align incentives so that internal responsibilities are split into discrete, measurable areas. It seems like re-org success has mixed results - often due to Goodhart's law problems.
Sometimes one side is right, and the other side is wrong, and it doesn't matter if they didn't "communicate and strategize" or "read the room".
Obviously this guy is probably writing about a Javascript photo-sharing app or something and it doesn't actually matter, but it's the same principle. The managers who went ahead here would have gone ahead with launching the shuttle for the same reason.
I think your comment actually supports the original comment. If what's at stake is a $60M javascript photo-sharing app, then you gotta decide how much you care to massage egos and play the game.
If you're literally putting human lives at risk and you think there's a real chance of death, what a petty thing to say, "Oh well they should've just listened! It's a high-stakes game!" Do be clear, this doesn't shift the responsibility but it just reinforces that if you want to just raise a stink—do it however you think best. If you want to communicate effectively, you must play by the laws of human ego. Plain and simple.
People always underestimate the allure of human ego and pride.
The original comment says "a 12 month delay isn't a solution, it's a problem."
But sometimes there is no solution other than recognizing that it will take longer.
Or at least not with the current team.
And yes, that means telling everyone involved up to and including the CEO if necessary. The only other "solution" was clearly to quit, which they did.
A $60M project with 200 people on it isn't going to be able to pivot to creating that photo-sharing app (or whatever) 12 months faster. It's unethical of the entire management team to not immediately go to the client and tell them that the project is seriously behind expectations, in fact, "career limiting move" or not.
This is why outsourcing gets such a bad name. It's frequently run by unethical scammers who are just there to milk money out of clients.
STEM people will naturally succeed at this task immediately, while an average person, like a koala unable to understand a leaf is food unless it's put on a tree, can only answer the logic problem if it's phrased in terms of social rules.
The STEM people's brains tended to develop in a way that intuitively understands logic in a more abstract way, better able to understand reality, not just monkey hierarchies.
So they will be averse to politics because it's boring, frustrating, disingenuous monkey shit flinging. But they're the most qualified, because they're more likely to put truth and fairness above tribal enrichment and games.
If engineers more often made the sacrifice to waste their brainpower dive into that swamp, we'd have colonized space and solved hunger etc. by now. But I can't blame them for not wanting to deal with it.
Aren't the images in that wikipedia link misleading?
In the original case, you have the following statement: If even, then red. You also have 4 cards, 3, 8, red brown. So two numbers that relate to the if side and two colors that relate to the then side.
In the second picture, you have the statement: If drinking alcohol, then >=21. You also have 4 chards. 16, 25, soda, beer. So two numbers that correlate to the then side and 2 drinks that correlate to the if side.
But the way they arrange and color code the cards makes people associate the drinks with the colors and the ages with the numbers, which is mixing up the if and then.
Granted, this isn't a problem in the text explanation, but could lead to further confusion by someone trying to create associations between drink alcohol status and color when it is really drink alcohol status and even/odd.
Unrelated to my the rest of my comment, I found that despite having what I would consider a very logical brain, I did have a much simpler time solving the drinking problem than the original one. I reach a satisfactory conclusion in each, but the drinking one felt more natural and intuitive while the original problem included a pause and double checking my logic. I would like to be tested on social rules that aren't part of my current social context to see if that played a roll in this specific instance (the article says there is evidence that the effect persists even when the rules aren't part of the existing culture, but that is a general trend and may not apply to specific instances).
I'd argue anyone who wants to be successful, in any arena, must rise to these occasions. I'd also argue they're less political and more empathetic opportunities. Most of us are really just 13 year olds emotionally, running around in 20+ year old bodies. All our insecurities and hurts are still there. The art of being able to address the mistake and the inner human who is just longing for love, simultaneously, without crippling either, is terrifyingly difficult.
Everyone should rise to the political occasion. Why is that the engineers should not rise? Politics is how we solve problems without resorting to fists.
I assume you're referring to Feynmann's remarks in the https://en.wikipedia.org/wiki/Rogers_Commission_Report. The issue there was that management advertised a safety factor of 1 in 10^5 failures while the engineers thought it was more like 10^2, so numbers were fudged across the board to look reasonable. It really was a communication issue in that there was not accurate information on the riskiest parts of the launch. I guess you could argue here they are dealing with fudged time estimates. OP, like Feynmann, did his own investigation and obtained presumably accurate information. The Rogers report resulted in a new "NASA Safety Office"; OP's investigation was the perfect opportunity to launch his own team but he blew it.
The managers tries to be nice and make the numbers look a bit better to make the next level of management happy. That is the main problem here, putting engineers who just give you the facts straight up without considering what their managers would feel about it in every part of the chain would solve the problem.
No, according to the Gervais principle engineers are losers who don't know how to run a company. An organization run by engineers would waste their time on unprofitable but technically interesting distractions. The closest economically viable structure is a sociopath plus a small amount of losers, i.e. a startup. But startups don't get $60M contracts until they've grown enough to acquire some middle management.
Crap like this is why people like those managers are able to get away with what they did.
The challenger blew up because the engineer in the room kept vetoing due to the cold temperatures and he was pressured to stop vetoing, which he did.
Feynmans point about the safety factor was a side-point about the general attitude that allowed them to feel safe to put politics in front of nature.
This is WHY he made his infamous quote.
> For a successful technology, reality must take precedence over public relations, for nature cannot be fooled
The safety factor is what they were claiming to the public and what they used to convince a teacher it was safe, but has absolutely nothing to do with why the challenger disaster happened.
In the article, risk was known. "It would be career limiting." The managers knew the risk was to themselves because they weren't offering up a solution.
The Challenger was different. There wasn't hard data that characterized the risk. That was the main problem; there was an absence of known risk because the operational parameters were outside the testing scope. It was more like "We don't know what the risk is, if there is one." That's a very different animal because you're dealing with uncertainty and low probability events. Those risks tend to show up in hindsight. (same with Columbia for that matter).
> There wasn't hard data that characterized the risk.
I commented on this the other day; there's a useful NPR article on the subject.
> The night before the launch, Ebeling and four other engineers at NASA contractor Morton Thiokol had tried to stop the launch. Their managers and NASA overruled them.
> That night, he told his wife, Darlene, "It's going to blow up."
I’m familiar with the story, and actually came across your comment a few days ago.
He didn’t feel right about it, but that’s not the same as hard data. They didn’t actually have data on the performance of the material at those temperatures, which is part of the big discussion with his managers. He essentially said, “we don’t know how it will act in those conditions.”
Granted, on a safety critical system, having no data should be a scenario very, very carefully considered as a harbinger of doubt, but having no data isn’t the same as having a concrete understanding of the risk. The problem with large, complex systems is you will always find someone who thinks management isn’t taking a certain risk seriously. I know aerospace engineers who squawk about the risk being too great, yet that’s a 5 sigma industry.
NASA reliability risk is usually quite rigorously defined. If he had hard data that said the risk was outside the acceptable envelope, it would have been relatively easy for the managers to stand behind him (especially when weather is driving that risk).
Columbia was similar. They had lots of data points that the foam shedding wasn’t a problem is different scenarios, but they didn’t have the same evidence about that specific scenario (the deltaV, flight profile, and where it struck).
> you don't go into a meeting like that to present problems, but to present solutions. And a 12 month delay on a $60 million contract isn't a solution, it's another problem
Honestly that's exactly what I'd expect out of a meeting like that, and with good leadership it'd be a collaborative exercise on how to solve the problem. There's not going to be a solution that has zero impact on anyone else, and that individual team doesn't have the authority to make the call on what impact the business can sustain. They came, presented their problem, and their ideal recommendation (a 12 month delay). There's plenty of options on how to deal with that: ask sales how much of a delay is actually tolerable, see if low-priority asks could be dropped to free up some additional time, etc etc.
It's leadership's job to mediate problems between "peer" groups, like engineering and sales.
My first role out of college was on a four person product team split across three projects on two OSes. We were overloaded and couldn't maintain the desired velocity that Management was asking for. So we scheduled a meeting with the VP of product development and the CEO (the joys of a midsize company), sat down, and shared the amount of effort in our backlog, the goals we'd committed to as a company for these projects, and the cost that context-switching. The CEO considered us for about 20 seconds, then said "Okay, which project should we drop?". She had the trust in her teams and her management to take them at their word about their inability to achieve the goals, understand it's because the goals were beyond the reasonable capability of the team and not because the team was underperforming, and understand the landscape of the choices available:
(1) continue underperforming on our existing goals and possibly upset customers due to not meeting stated expectations
(2) walk back our commitments, possibly upsetting customers
(3) cut the legacy product and focus on achieving and even exceeding our commitments for the modern product
(4) do nothing and shred team morale
More often than not "office politics" is really just shorthand for "low trust, low transparency environment". Yes, there's some amount of collaborative interpersonal skills necessary to be a good engineer, but if you don't trust me to do my job and tell you when our objectives are at risk then why did you hire me?
I smell a lot of captains of industry with stockholm syndrome in those takes.
They fetishize self-serving sociopathy -- which is frequently just compensation for deep incompetence.
The skill of reading a room in this particular case - is to realize the kind of place this is and go elsewhere before going through all that effort for it be disregarded by bruised egos, not do even more unnecessary work to bail out incompetent managers.
I have known very few managers who didn't routinely lie. The advantages of subtle (or not so subtle) manipulation are too tempting when trying to get something from someone.
As most comments seem to say, I think that what you say describes a very bad culture. Although said with many more words, your proposed culture is of secrecy and opacity, where decisions and actions are performed in private in a conniving fashion to avoid "backlash".
Any company that doesn't appreciate honesty/transparency/openness is certainly not one I would ever be a part of.
Most importantly, and it's worth mentioning again because other comments pointed this out, the culture you seem to be a proponent of was critically instrumental in major disasters like the Challenger disaster. When we can't talk about those "inconvenient truths", they get buried until they are forgotten and we are forced to learn about them again, sometimes in the most cruelest of ways.
Doesn't sound like that was the job of this little committee. As written, it was to review and particularly identify extra work. Presenting solutions to this kind of problem isn't explicitly and often implicitly the function of the developer(s), especially in a room full of managers. Whose job it is literally to identify solutions to this exact kind of problem.
Specifically, developers are in charge of tactical solutions, while management should be paying attention to strategy. Micromanagement is one of the many failure modes we talk about here, there, and everywhere. But having to do all of the strategy work because your bosses either can't be arsed to do so or can't find their way out of a wet paper bag, is another failure mode we talk about a lot.
Leadership should be leading, not being lead by the nose. But when they won't you do what you can. It's not right, but it's expedient and somewhat sanity saving. Though if you take it too far you find all new kinds of insanity.
The managers might not understand the exact nature of the work. They want to know how they can reduce the scope: for which they need information about which work is urgent, or necessary at all. The mission is "please identify and estimate all untracked work so we can blindly put all of it into the plan, no matter how it delays the project".
>You don't go into a meeting like that to present problems, but to present solutions...it doesn't matter if you're right, it matters how you communicate and strategize.
I agree, I think the author misread what their role was. It wasn't to "tell it to them straight" as much as it was to solve a problem. Acknowledging the issue is only the first step.
I once worked as an energy manager for a large financial institution. They had invested a lot of money into a complicated software system that promised to optimize all of their HVAC costs related to their data centers. The problem was the system didn't work well. At all. It used a complicated computational fluid dynamics model that took forever to build and any hiccup in the data would cause the system to start again from scratch. The engineers hated it so much they would just unplug it on the sly. It wasn't delivering on its promise to meet the sustainability goals as everyone thought it would.
I didn't feel comfortable wasting the company's money on this system, but they thought it was great. There were plenty of vice presidents and managers up the line who vouched for it and it would make them look bad to say the system didn't work. We had to figure out a way to break it to them while allowing them to save face.
So we went to work on their building automation system, reprogramming everything to be as efficient as possible. Part of the plan was to create an "experiment" where we had to remove the computational fluid dynamics model for a time. You know, so we gauge the true impact of our reprogramming efforts ;-) The effort worked wonders, exceeding their energy and sustainability goals set by the shareholders. We reframed it as "this worked so well that we think we can continue to meet sustainability targets without the computational fluid dynamics software contract."
They were thrilled. Not only did they meet the goals, they saved money by getting out of the contract. It turned a bitter pill into a sweet one.
Yes, I felt a duty to get them out of the contract that wasn't working. But getting them to accept that is a lot easier if you offer up a solution instead of just underscoring the problem.
By the same logic, canceling the project to focus on others is a success story. If the expectation is that employees are more than cogs in a machine and are expected to solve real problems, both the author and company have problems.
Washing your hands of a problem, especially when you’ve been empowered to create a solution, doesn’t solve anyone’s problems.
The article actually said they were empowered by management to act as the Architecture Board.
Had they come up with an actual workable solution, I seriously doubt it would be career limiting. In the context of the article, that statement was made about not fixing the problem but just saying it couldn't be done. Not finding a solution is what is career limiting.
Circling back to what you originally commented about on, i could have just told them the software they bet on was crap. I would be right, but it would have been “career limiting.” If you can actually focus your energy on a solution, maybe you won’t get the ego boost by showing everyone how right you are, but you can move the ball forward in a meaningful way.
I do think it's telling that the author viewed being given authority as a subversive act. That sounds much more like somebody who's interested in pointing fingers than taking responsibility to solve problems.
Do you think they would be blamed if they had actually come up with a solution?
The “message” was just stating a problem, not offering a solution. That’s the point.
They apparently thought they role was simply to uncover the problem, not figure out a way to solve it, despite being given the authority to do so. In general, people who just point to problems aren’t very well received in either business or personal life.
> we further suggested that there was probably work we had not discovered. Finally, *we made our primary recommendation*, which was to slip the project 12 months to cover the newly-discovered work, and provide margin for any additional remaining work.
Are you implying they offered more to solve the problem? Being generous and conceding maybe that was the case, why don’t you think that fixed anything?
Just asking for more time or more people isn’t really a solution. Maybe it can be part of the solution but it should rarely be the primary fix. They already said they had over 200 people on the team, so I would expect some pushback on saying they continually need more resources. It’s like asking for more inventory to cover up quality control issues. It only shows a superficial understanding of the problem.
An organization entrenched with managers like this is not salvageable. There's no "right" way to fix organizational rot this extensive from the bottom up. The organization has evolved into a parasite that exists only to suck assets out of other companies, and the management exist only to suck assets out of the company they purport to manage.
Don't waste your time playing political games and undermining incompetent management trying to "fix" massive organizational rot from the bottom up. Your reward is going to be negligible at best relative to your effort, and it's more likely you'll be punished instead. Go start your own company, or work for a small company where you can make a massive and positive difference - and get massively rewarded for it.
In this story, the report presented the situation cogently, and the higher ups decided it would be best not to tell the client, within the context of semi-ripoff system development.
He saw that the project was doomed because of absent management, he presented the facts to management, and he quit after it was clear that the previously oblivious management was going to carry on in denial. It sounds like he read the room perfectly.
> And doing it in front of a group of management, no less - that's like firing a shot across the bow, declaring that the current PM team is incompetent.
Always live below your means. Then you can walk out on people when they tell you who they really are. At least then you have a small chance that they will take the feedback for what it is, instead of learning to lie better.
If you quit mysteriously six months later there's no feedback loop, even if you tell them what it is (same human psychology theory behind CI - only immediate feedback is properly internalized)
I agree, however, the teams where people don't need to read the audience, and can just freely present problems whenever they want without fear of repercussions are the most productive, in my experience.
The management team must be "thick skinned" enough, though, to be able to take the blame and work on the problem. Maybe talk in private to the person about the tact.
Of course, I'm not going to try, just personal observation.
I've personally done this exact thing. If the project is underestimated, there isn't always a solution. I worked on a smaller project for an agency where I was the tech director. Meaning I had a direct line to clients and account managers at all times as well as authority over the execution. I raised flags when the contract was drafted that it was vague and optimistic, but it got signed anyway. I did a prioritization and forecasting exercise to keep scope in check and set milestones for client obligations that would roadblock us. We could see in real time how far off we were and I reminded everyone at every turn. The account team who sold the project were not involved in execution. I back-channeled to our CTO that they messed this up and we have no hope of delivering on budget. We ended blowing the budget by a mile, the ones that sold the project said the team didn't execute and I got let go. As far as I can tell, I did everything right and still lost. My biggest regret is that instead of insinuating the account team were at fault, I should have yelled it at them.
Better approach is to leave.
Talking to those kind of ppl is like playing chess with pigeon.
Just dont, have dignity. We are some of the smartest ppl this earth is supporting.
Absolutely nobody involved in this was stupid. In fact, the ones who signed the doomed contract were very savvy, just very self-serving. Part of the reason I got screwed was because I had excellent relationships with almost all the other account managers and they also all knew that successful deliveries lead to more sales and were brilliant at what they did. It's hubris to think that tech brains are always the smartest.
Bad news like this should probably be first communicated up to management privately, not sprung upon them in a meeting in front of their peers and reports.
I think you've missed the point. These people are pretty close to thieves. There isn't an amount of communication strategy that would have changed the unspoken willingness to take the client's money knowing they were lying to get it.
I wonder if we have conditioned clients to expect everything now. Are we harming our own customers by allowing them to make demands that in turn only harm themselves in the long run?
Do we have too much of a revolving door for an organization to see this trend?
"Are we harming our own customers by allowing them to make demands that in turn only harm themselves in the long run?"
It sounds paternalistic but yeah, that can happen. I've been in this sort of office politics situation where that was an issue.
The problem in that case was that the projects were quite long and touched many different people inside the customer companies, many of whom had differing agendas. In particular the customers were banks and their security people had a habit of demanding very specific changes that would clearly sink the entire project a couple of years down the line, and even contradict the original justifications for it.
Unfortunately the company I worked for at the time had a lot of difficulty with this concept. The upper management tended to abstract the political complexity inside these banks as "the customer wants X so why aren't we giving them X" where in reality there was no "the customer", just lots of people inside big orgs who weren't really talking to each other. The notion that "the customer" could be incoherent and we needed to manage that somehow just wasn't there at all, they just saw it as anti-social arguing. So it was in fact career limiting for me to point out these issues.
Pretty much. I have never seen a product manager/project manager see a multi year project through to the end.
I also suspect a lot of it comes down to it not being the problem of anyone until the end of the project. Sales can promise whatever they want. Tech can put it off for a while.
Yes. If you need more time ask for it and explain why it’s necessary and why the delay couldn’t have been anticipated. It’s better to be late than be late and also delivery a shoddy product.
Being transparent and communicating roadblocks early is just a good way to get through life. Nobody likes to hear something will take longer than expected, but what people really hate is non-communication that leads to unexpected delay, or even worse, poor work that's delivered late.
It seems like Agile would have been a great fit. Too many requirements, no real information - it's exactly the situation where throwing out prototypes and getting feedback can lead to a solution.
Here is where the outsourcing happening in this story comes back to bite, though. It's basically impossible to write a good contract for an Agile development process. (The only time I've seen it at all is in gov't work, where cost-plus is the default way to pay, and it doesn't often produce good software.)
If I'm the customer, why would I accept anything less than X for the amount of money I'm paying, and if I'm the developer, then Y is a perfectly good MVP, and since X >> Y, who determines when you are finished?
Contracts for non-Agile processes are pretty worthless too if the project happens like this. If I understand correctly, the client ended up swallowing the cost for being intentionally lied to.
In an Agile process, the client would be much more closely involved with the development, attend sprint reviews, ask questions, and be available for questions about whether to drop features or extend the deadline. The client can make an informed decision and sound the alarm when too much time is spent on things they don't need.
It can work, and it has to, because the vast majority of companies in the world simply cannot write their own software. The problem is big software companies that mostly exist to leech of those other companies' lack of understanding of software. Basically every company that outsources software still needs to have at least one person who understands software development and project management sufficiently to keep an eye on the development process and check that they're not being scammed.
I don't think hiring some certified Agile gurus and reshuffling all the teams in the middle of the project would have improved the chances of delivery.
It depends if you do certified Agile™ or apply some core agile principles. Getting something that works ASAP and then iterate is a huge win whenever possible. Losing steam on a project that hasn't met any useful milestone yet must be one of the main sources of waste in our industry. Granted, 15 months in might make it tough to correct course towards a shippable milestone. Definitely worth the exercise tough.
Agile is great for running execution teams and gives you real-time feedback on progress, but if you have a contract with fixed scope and timeline, you're just boxed in. Agile requires flexibility on time and/or scope and it's not amenable to a services contract unless you have a very trusting customer.
It's not clear how long the project lasted but it was at least 3.5 years. So the time-line couldn't have been that rigid; yes there was a Gantt chart but those are like horoscopes. And since the requirements kept coming in there was no fixed scope.
As far as the customer goes you can say something like "we'd like to deliver a prototype early" and then it sounds like you're exceeding the contract. You just have to get them to prioritize features while avoiding discussing the fact that it's impossible to deliver all the features they requested. Basically you treat the lists as a wishlist rather than a requirements list. Maybe you come clean later once they like the prototype.
I'm not saying it would have saved the project, I'm just saying it's better than giving up and saying "the project is doomed" like OP did. But maybe OP wasn't cut out for a leadership role.
I call these kinds of solutions “baby solutions” because they are impractical and assume the problem is that no one knows the “truth.” So they suggest impossible things to solve the problem.
Proposing an additional 2,400 person months and increasing the schedule 50% is not a viable solution. The PM probably said the kindest thing they could instead of “no shit Sherlock.”
A more useful solution would be to identify what could be cut to release something viable. Or to figure out why so much unplanned work was taking place and an idea on why to solve it.
It’s like recommending that step one is to built a time machine.
I had a similar reaction. It's pretty rare that you want someone to be surprised by what you have to say in a big meeting like that. Ideally, the goal of a large meeting like that is to say, "I've collected the data, we've had different workstreams look at the data, and having spoken to all of you, we've all agreed on X."
> People talk shit about office politics
Right... there are good ways to go about politics, and not-good ways. I think many of us see the not-good ways.
> I mean this story is cathartic, but I don't get what the "rabble rousers" expected to happen...
I think it depends what the rabble rousers actually wanted.
Did they really want to fix the problems, or did they want to give management one last opportunity to address the issues before deciding to move on to other opportunities?
The person telling the story seems to end it on what they precieve as a happy note. They quit and they felt good about quiting. Perhaps the outcome was a good outcome for them.
It's their fucking job to solve the problem, and it's professional malpractice to hear the news, acknowledge it's true, and then sweep it under the rug.
No, it's the little people's responsibility to convince the big people. If they can't do it and the big people suffer as a result, it's still the little people's fault.
> People talk shit about office politics, but sometimes you need to read the room...
In my limited experience, most people have a kinda low self awareness, especially in the lower end of the food chain, the higher I go in the chain, the less naive people I meet. Why was he even worrying about a badly planned project? If your job is to code, just do that unless you are getting pay to be worried about the planning, which would be even a higher salary and at most have a very low key conversation about the problems with the superior of your manager, so when he gets fire for performing badly you can have more odds of getting his job.
Keep the client informed of the progress. Springing a surprise like this on the client on the originally planned delivery date, without any warnings well in advance, should count as proof of poor project management and make the software company liable for a significant chunk of the costs. The client shouldn't have to swallow that cost if they were kept in the dark.
Totally agree, they went in presenting a problem and not a solution, to the wrong bunch of people.
Nobody wants to hear that, even if it's true, and even more so if it affects the company's bottom line.
There's two ways I see they might have worked around the issue. The fundamental problem with the project might not be workable, but firstly reaching out for a private chat with some of the participants would have shown the likely reaction in advance. Secondly, re-framing it as a solution space, might get more people to buy in.
if consultants were asked to do this, the solution might have looked something like "there are nine months worth of opportunities to optimally architect the project; these are the top ten problems we identified and the top three preventing us from shipping; here are the tradeoffs; which would you like us to work on?"
this could've been a resume generating event for a lot of people
that said, burn out and feeling unheard definitely sucks. that probably played a part in how the OP landed here
It doesn't matter if you're right, it matters how you communicate and strategize. This seems to be a skill that many people lack. This sounds like a conversation that should be had with a handful of managers who you can convince to your side, and concoct a plan to stage the product development and release such that it gets done and you don't cost a giant contract (and people's jobs).
People talk shit about office politics, but sometimes you need to read the room...