Story: “It would be career limiting..."
doomedprojects.com
doomedprojects.com
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...
Do we have too much of a revolving door for an organization to see this trend?
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.
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.
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.
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?
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.
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.
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.
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?
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.
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.
Telling a manager "we uncovered work that wasn't in the original spec" isn't literally the same thing as telling them they aren't doing their job.
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.
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.
I'd bet it doesnt requires tact to convince them anymore.
If necessary someone else will tell them they are not doing there job. Stick to your role.
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.
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?
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.
Most people can’t afford to leave at a week’s notice, which is what I meant by driving off a 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.
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.
Forgive me, but playing hero (really just martyr) sounds like the absolute least logical thing to do.
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.
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.
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.
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.
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.
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?
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.
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).
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.
> drove me away to play DotA2
How toxic is the HoN playerbase if DotA2 is an improvement? I don’t think I’ve ever not enjoyed my games as much as in DotA2.
* 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)
Thanks for the nostalgia hit!
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.
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.
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.
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.
Good luck with that :)
"Because part of the process of saying that something is wrong is being willing to learn that maybe you are the wrong one."
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.
Saying that something is wrong doesn't imply (at least for me) that you're 100% sure that it's wrong.
English is my second language, so, I might be missing some nuance.
Telling someone they are wrong, means you know for a fact that they are wrong.
It does not mean you think they may be wrong.
It is binary.
You do not tell someone they are wrong if they may in fact not be wrong.
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.
What a novice usually does not realize is:
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.
> "I just came here and I immediately saw that you all are idiots, you should listen to me!".
It's easier to be wrong.
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.
This is helpful. And it is hard.
That isn't the case, has never been the case and will never be the case.
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.
One of the many benefits of being having extremely employee friendly laws is that you can absolutely do this.
It still doesn’t really help, but it’s not ‘career limiting’ either.
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.
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.
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.
Hiring 200 more people would just make it 2 or 3 years late, not just 1 year late.
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.
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.
exactly
If Engineers don't like Managers-with-no-Engineering-background, then Engineers should try to fill the Manager role from their own ranks.
Otherwise, what else do you expect will happen? Like a lot of things, you won't win if you are not in the race.
Having said that, having an Ex-Engineer as a manager doesn't guarantee anything. You need the right ExEngineer - a person who can manage!
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.
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 knew I was different, but I didn't think I was that different...
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.
Deliver nicer and more palatable results and you could have had your own team!
Jeez, reading the comments here makes a lot of the dysfunction I've observed in industry make sense.
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).
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."
https://news.ycombinator.com/item?id=33488205
https://www.npr.org/sections/thetwo-way/2016/01/28/464744781...
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).
> 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.
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.
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.
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?
Hard agree with this approach! Why surprise and upset people enmasse when you can talk to individuals more privately and test the waters beforehand.
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'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.
Should have just arrived at the handoff with a half finished project and a new job offer, leaving the business types with the mess.
Many of us 'less socially aware' (or perhaps 'neuro diverse') people would like this waste to disappear.
If I suck at coding, you have no issue letting me go.
If you suck at management, then I have no issue letting you go.
Symmetry is beautiful.
Sometimes that's just victim blaming.
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.
Don't you know how power works?
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
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.
As it turns out, they were wrong.
The project management was actually fraudulent.
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, 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.
While the author moved on and had more success.
Who exactly had the problem?
Washing your hands of a problem, especially when you’ve been empowered to create a solution, doesn’t solve anyone’s problems.
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.
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.
note the usage of the word primary there.
stupid messengers.
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.
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.
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.
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.
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.
You cannot solve a problem that you haven't acknowledged.
In other words, do management's job for them. Only, do it vastly better than them, despite having no experience.
> 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 also take responsibility for the issues management created for other departments?
Why do we have managers then? It's not to manage well, and it's not to take responsibility.
It's not an individual employees responsibility to get the company to make good decisions.
I had a similar feeling about a project once. I thought "Boy is this stupid. No one in their right mind is going to pay for this. Why are we building this." Let me manager know my feelings. Stayed and built it.
Thing is a huge success. One of our best selling products. Boy do I still feel dumb. Very humbling, honestly. Shows what little I actually know about what people want.
That doesn't sound like it's your fault!
It's really strange the first time you experience it.
But you can't go wrong with talking to users to understand the problems they are dealing with
https://www.amazon.com/Mom-Test-customers-business-everyone/...
The whole book is basically how to get useful information by being curious about the potential customer, how to decode “That’s great” by asking for commitments/intros/money, and also a bit about how to know whether you’re talking to the right person in the first place.
Sometimes you just don’t see it, and that’s ok. Not everything is “I would have succeeded if only…”
A year later the entire project was wound down. It had never shipped past an extremely limited beta. It completely failed to generate any sort of traction or product market fit. The manager who brushed off my concerns left the team way before this and went to work on something else in the organization.
I was a new security champion for a team. The product had schema owner SQL injection vulnerabilities on every page we developed. I had a meeting with the department head and explained the whole situation and two remediation options. He chose the third option - do nothing. According to him we have a realtime DB backup. Has it ever been tested? No. Do you have procedures for it? No. How long will it take (15 minutes is the end of the world for this system to be down)? No idea.
I walked out with a clear answer in my head and that free feeling. I left for another team. Not my problem.
It's a great compliment for your peers to call you a senior or tech lead, but it only opens the door to the great insult of your managers keeping you from the actual roles.
Preaching to the choir, but that's simple black and white thinking. Once an attacker has gotten in, it's better if at least there's less damage they can do. The more damage an insider could do, the more damage an outsider who social engineers some credentials can do.
> And then one of them said “It would be career limiting if the client were to hear this.”
> I’d met my responsibility to the company – and the company had threatened me as a result.
The author interprets that they were threatened. But really, for whom would it be career limiting? Perhaps I'm being too charitable, but the manager could also be read to be making a statement of fact about the perception of their own performance. The author says there's already a project plan and a project manager, and the plan is clearly incomplete and the project manager was not aware for an extended period. Someone's career probably _should_ be limited.
But the larger question is, did any of this matter? If the customer is not engaged enough to make clear what they want, is there perhaps an equal amount of dysfunction on the customer side? If they really wanted something delivered, wouldn't they be trying to deliver clear requirements as soon as possible? Or perhaps someone on the customer side is able to get promoted off of being the point person for a 2 year $60M contract before it finishes? Or someone is able to use the slowness and expense of the contracting firm to argue for building an in-house development team?
Tbh, I sometimes wonder if it is a question of engagement. I just finished a project. Major clusterfuck. And it is a part of a much bigger overhaul. Tons of people are involved and there is maybe one person hidden somewhere that understands how it all fits together ( but my real fear is that the project is so big that no one really knows what this monstrosity is supposed to do, how it is supposed to behave or even how it actually behaves ).
People are engaged ( the ones doing the work anyway ), but there is just too many cooks and too many layers to information to be translated from English to English and from English to w/e contractors are from.
<<Someone's career probably _should_ be limited.
Probably, but based on my experience, there is near zero accountability in manager's circle. It is usually the sacrificial scape goat that gets all the blame and limited career opportunities.
In the two examples I'm thinking of, it's been that the client stakeholder has a lot of pull, but not a lot of experience. For example, the top Sales guy decides they want to run a little tech startup inside the company, but they've never actually launched software before. Or, someone in a load bearing role, like the head of product, knows they are out the door (usually moving up in a different, more glamorous organization) and doesn't really care to devote 60 hours a week to this dumb old company anymore.
If it doesn't feel like you're making a threat - it may feel to you like you're genuinely giving advice - then you have not really understood what it means to be a manager and what sort of power you have over your reports. Try to think of things from their perspective and imagine this coming from your boss.
Now, it takes a lot of company culture work to make it safe to actually deliver that, but you have to choose: do you want to have some awkward meetings, or some awkward subpoenas?
If you show up and are like "hey idiots, you fucked up the estimate, man you're dumb" then, sure, people will react negatively. If you show up and say "you were right that we needed to look into this more; we found 9 months of work we hadn't incorporated into the plan" then they're going to have a lot of work to do, but they probably aren't going to be unhappy about being in a position of higher certainty.
To some extent, it's not really different from what engineers do. Are you mad when there's a production outage? No. You just debug it and mitigate it. Project planning is no different; new facts are on the table, and the plan has to change. Changing the plan is a lot of work, and that's why project management is a dedicated profession. They can now go do their job better with the data that you collected. No reason to be mad.
It doesn’t matter if it was intended as a threat because if it wasn’t, it was still an appallingly judged comment.
I'm now realized that I've been soft threatened quite a lot.
For reference: https://youtube.com/channel/UCCtfpN-3GkF7HKvj5qs2EPQ ("toodaloo advice girl" Lou Whaley, who makes videos about office politics and setting boundaries with your manager.)
For the first little bit of my career, my coworkers and I would often joke about how the mistake one of us had made was going to get us fired. One day, I made a similar joke to another developer and was met with a look of sheer terror. Later that day, he pulled me into a room and asked me if I was serious. After doing my best to calm him down and assure him I didn't even have that type of authority, I came to realize that he viewed me as a manager even though I was technically at the same level in the org chart as he was (something that would be changed a few months later).
So that was the last time I ever made a joke about someone's job security and it made me realize that absent-minded statements from someone in a position of power are absolutely taken by others as things to be concerned about. I've been much more guarded with what I say to team members since that interaction, even those who aren't under me. It's not worth stressing your team over.
But agreed - as read, my initial interpretation was not even remotely as one of the threat. Perhaps advice, or conclusion, or discussion. It depends hugely what else was said though - I doubt it was truly "and that was the end of that" in the sense that those words were the only ones spoken at that meeting, or outside of that meeting.
[0] https://en.wikipedia.org/wiki/Will_no_one_rid_me_of_this_tur...
That said, the context of the article, calling somebody out in a public setting based on a large amount of work that they just presented on, is very much the opposite of that hypothetical context.
The people who actually intended to make good on it, they were always circumspect and left room for reasonable doubt. Largely, I expect, to make the process easier on themselves; to create sufficient dissonance that they could think of it as giving advice. But of course the advice was, "if you do X, it will be bad for you, because I will respond with Y."
1. A client didn't know what they wanted, had 60 million to spend on figuring it out, and hired a firm that would let them spend 60 million.
2. The firm was incentivized to provide a nice looking underestimate and then adapt as new work was discovered.
3. The firm continued getting paid as long as the client was happy.
4. The client did not want to be told that the project was a year late in advance.
One unfortunate aspect of the customer is always right is that the customer may often be very wrong.
At the same time I’d say this bigger picture is directly contributing to the secrecy and dishonesty within the firm.
Not only the client is not aware what they actually want and are getting; it looks like the firm is not fully aware what they’re delivering either.
I guess dealing with clients who are wrong may be a risky business.
There are real humans in the loop here. They can easily put their foot down and find another job if they get fired. These are not people at the edge of feeding their families. These are people that buy 94 octane gas at the Sunoco fuel pump for their stupid sports car.
If people don't make moral decisions in their day to day lives the world gets worse. It may not seem like the millions of dollars belong to anyone but they do. Pensioners or millionaires or even just normal folks that grasp their tiny share of the pool via their ESOP.
When people just throw resources and good will under the bus in the name of career advancement they're visibly hurting the world. Each single dollar could have been spent on refugees, climate change, or war relief.
I am very sick of this cavalier attitude by the tech elite.
I guess in the end it’s about balance, i.e. being selfish won’t kill us as long as it’s not the only thing we (humans) do. But yeah, we have to keep that in mind. Or ants will be the only thing left.
[1]: https://misfitanimals.com/ants/how-many-ants-are-there-in-th...
In other words, "the customer is always right" leads to absurdity even if interpreted generously, so maybe it's actually a bad principle.
Anyway, your optimistic view of the project in OP still does not describe an efficient use of 60M. Lots of us find that morally repugnant, and are not convinced to accept it by interpretations like the one you put forward. When people want to good work instead of bad work, we would prefer that be rewarded, not punished as it was in OP's story.
Of course that's the kind of behaviour that should be career-limiting, but clearly the industry has more than enough room for leeches like that. Because this is hardly the first time I've heard of a story like this; some companies really seem to exist primarily to live off these sort of projects.
For me virtually everything else in life has been more important, and careers/jobs were just a necessary evil because it's almost impossible to survive without money.
Given the necessity of work, I would rather enjoy my work and excel at it than sluff off.
True, but from my perspective the career oriented people don't actually care about that stuff or solving problems. In my mind, the people I would label as career oriented are usually pretentious assholes preoccupied by the "status" of someday being in the C suite and driving the most expensive BMW/Tesla.
On the other side, you can have fun, perform well, and solve problems yet have a stagnant career. You would have to play the politics to leverage those into career advancement.
One does not exclude another.
> Once you have a family, debt, obligations it does matter. Health care too.
Health care is obviously the elephant in the room. But generally, you'll find that people like this have structured their life in a way that allows them to have this attitude toward their career.
We in the tech industry are particularly blessed in our ability to do this. (perhaps less so in the Bay Area)
I don’t think this is incompatible with caring about your career.
My perspective is that I am very fortunate to have a job as a software developer, and that someday my luck may run out (bad economy, unexpected expenses, decreased demand for my skills, etc). My goal isn’t to be rich and live in luxury, my goal is to insulate myself from bad luck.
So at least for now, I would like to “advance my career” (especially since I’m in an entry-level role), just to give myself a bit of extra security.
But make no mistake my family and I come first. If a doomed project is not my fault and I can’t fix it…. I’m still taking that paycheck and finishing tasks….
I can tell you that many of them also see work as a necessary evil they need to do what they really want.
To weeks into the new gig, I looked at my boss and expressed to him that it was a failed project and it needed to be canned. I got the "are you kidding me, we've already got millions tied up in this project."
Fast forward, 2 years went by and it's still not production ready. I was then asked to take over the project to help save it. I politely declined, knowing my limitations, to which I got the "this is limiting your career" speech.
Another year went by (7 years into the project) to which the contractor said they needed yet another year.
After hearing that news, I took on a skunkworks project that basically reimplemented the core of the project. After I demoed it, the contractor was canned a month later. 9 months later, the fresh project went to production for the phase 1 release.
a) Got cancelled shortly before launching
b) Took several people several months to complete (amounting to a number of people-years)
and most importantly
c) Would not have started if someone had asked the right questions early on
I believe as engineers we can achieve big impact by preventing doomed projects from lifting off. That being said, it requires a certain support and company culture that aren't available everywhere.
Sounds like that might be half the problem: the firm with the contract had tens of millions of reasons (dollars) not to do honest product/project management.
(The other half is that product/project management is hard.)
If the client, which isn't it of the ordinary, then it shows exactly why it is career limiting to tell such truths to customers: company got paid regardless of project success.
Actual short term success for a services company is not defined in terms of the achievement of any particular outcome for the customer, but in terms of amounts billed and paid. As a result, it is a career boosting strategy for managers in short-term minded organizations to underestimate work scope so that a bid can be made for less money / less time than competition. Then, once the contract is signed and work has begun, "realize" that it's going to take longer and ask the customer for more time/more money. The customer may not have a great choice at that point, given they're already halfway down some path, and especially if their requirements were vague enough going in that this can all be characterized as new scope.
This dynamic isn't necessarily explicit or malicious. If people get promoted on the basis of contract wins (as opposed to on time, on budget delivery), for example, the incentives naturally reward overoptimistic managers.
I don't have a ton of experience here but whatever experience I do have tells me this is widespread in the computer services industry, as it is notoriously widespread in construction. The parallels with construction indicate this may be a structural feature of markets with information asymmetry...
It's not unlikely to think that management already knew what you found out before your report. they just used stalling tactics.
In the end you did the right thing to leave the project. These projects are commonly referred to as "death march projects" [Yourdon, Edward] and you should learn to identify them before joining.
I learned about CLMs early in my career: career limiting moves. It is something you need to avoid. Pick you battles and try to avoid imploding of frustration when things are becoming really bad. Just make sure you CYA and do basic stakeholder management to protect your reputation and skillset.
When you are in kindergarten, there are kids who build forts, and kids who play musical chairs. The skills for each are mutually exclusive, where one requires co-operation, creativity, and shared vision, and the other requires an understanding of the dynamic between power and limited resources. If you mess with the fort building kid, you're probably going to get called dumb and shoved, and if you mess with the musical chairs playing kid, they will find a way to make sure you get cooties or find an authority to tell on you to. Nothing much really changes.
Engineers build forts, middle managers play musical chairs, and if you show them them they are being dumb, they will edge you out in some variation of a purity game, because on a deep level they don't need a fort, they just need a chair when the music slows down, and for someone else to get cooties first. An enterprise project is either a zero sum credit and status game or an attrition game. In most large orgs, it's the latter. You don't win attrition games, you survive them, which means understanding when the music is slowing down, and keeping track of who is most likly to flame out and rage quit or get cooties, because if you can't see who it is, it's you. Personally, I like solving problems and unblocking engineers so they can build amazing forts, but you can't do that if you don't have a seat when the music stops, so you learn to balance the skills without antagonizing people who are over invested in one technique or the other.
It's amazing when you can just make stuff people want and get paid for it, but as soon as you do that, there's going to be someone else there showing up to find it, inventing something to be unhappy about or promising it to someone else to extract more value from it for themselves, and you get drawn into the same games again. Being smart about it is recognizing the cycle for what it is and setting personal boundaries that allow you to navigate without becoming a target.
It's happened several times. It's happening right now in my team, in fact. It's so off the rails I don't have time to interview for a new job.
Also law 23 from https://spacecraft.ssl.umd.edu/akins_laws.html seems appropriate: The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.
Looking back at the places I've worked, I'm having a hard time thinking of any examples of people committing singular "career limiting moves". Most tech companies I've worked for have been extremely forgiving of anyone with tech talent, to the point that some people were given countless extra chances despite longstanding patterns of misbehavior or failure to deliver.
The only true incidents I can think of that fit the "career limiting move" description either resulted in getting fired, or doing unnecessarily vindictive/petty things when disagreeing with management.
Not good results how? They got their $60M and moved on to the next sucker.
CLM = "career limiting move"
My original plan was to stay 3 years at my first company, and then change jobs for a raise. I ended up staying 5 because they gave me great raises for the first 3... And then screwed me on 2 years, at which point I knew I should have left at 3 after all.
After that it gets murkier, but in general if you aren't seeing really nice pay raises every 3 years, you can get it by changing companies.
What a lot of young developers don't get is that you can't just solve every problem with deep analysis. Nobody gives a shit if you can find all the gaps in requirements because a day after you finish your analysis the requirements will change.
There's requirements you need to define early. Who is using the system, expected availability, the different levels of access and the entities involved. Performance requirements, data security/tenancy requirements and some idea of how many users will be using the system concurrently are extremely important to understand up front.
There are a ton of companies, particularly the ones that build custom software for public/private sector that are incredibly happy to have customers submit junk requirements and nickel and dime them on every single change request.
> Web server is returning an unknown error (Error code 520)
--
Story: “It would be career limiting..." Harry E. 2022-11-04
I spent about 18 months working on a doomed project. For a lot of that time, I thought I was the only one who realized it was doomed.
It was a big, multi-year project. I was hired on as an individual contributor maybe 15 months before the project was to be delivered to the customer, and it took me awhile to get my bearings. But after a few months, it really seemed to me that (a) we were not moving along as fast as the project manager Gantt charts said we had to, (b) we were doing a lot of tasks that weren’t even on the Gantt charts, and (c) we hadn’t even received all of the specifications from the customer that we would need to complete the project. Bad estimates for the work we had, lots of work that hadn’t been estimated, and incomplete requirements – the project sure seemed doomed to me.
Over time, I made more and more noise about this to an ever-growing number of people. A couple of other folks felt the same way and also made noise.
About a year into my employment, management got tired of the noise, so they tried, as far as I can tell, to subvert us by giving us responsibility: they said OK, you trio of rabble-rousers are now an Architecture Board. You’re in charge of doing a technical review of the architecture, and in particular identifying work that’s missing from the official project plans. Report back in a few weeks.
Nominally empowered, we set out to do just that. We pieced together what we knew about the architecture and the work plan from our individual roles in the rapidly-growing, nearly-200 person project, and then went and asked a lot of people a lot of questions. When we were done, we scheduled a meeting to deliver our final report. At the meeting were the overall program manager, three project managers, ten development managers, and a handful of other managers as well. It was to this crowd that we presented our results.
What we told them was this: we had discovered a lot of work that wasn’t on the official project Gantt chart. A lot of work. In fact, we had discovered about an extra 9 months of work. Not, to be clear, 9 person months – we had found 9 calendar months of work for the 200+ person project. And that was assuming the client got us the rest of the specs in a timely manner and they didn’t contain any landmines.
Once we had let that sink in with the managers, 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.
It felt great to deliver this report. Finally, we would all be aligned on the doomedness of the current project plan. Finally we would adjust our delivery schedule to match reality. That gnawing sense of futility and impending failure that I’d been feeling for 15 months would finally, today, get addressed. Well, that’s what I thought.
The managers absorbed our report in silence for a moment or two. And then one of them said “It would be career limiting if the client were to hear this.” And that was the end of that.
When the shock wore off, I felt freed. The doomed nature of the project didn’t trouble me anymore. I’d met my responsibility to the company – and the company had threatened me as a result.
I quit a few weeks later.
Two years later, the client canceled the two-years-late project before it ever launched. They ate a $60M loss.
Bet that manager’s still at the company, though.
edit 2: it's back online and I just re-archived the page in case it goes down again: https://archive.ph/vrgsQ
--
yes and both archive.org and archive.is have archived an empty version of the page unfortunately[1][2]... it seems that as of right now (9th Nov 6:26am AEDT) there is no way to read the article. Hopefully it will be back online.
[1] https://web.archive.org/web/20221108183338/https://doomedpro...
They brought in a "Yes Man" who came in with the lowball estimate that management wanted and figured they could bring the cost down further by stealing people's time from other people's projects.
The project broke the $100M budget that was floated by the initial project manager and they only completed 1 out of 5 modules. Of course other IT projects across that university were screwed up and damage was done to the careers of many innocent people.
The good news is that based on that screw-up and several others around the same time that Uni greatly improved its management practices.
The truth is that, you are better off throwing all your process away and just use the pre-built stuff from the ERP system and adjust it as you go along. But very few companies have the courage to accept that their process were fucked up in the first place.
I had my own personal Peoplesoft story which was that they cut n' pasted a Javascript random number generator I wrote into their home page before Javascript had a built in RNG and so my email was embedded in a comment in their page. It's one reason why my email got spammed so much in the 1990s (later on I found out my email was the most spammed at my Uni).
Another amusing story is that David Duffield, founder of Peoplesoft, got pushed out of Peoplesoft when Oracle took it over and he founded Workday which turned out to be much more successful for higher ed institutions.
I'm also looking at the number of projects that I have built that got nowhere, so I'm also part of the problem. And with these projects, I tend to shrug off and say "well, that was a good experience".
But a "good experience" at $60M price-tag doesn't sound right.
I proposed solutions, and the lead engineers rejected my ideas. My manager gave me a horrible performance review filled with lies. I went to HR and then all of my coworkers stepped up on the record and said what was written was wrong. He was forced to rewrite my entire performance review. I changed teams shortly after this and the project was canned 6 months later.
Everyone who was wrong "failed upwards" which is usually how things go in Silicon Valley and everywhere else unfortunately.
Fuck you. Pay me.
(I was going to add a whole bunch of pithy wisdom after this, but I think this is always a good stopping point because nothing good for anyone comes from being grossly underpaid. What did you think would happen?)
You could say that the customer got exactly what they paid for. The customer lacked the ability pay in terms of specifications, so what they got was what $60M and a half-hearted attempt to articulate what they needed could buy.
On the other hand, the customer never knows what they want. You could say that's the job of the software company - to slog through the mountain of feature requests disguised as specifications to arrive at a system that will actually solve the customer's real problem.
That's the role of a business analyst, product owner, customer liaison, sales engineer, or some similar role for sure. If you're running a large project without one of those as a dedicated full-time resource then it falls on the project manager. If the PM can't do that, they should delegate to some role like those, possibly a few of them for various vertical slices of the project.
> I was hired on as an individual contributor maybe 15 months before the project was to be delivered to the customer
I can't imagine trying to deliver a project of this size all at once and so far into the future. I also find it hard to believe that individual parts couldn't be reprioritized to ship first, rather than the all-or-nothing take of "we need 9 more months".
You have two choices here - keep your head down and collect your paycheck until the client cancels the project, or go out in a blaze of glory. The second choice is the right choice in our industry, where anyone with even middling skill can get a new job in a week.
I can imagine. I don't know about you, but I met a lot of managers throughout my career that were masters in saving their own asses. They could not keep their P/L up to date. They didn't have time for that, as they were working 24x7 to avoid the hot potato. Amazing! Pure art! Art of avoidance!
We kept missing deadline after deadline, and it was starting to become apparent, even to the board. The board sent the most technical board member to talk to us to see if the team and architecture were plausible, the founder unilaterally fired the VP, and hired the guy he wanted all along. Things turned around instantly, once the new VP focused on the right things. Five years later, company was sold and now, nine years later, the product still exists at the acquiring company.
You cared too much, bet you wont do that again
Let the building burn down. Let the fires burn. By the time the fire reaches where I sit, I’ll be gone.
As the OP said, he was absolved. He (she?) couldn't stand the idea of incompetence or lack of communication/recognition of the fire in the room. Once the boss said "let it burn", their sanity was confirmed and they left the room.
I think my personal favorite was someone - seriously - saying to a Sales guy that he shouldn't espouse his opinion that he didn't like Bourbon anywhere near the CEO, as that would be "career limiting". WHAT!
They should have tried to identify wasteful work that could be trimmed so as to deliver something to the customer.
The managers were probably thinking, what, there is unplanned, untracked make-work going on in the project, and these guys just want it to be added to the schedule, and even look for more?
> I’d met my responsibility to the company – and the company had threatened me as a result.
That is not clear. The manager could have just been expressing the fact that if the confidential, internal problems from the meeting were to leak out to the customer, the customer might walk away. He could have been referring to his own career, or careers in general.
However, if that manager was insinuating that unless staff are reminded not to, like a bunch of children, they are going to go to customers, or the public, and squawk about problems discussed in an internal meeting, then that was actually quite insulting, and betraying mistrust.
Of course it will be career limiting to blab confidential info and lose customers, even under the best of circumstances.
Doing that is being stupidly honest, because maybe solutions can be found to deliver, and save the deal; if you blab to the customers, then you could be flushing away the opportunity.
To me that smells of incompetence on both the customer and local company. At that point the project might be entirely unsalvageable.
My guess is a longer game was going on that OP never found out about.
Sounds like this guy just needed to feel heard. Therapy might have been easier but what do I know.
(FWIW, my 2 cents - ERP project can succeed or fail on many key levers, including the approach (are we taking it as the business-transformation project that it is, or trying to treat it as a simple IT project); having a suitable client champion and involved/engaged/competent client team; clear goals, priorities and business requirements; explicit responsibilities and deliverables; and of course the competence & experience of the implementation/system integrator - not just on the development side, but on the functional, business transformation, project management, and most important client relationship management side.)
Funny enough, they're about 2 years behind schedule.
At least they took my advice about modernizing...
This has to be a project for the government
Your job is to write code, not directly challenge senior management.
This is unfortunately typical case for smb (small business), but for hundreds devs (definitely, large business), this is something extremely anomaly.
Looks like it is grown from small project, with small business level management not changed to appropriate when where need.
But such projects are also opportunity for smart brave persons, who could make great career grow.
1. It is management's job to find the solution. No.. it is the management job to make a decision. They would have their own opinions on how things ought to be and a good management would listen to everyone, consider possible alternatives and make a decision. A bad management would just make a decision. However, they cannot come up with solutions to everything. Why hire anyone else, if that were true?
2. Politics is bad. - I had this in my mind for a long time. Then read something in a scifi book that went like "You get politics when you have two people talk". Then I realized it is not politics that is bad.. We play politics all the time - posting this comment is politics. I am trying to convince you of something by appealing to logic and rhetoric. We tend to think politics is only when you lie and cheat and deceive people.. but that is just not true. The alternative to politics is to live in a world where might makes right. It is still true, but the concept of might is different.
Trim the fat
It was an internal project, so not even a real customer, other than the massively overfunded HR department.
We were to deliver a massive scope, an entire ecosystem of software/services to provide value for the 100K+ employees.
There was zero actual demand for it. Data clearly showed that the 100K+ employees of this massive company only needed two things: leave management and payslips.
And we were to add some 40 services to that, from a vast ecosystem of external vendors, homegrown crap, and integrating it all together. Every single piece of this new suite was specced up as if we needed NASA-level reliability.
I was puzzled from the start as to why we're even doing this, but soon realized I was overthinking it. It's busy work. It's one of the twisted incentives in corporations: be frugal and efficient to get punished, spend like a maniac and get rewarded. This is how kingdoms get created and inflate.
HR did not like to work with the internal IT department. Because they have an engineering mindset based on structure, whilst HR favors managing things Game of Thrones style. So to balance things out, not one but two external IT agencies were added to the mix, as "neutral" party between the internal departments. Mistrust from the get-go.
We're talking an army of consultants costing 200$/hr, producing documents and agreements that are treated as nothing but opinion. Some two months into the project, they understood the grim outlook of this project and got into the mindset that every hour of busywork is still revenue.
The customer, HR, acted like children, and that would be an insult to children. They would literally dream up the most outrageous requirements on the spot, just something they would personally like the system to have. Things that cost 100K to build and would save one person 5 minutes of work per week.
Any critical, rational feedback was fully dismissed, even if delivered diplomatically. Do it too often and they'd form coalitions behind your back to sabotage any of your next moves. This was of course a political setup in the making to ultimately blame IT for "failing to deliver".
As nothing actually got delivered for months, the inevitable came to be: let's launch a committee. I was on it. We spent our time producing meeting minutes of no consequence. Much needed hard decisions were unattainable as they required complicated coalition building that usually failed. Every head of every kingdom discussed things one-on-one, as if we're dealing with the mob. After a while, we used the committee basically as extended lunch, chit-chatting.
It took 8 months to deliver a first demo. A demo to ourselves, mind you. No actual user was involved. A few dozen people filled the room to see a tiny bit of poorly implemented functionality that nobody asked for. The mass psychology of it continues to fascinate me. An entire room full of people all knowing this is a sad joke, but nobody speaks up. There's even a forced hint of positivity: great progress, guys.
All of this kept going for nearly two years, after which the project was dissolved. About 25% of the scope was delivered. Our new solution for leave management and pay slips was worse than the old one, and everything else nobody uses. The 75% not delivered at all was fine as nobody wanted it anyway.
Nobody got fired and nobody had to justify the massive spend or any outcomes. In fact, the spend guarantees that a similar budget is to be granted to HR next year. Not spending this much would be very career limiting indeed.
There's no way to do true R+D with product driven budgeting. Perhaps "big corporate" has their own R+D and forbids divisions from doing R+D. Its really none of OPs business.
The backlog is always two years because budgeting is done for two years and the goal posts will change continuously to keep the backlog long enough to keep the budget afloat.
The goal posts always move continuously because R+D advances. If they close out and release 1.0 then the team and project have to shut down and transfer to the maint group. If you just keep the project eternally open then you don't have to re-create and open for bids and start entirely over to being version 2.0, you can just massage the requirements into 2.0 and keep going.
The individual contributor layer might not be cutting edge R+D, OP probably wasn't using framework-of-the-month or language-of-the-month but at the business level it might have been interesting R+D, far away in logistics-land or something.
A product driven company can bury paying for R+D this way if no one points it out, but if someone makes a formal report calling it out, that's a career limiting move so lets not look too close.
The other thing I've seen blow up is the business changes faster than the coders can keep up. If you have small enough line of business revenues you can over invest into automation; to put it in terms HN can understand if you engineer a hyper-scalable startup and only ten customers show up, that's a lot of money down the drain. Even worse if they're ten HUGE enormous customers you can stay in business a long time even if the automation would never, ever pay off with only ten customers. Or logistics invented a strategy that is obsolete before the coders can code it.
Some companies are really good at processing "build a bridge" Like a physical bridge cars drive over. Their internal systems will melt down conceptually at the idea of having a R+D dept with a permanent budget, even if it works and even if R+D makes a net profit. I had dealings with a place that, at a high level, made cranes, like industrial lifting cranes. They needed a R+D budget for R+D things but they only spoke business like a housing developer, you sign the contract, build the crane, find another contract. Smart companies that need to do R+D will find a way to do R+D even if they use really weird terminology to manage it.
The way companies like this move from one R+D project to another is "whoopsie the eternal product development is over budget scrap and do something else". Now they're probably got an eternal "fake product" around actually doing R+D using AI algos in the cloud or something. Or they're doing bland IT support, just endless Python CRUD for an R+D experiment in doing JIT logistics in a post-covid chip shortage world where the R+D is not in IT but the R+D is outside IT in logistics or accounting or marketing or something.
I can't guarantee this happened to OP but I've worked at places like that.