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
> 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.
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.
Conversely, one time I worked for 12 months on a project I believed was dumb on a team of at least 30 to 40. I thought no one was going to pay for it and it made no sense why we were building it. I told my manager my feelings and he brushed them off.
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.
It’s great. It strongly warns against ego pitching, aka talking about your fancy solution, which only prompts people to say “That’s great” so you go away.
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.
I don’t think it’s anyone’s fault at all. Business people’s job is to understand what users want and developer’s job is to figure out how to best build it.
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.
I'm not sure what's more depressing, that they didn't think that someone exfiltrating the data was an issue as long as they didn't lose it, or the fact that even if customer data was stolen, they probably were correct that there wouldn't be any ramifications for the negligence.
Oh, to be fair I should mention that it was an internal system. External threat actors were not a major concern. However, we had trading desk developers with access to the prd system and their own development space. The major concern in my mind is an absent minded copy/paste of a drop table, maybe a disgruntled employee.
> Oh, to be fair I should mention that it was an internal system. External threat actors were not a major concern.
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.
I understand defense in depth. I'm just mentioning it because is incalculable worse if those pages were exposed externally since any script kiddie would be able to pwn the site immediately.
As long as you have it documented in an email ( issue plus proposed remediation ), you are good. You did your part. Sometimes it is best just to slowly walk away like you did.
It sucks though since I sort of liked that work and had some respect of my peers. Now I just bounce from team to team every 18 months (lateral moves, no raise). I probably could have stayed there and gotten a promotion if I played the politics and kept my mouth shut. Now I'm just a lazy slacker because I've gotten shafted by the company a couple time.
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.
> we hadn’t even received all of the specifications from the customer that we would need to complete the project
> 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?
If you are a manager, and you make this type of remark, do not get it twisted. You have made a threat, and you have created an adversarial situation that limits your report's ability to trust you. You've telegraphed to them that you're willing to throw them under the bus, and they will remember.
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.
Seeing this and the todolu work advice girl ... I think educating people on how threats are composed and used is something that everyone should understand.
I'm now realized that I've been soft threatened quite a lot.
I had a similar disagreement with a manager once about a project, and I said something like, "I'm stressed and working around the clock, I don't need you threatening me," and they were genuinely taken aback and even hurt that I would interpret it that way (as they felt they were offering advice). When I asked them to reverse the situation, they immediately understood. When the pressure is on, it's an easy mistake to make.
You're harder to effectively blackmail (and therefore less likely to be blackmailed) if you can't understand when someone's blackmailing you, for example.
Semi-related to this, but this type of statement and the reaction to it is how I discovered that I had basically assumed a manager role in all but title.
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.
That's just a fractal version of this same problem.
Most of us are here to get work done and earn a living, and not to role play palace intrigue.
But certainly it's my experience that this toxicity comes from the top down and I have sympathy with managers who are putting their reports under unreasonable pressure because they are themselves under unreasonable pressure.
Presumably you're conveying the results of your research, which means new facts are on the table that the "mismanagers" weren't previously aware of. They assigned you that research work presumably because they wanted to know those facts. Now that you're showing up with useful information, they can go back and deliver an even better estimate of the project than they had before.
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.
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?
I've been naive like that a few times.
I managed to get away unharmed most times but once I was publicly blamed for the project's failure by the incompetent managers, in a governmental organisation.
I overestimated people's honesty in the face of their own career death.
I considered blowing the whistle or taking them to court for slander but I had strong doubts I could clear my name as power corrupts.
As a contractor, I was definitely on some big projects where, from the perspective of an IC in the trenches, it didn't seem like anyone was in charge, or that the people in charge didn't care about it succeeding.
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.
I wasn't in the room, and a lot of it depends on the vibe, facial expression, atmosphere, personalities, etc.
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.
I'd put it in the category of "Will no one rid me of this meddlesome priest?" [0]. There is no way for somebody with authority to express a preference without it coming across as a request. The same words that from a trusted coworker would be advice to keep your head down become an implied threat when given from an executive.
Yeah, that's fair enough. I have been lucky to have had some managers in the past who were great mentors, very transparent, and have several times during my career actively coached me on what are "Career limiting moves". It is a phrase I have heard without it being sent or received as a threat. I have over-extrapolated and under-empathized though, and realize that in majority of situations for majority of involved folks, that would not be the case. (relatedly, I've also tried to internalize and implement the notion that I can no longer joke with any variation of "don't you know that's a fireable offence? :D" etc. )
Good point, and it very much depends on the pre-existing relationship with a manager, along with the context where a statement is given. I could imagine pulling aside a coworker and quietly telling them that they're about to hear about a new project, but that volunteering to work on it would be a dead-end and a career-limiting move. Something in private, informative for an upcoming choice, not a judgment of ongoing projects.
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.
<<If the customer is not engaged enough to make clear what they want
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.
Granted, “it would be career limiting” is an ambiguous statement. We can reasonably assume that the story as written omits various context clues, additional communications, body language, and other ensuing events that gave the author a more complete understanding of what the manager meant when they said that.
I've been threatened a number of times in my life. The only people who have threatened me directly and without any fig leaves, weren't serious about it; a man on the street once said he'd kill me, and being an dumb 18 year old, I just laughed at him. He didn't do a thing, and I don't think he ever intended to. He just wanted to scare me. (I'm not bragging, this was foolish and cavalier, and I wouldn't respond that way today.)
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."
It’s only ambiguous if you haven’t been exposed to corporatese. It’s as ambiguous as the phrase “as per my last email”. He was directly told he was done getting promotions/raises if that information ever made it to the client
I read the statement as less of a threat and more of a "we're going to all ignore this" message. In other words, it's bad for everyone in the room if the situation is officially acknowledged, and so it won't be.
Omitted from this article is the details of the contract. Projects taking longer than expected is normal, and there are typically terms spelling out what should happen in that case.
> One unfortunate aspect of the customer is always right is that the customer may often be very wrong.
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.
This type of thinking is how we get ants. Ants Lana. Ants.
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.
You are right too. And yet, there are 2.87 million ants per person in the world [1], and people continue to choose short term personal goals.
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.
I did not initially read it as a threat, but as a warning. That somehow the client would end the project manager's career, or something. How naive of me! Clearly the project manager knew full well they were just milking the client for an endless stream of money for a doomed project as long as they could just provide the client with some hope that it really was nearly finished.
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.
I could never relate to people who care about their career, "success", getting ahead, or climbing the corporate ladder.
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.
> careers/jobs were just a necessary evil because it's almost impossible to survive without money
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.
Career and climbing the corporate ladder are orthogonal. For example, I don't care about climbing the corporate ladder but I do care very much about my career progression because it defines what job opportunities I get to choose from in the future and better career progression allows me more freedom to choose only the ones that are likely to be fun. (Unlike many here, I actually enjoy my profession.)
I think I agree. The job is a means to an end. The only two times that I actually applied for a higher position is when I noticed a really, really bad candidate applied ( with a good chance of getting that position too ) and would effectively become my boss. I am not the manager type, but sometimes you have to bite the bullet and choose lesser evil.
> careers/jobs were just a necessary evil because it's almost impossible to survive without money
> 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)
"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.
I'm not saying everyone is. I'm just saying the people I know who are, or have the ambition to become, CEOs etc are that way. My sample size is low, and does not include FAANG. Perhaps FAANG is more meritocracy and less politics (and I'm talking about management, not ICs). In finance and healthcare admin (CEO) it seems it's about image and politics, with the ones I know being pretentious assholes.
> 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.
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….
A career can be meaningful or meaningless. It can be meaningful if you are making money doing something you feel it's important to do in the world: for example, nature conservation work. I am working on that, and in that realm I care about the work I do. But I also have a corporate job, where I'm just hired to do something for someone else. In that case, it's only about money and I just satisfy the job description without putting anything more into it. In that case I'm just using it to make enough money to support my future projects and I don't plan on staying here much longer.
For some, a creer is a means to something else. For example, if you want to retire early, making more money is the best way to save more. Progressing in your acreer can be a great way to increase your income. Therefore progressing your career can be your best option to reach a goal outside of your career.
I also feel that work is among the least important things I've got going on, but that doesn't seem like a reason not to care about maximizing career success. If you've got to work ~40 hours per week anyway, why not make an effort to maximize the return on your time?
It might help to learn about how they spend their time out of work, and to learn about their upbringing and parents. And how they see their goals at work.
I can tell you that many of them also see work as a necessary evil they need to do what they really want.
Oof. Had a similar experience on the other side quite a few years ago. I had recently started a job where my new employer had been working with a contractor on their "next gen" web application for 4 years and it was nowhere near production ready.
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.
In my career I have two clear examples of projects that
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.
$60 million project somebody's paying you to do? there's no way that this project doesn't have heavy requirements on their end too, and the trick to managing a project like this is to make sure that every time you meet the client that they have milestones/deliverables to present to your team also. They will be late, as you are, but now you got them to ask for deadline extensions.
For all the very justifiable shit "Agile" gets, this is what the original "Agile manifesto" agile was supposed to prevent, right? Deliver something early, so you (customer and devs both) learn more quickly what's missing and what will never actually be needed.
In a way but also I think there are unfortunately a lot of consulting firms where the core business model is just to make sure they can keep billing the client for as long as possible. So they will prefer that the project or collection of projects are never really finished and will just keep increasing the scope with no real regard for business outcomes except contract extensions.
See? Even clients benefit from early delivery! The consulting firm can't just bluff about their ability to deliver! I guess the reason I brought it up at all is that this seems like a very preventable tragedy if people grokked some pretty easy principles. Ah, maybe in a generation or two...
> Two years later, the client canceled the two-years-late project before it ever launched. They ate a $60M loss.
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.)
Not sure how to feel about this TBH. On one hand, yeah, it is clearly a pretty big screw-up on the part of the contracting company, to provide $60M without sufficient specifications as to exactly what they are trying to buy. On the other, accepting $60M without providing anything of value seems pretty unethical.
Who ate the $60m? The author's employer, or the client?
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.
Understand what management means. It means to extract value. You can do work, or you can manage it, which means getting credit for keeping the ball in the air, and attritioning out anyone who doesn't. This is anathema to people who actually solve problems (like me), but it's for a very specific reason.
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.
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.
If accurate, realistic project schedules are considered a "career limiting move" then obviously the company was never a good place to advance your career anyway. As evidenced in this anecdote, this mentality doesn't produce good results for those companies.
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.
> If accurate, realistic project schedules are considered a "career limiting move" then obviously the company was never a good place to advance your career anyway. As evidenced in this anecdote, this mentality doesn't produce good results for those companies.
Not good results how? They got their $60M and moved on to the next sucker.
When I was younger I thought I was smart when I would point out an organization's dysfunction. Now I think the smart thing is to figure out how to be effective in dysfunction, which is everywhere at some level.
Working in dysfunction wears me down. To me Dilbert is funny for the first 10 strips or so, then it becomes dull and depressing. My way is to try to get small victories against dysfunction. When I stop getting these, I start seeking for another dysfunction elsewhere.
I deal with C-level folks on a daily basis, and if you come to them with problems, its not always clear to them what you want them to do about it. They are not going to be intimately familiar with everything. It's only human nature. Better is to provide the information along with something like "Hey, and here's an idea that might help us not lose the contract. I'd like to be give a chance to implement it.". Senior management can't evaluate people on a technical basis, but they can and do remember people who stood up and took on a challenge.
I don't think they have it at my company. Or maybe nobody was nice enough to tell me. That might explain being just a midlevel after 10 years and a masters...
If you're still being paid like a mid-level dev after 10 years, you owe it to yourself to look for a new job and get a massive pay raise.
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.
Would it be legal (and, different question, do you think it would be ethical) in a case like this to quit and go to the client company proposing advice on how to negotiate to avoid the $60M loss?
A role of advisor to let them know they need to get their shit together (and provide the required specs) and to guide themto ask for incremental delivery.
As far as I can tell such a consultancy is easily worth $1M/year or more, given its potential effectiveness.
Seems like acting on privileged imformation for personal gain. I think that would be a very risky idea. OTOH advocating for the same role from within the company is probably a way to repair the project without pre-burning your bridges. You could still leverage those connections to switch companies (basically, show the client thar you want to formally represent them).
This happens in a similar away at the small architecture company I work at. A client will pay for work, and then it will then become clear the work they have asked for is infeasible. However we are still contracted to do work. It benefits us to do this work and bill for it. I find it totally unethical to do any work after finding out that it will never result in a building, but my managers know that if we do the work we can bill for it. I think this story is the same, whereby the managers know the client will not benefit, but also that they will pay.
A recent HN post spoke about how employees are either aligned with a company (profit) or the overall goals espoused by the company. These goals appeal to the client. This story is an example of the OP being aligned to the client but not the company, and essentially how our economy is not aligned with ethical practice.
This is just not a great way to go about things and this is exactly the problem Agile is supposed be solving. When you deliver value incrementally, it becomes painfully obvious to everyone where the gaps are and what's at risk of not being delivered. It also puts the onus on the customer to TELL you what they want instead of you having to guess.
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.
edit: luckily we can read the story from sibling comment.
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.
I have it open and will paste it here since it's a text story.
--
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.
I remember going to a training on project management where they told story about a project manager at a major research university who was told to estimate what it would cost to implement Peoplesoft and was let go when he told the truth about what it would cost.
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.
Forgive my ignorance of "Enterprise" software, but what does "implementing Peoplesoft" involve, exactly? Isn't it like SAP where it's a base system with some predefined starter templates that you customize? And to "customize" means just adding custom fields and data-entry forms, and wire it all up to an ERP and something like Biztalk? How does that add-up to $100m?
By the time you come to a size where you would consider SAP or PeopleSoft, you are already a mid to large size company. You have developed internal process and workflows. You would have policies put in place that are crazy, contradicting each other and different across divisions, business lines and roles. You are trying to model all of this in a software that was not organically grown in your company. This is what implementation mean.
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.
My understanding is that Peoplesoft worked out OK for most corporations but it went notoriously wrong in higher ed. Australia tried to roll it out over numerous universities in a huge project which went terribly wrong.
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.
This is anecdotal, but I've also seen several projects in my ~20-year career that ended up no where. And reading through these stories (and there are countless stories of these doomed projects) one cannot help but wonder the amount of waste that we create. The original motivation of the whole Lean Startup was to reduce waste - not that Lean Startup model fits all the projects (and it shouldn't). Of course, it's impossible to know how a project will end up, but there must be a way for us as humanity to improve?
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.
This EXACTLY happened to me at a somewhat well known software company. We were working on a project and I spoke out that the performance wasn't anywhere where it needed to be. I was pretty sure it wasn't going to work in a real situation.
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.
OK, you trio of rabble-rousers are now an Architecture Board.
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?)
> Two years later, the client canceled the two-years-late project before it ever launched. They ate a $60M loss.
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.
> 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'm not a project management expert, but isn't this basically why Agile was created so that incremental/iterative progress can be more easily delivered? Like hearing this part is insane to me:
> 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".
Lol all the people in this thread - "if you reduce scope..." "if you presented a solution...". This is a 200 person multi-million dollar project, you can't turn the ship in less than 12 months. You've already hit the iceberg, you just haven't felt it yet.
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.
> Bet that manager’s still at the company, though.
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!
I encountered a similar situation at a tiny startup. The VP of Engineering was hired by the board, against the founder's will, and he was a disaster. Our main metric was measured by a graph, showing foobars/second. Similar to the linked story, there were lots of off-schedule tasks, and the VP was focused on shallow features instead of fundamentals. One of those features was i18n, apparently because his girlfriend was the consultant on i18n.
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.
Some of us have decided to embrace our idealism/personality flaws and continue forth, undaunted, regardless of occasional negative feedback from others.
Being able to do your work without having to deal with people who value career over client outcomes is one of the best reasons to pursue financial independence. For a creative person that type of environment is soul sucking.
For the managers. Admitting you got it wrong is [more] career limiting than proceeding with a doomed project and then (presumably) blaming other factors. Heck, you may even have gotten promoted in the intervening 2 years.
There is a spectrum between full principled rebellion and complete acquiescence to a shit project.
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 don't think I've ever heard an anecdote about a "career limiting" statement being made which wasn't a red flag about the company culture.
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!
Here is where the blogger loses me "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."
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.
The author should have jumped to the end immediately: follow the rats off the sinking ship. There's no winning on one of these projects, and if you find yourself in one, run away immediately. Knowing it was a doomed project and still accepting any sort of responsibility for it is dazzlingly naive; the ship will not make port, and you will all drown.
I read through to the end. Because that's what a thorough engineer does. But honestly, I guessed exactly how this story was going to end when they rattled off the long list of the different kinds of managers. Manager::engineer ratio has exactly the opposite effect as teacher::student ratio does.
I've been at companies like this, and learned from peers that you had to write "CYA" (cover yourself) documents. But, I also learned learned that these documents should never skip levels of middle management, so that intermediaries have time to bury or re-frame the news.
It's on one side of the bell curve but still a reasonably common size in ERP space. Not all of those projects are successful, but not all of them are failures either.
(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.)
Oh yeah. The product I worked on in the past went this way. We had a mature product that I said we probably needed to rewrite and modernize to handle any additional increase in volume or integrations with other systems. I left the team due to mostly politics. A year later, half my old subdivision was laid off and the project went to a contractor.
Funny enough, they're about 2 years behind schedule.
More than half of this thread sounds like we are all just sociopaths and the scary thing is that I see myself 10 years ago in the answers. I would like to correct 2 perceptions that I see as common threads:
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.
I once worked on a project for a giant multinational, took 2 years, and was a complete catastrophe costing the company ~10M with zero value delivered. I'm sharing it because I learned a lot from it.
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.
I've seen "product driven management companies" do R+D the way OP saw things happening.
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.
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...