{ "archive_path": "archive/1768757156.629201", "base_url": "lalitm.com/post/why-senior-engineers-let-bad-projects-fail", "basename": "", "bookmarked_date": "2026-01-18 17:25", "canonical": { "archive_org_path": "https://web.archive.org/web/lalitm.com/post/why-senior-engineers-let-bad-projects-fail", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=lalitm.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": null }, "domain": "lalitm.com", "downloaded_at": "2026-01-18T17:25:59.076061+00:00", "downloaded_datestr": "2026-01-18 17:25", "extension": "", "hash": "Y5C413QV2N2TKAT2JJ3E", "history": { "archive_org": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://web.archive.org/save/https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/" ], "cmd_version": "8.10.1", "end_ts": "2026-01-18T17:27:00.314779+00:00", "index_texts": null, "output": "https://web.archive.org/web/20260118172643/https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/", "pwd": "/data/archive/1768757156.629201", "schema": "ArchiveResult", "start_ts": "2026-01-18T17:26:39.058689+00:00", "status": "succeeded" } ], "dom": [ { "cmd": [ "/usr/bin/chromium-browser", "--proxy-server=socks5://tor-socks-proxy:9150", "--disable-features=DarkMode", "--run-all-compositor-stages-before-draw", "--hide-scrollbars", "--autoplay-policy=no-user-gesture-required", "--no-first-run", "--use-fake-ui-for-media-stream", "--use-fake-device-for-media-stream", "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'", "--headless=new", "--no-sandbox", "--no-zygote", "--disable-dev-shm-usage", "--disable-software-rasterizer", "--disable-sync", "--window-size=1440,2000", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "--user-data-dir=/data/personas/Default/chrome_profile", "--profile-directory=Default", "--dump-dom", "https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/" ], "cmd_version": "131.0.6778", "end_ts": "2026-01-18T17:26:14.813401+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1768757156.629201", "schema": "ArchiveResult", "start_ts": "2026-01-18T17:26:08.538774+00:00", "status": "succeeded" } ], "favicon": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.google.com/s2/favicons?domain=lalitm.com" ], "cmd_version": "8.10.1", "end_ts": "2026-01-18T17:26:02.807244+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1768757156.629201", "schema": "ArchiveResult", "start_ts": "2026-01-18T17:25:59.608679+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/" ], "cmd_version": "8.10.1", "end_ts": "2026-01-18T17:26:03.038020+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1768757156.629201", "schema": "ArchiveResult", "start_ts": "2026-01-18T17:26:02.843681+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2026-01-18T17:26:32.429491+00:00", "index_texts": [ "Why Senior Engineers Let Bad Projects Fail - Lalit Maganti (https://fedi.lalitm.com/@lalitm) (https://fonts.googleapis.com) (https://fonts.gstatic.com) (https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&family=Roboto+Condensed:wght@400&family=Source+Code+Pro:wght@400;500&display=swap) (/css/main.min.css) (/favicon.ico) (/apple-touch-icon.png) (https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/) (/) Lalit Maganti \u00d7 (/page/about/) About (/index.xml) RSS (/page/about/#newsletter) Newsletter Why Senior Engineers Let Bad Projects Fail Jan 13, 2026 \u00b7 Essay When I was a junior engineer, my manager would occasionally confide his frustrations to me in our weekly 1:1s. He would point out a project another team was working on and say, \u201cI don\u2019t believe that project will go anywhere, they\u2019re solving the wrong problem.\u201d I used to wonder, \u201cBut you are very senior, why don\u2019t you just go and speak to them about your concerns?\u201d It felt like a waste of his influence to not say anything. So it\u2019s quite ironic that I found myself last week explaining to a mentee why I thought a sister team\u2019s project would have to pivot because they\u2019d made a poor early design choice. And he rightfully asked me the same question I had years ago: \u201cwhy don\u2019t you just tell them your opinion?\u201d It\u2019s been on my mind ever since because I realized I\u2019d changed my stance on it a lot over the years. The answer is that being right and being effective are different. In large companies, speaking up about what you see as a \u201cbad project\u201d is a good thing. But only in moderation. Sometimes the mark of seniority is realizing that arguing with people who won\u2019t listen isn\u2019t worth it; it\u2019s better to save your counsel. Bad projects What I mean by a \u201cbad project\u201d is many things: UX : making product complicated, solving a problem which doesn\u2019t exist, breaking existing workflows Technical : overcomplicated design, wrong library, poor performing architecture Political : chasing hype cycles, exists primarily to justify a promotion It\u2019s important to point out that for much of the lifecycle of a project, whether it\u2019s \u201cbad\u201d is highly subjective. Software engineering is largely a game of tradeoffs and making decisions which are not perfect but the best possible with the information available. There often can be disagreements on whether correct choices are made and it only becomes obvious much later on, potentially years after a project has shipped. But as you become more senior, you\u2019ll start to have \u201ctaste\u201d when it comes to software projects and that will cause you to look at some fraction of the software projects and feel \u201cthis doesn\u2019t make sense\u201d. And this gut feeling is the sign to me of a \u201cbad project\u201d, one which you can see in advance of when it\u2019s obvious to everyone. Drawing on my personal experience, the most memorable example was a few years ago at Google . There was a high-profile announcement internally of a \u201cgame changer\u201d project that sat right at the intersection of two extremely large organizations. It was technically amazing and elegant, and full of clever ideas for really hard problems. But I distinctly remember sitting in the room for the announcement, turning to my lead and whispering, \u201cThis project has no chance of succeeding, right?\u201d He turned to me and just said, \u201cYup.\u201d We both realized the problem immediately. The project was entirely based on a platform team asking a flagship product team to give up control of their core user flow: technically the right move, but no lead or PM would ever cede ownership of something that central to another team. Politically, this project was a total fantasy. The project kept quietly chugging away in the background for almost two years. Every time it got close to launch, it would get pushed back as \u201cnot ready yet.\u201d Over time, we heard less and less about it until, eventually, the inevitable \u201cstrategic pivot\u201d email appeared in my inbox. Resources were reallocated and the code was deleted. We were told the company \u201clearned a lot from the effort,\u201d but to me it felt like it was doomed from the beginning. Politics and solving the correct problem matter just as much as technical beauty. Why you cannot stop them all When I started noticing \u201cbad projects\u201d and I felt that I had some expertise to share, the temptation for me was to start calling them out. Reach out to the team doing it, tell them \u201cthis doesn\u2019t make sense\u201d and explain to them why. Use facts and logic to persuade. And I did do this. But only for a very short time before I realized that there are a lot of costs to doing this that I just wasn\u2019t thinking about. Firstly, software companies have an inherent bias for action. They value speed and shipping highly. Concerns, by definition, slow things down and mean people have to look at things which they hadn\u2019t budgeted for. And so unless your concern is big enough to overcome the \u201cpush for landing\u201d, there\u2019s little chance for any meaningful change to come from you saying something. In fact, it\u2019s very likely that you\u2019ll be largely ignored. Related to this, even if the team does take your concern seriously, you have to be careful not to do it too often. Once or twice, you might be seen as someone who is upholding \u201cquality\u201d. But do it too often and you quickly move to being seen as a \u201cnegative person\u201d, someone who is constantly a problem maker, not a problem \u201cfixer\u201d. You rarely get credit for the disasters you prevented. Because nothing happened, people forget about it quickly. There\u2019s also the problem that every time you push back, you are potentially harming someone\u2019s promotion packet or a VP\u2019s \u201cpet project.\u201d You are at risk of burning bridges and creating \u201cenemies\u201d, at least of a sort. Having a few people who disagree in a big company with you is the cost of doing business, but if you have too many, it starts affecting your main work too. Finally, there is also the psychological impact. There is one of you and hundreds of engineers working in spaces that your expertise might help with. Your attention is finite, but the capacity for a large company to generate bad ideas is infinite. Speaking from experience, getting too involved in stopping these quickly can make you very cynical about the state of the world. And this is really not a good place to be. Manage influence like a bank account So if you cannot stop all the bad projects, what do you do? You get strategic. Instead of trying to fix everything, view your influence as a bank account. You have a certain amount of \u201cinfluence\u201d coming in every month as you do your job, help people, ship successful projects, and generally remain low friction. Then, when it matters, you should be ready to make \u201cwithdrawals.\u201d Every time you block something or raise concerns, no matter how small, you are writing a check against your balance. But not all checks are the same size: The $5 Check: A nitpick on a code review. Cheap, daily expense. The $500 Check: Challenging an architectural decision or pushing back on a timeline. Requires some savings. The $50,000 Check: Trying to kill a VP\u2019s pet project. This is a massive spend. You might only afford this once every few years. The problem comes if you spend $5 on every minor inefficiency you see. If you are constantly saying \u201cno\u201d to small things, your account will be empty when you need to write the big check to stop a true disaster. If you \u201cgo overdrawn,\u201d you enter political bankruptcy. People stop inviting you to meetings, they stop asking for your opinion, they essentially start working around you. Once you are bankrupt, your influence drops to zero and you not only harm your ability to influence things but also start hurting your own ability to get things done. When to spend influence Given that we\u2019ve now accepted that we cannot weigh in on everything, we need to figure out when it does make sense to do so. The most important thing to do first is to be humble and evaluate whether you actually have the expertise to make a judgment. Seniority often brings opinions, but those are not always informed opinions. For example, while I have some frontend experience, I do not feel qualified to give deep advice on it because my knowledge is \u201cenough to get by\u201d rather than deep expertise that comes from long term ownership. It is easy to lose sight of the fact that high-quality judgments require informed opinions. If you find yourself in this position, see yourself as an opinionated observer and stop there. You must also internalize the fact that just because you say something does not make it the truth. You are raising awareness of a point of view, not issuing a decree. So if some team doesn\u2019t listen to your concerns and decides to go ahead with what they were doing anyway, then you have to accept that and move on: at the end of the day, you\u2019re an engineer, not a CEO with authority over them! Given these points, I use three main factors to decide when to speak up: How close is the project to my team? If it goes wrong, how much impact will it have on my team? If it goes wrong, how big will the problem be for the company? Proximity. If a project is close to you, the \u201cprice tag\u201d of saying something is lower. If it is within your own team, the cost is near zero because you have high trust and a quick conversation often solves it. If it is in your broader organization, the price goes up; you have to spend social capital and potentially stake your reputation. If it is outside your org? The cost is often prohibitive. You have zero leverage, different reporting chains, and stopping it would require a massive withdrawal. Team Impact. Sometimes another org does something that deeply affects your work. For example, because (https://perfetto.dev/) Perfetto (the performance tool I work on) has users throughout Google, sometimes a team will ask us to sign off on a very complex integration. This is a classic risk: if things go right, they get the credit, but if things go wrong, your leadership might expect you to help solve a problem you didn\u2019t create. In these cases, the payoff of speaking up is high because you are protecting your team. Company Scale. Finally, consider the blast radius. Some projects are self-contained; if they fail, they only take themselves down. Others are so intertwined with core systems that their failure causes widespread damage or creates technical debt that persists for years. These can be deadly to the long-term health of a project. How to act with bad projects It\u2019s also not just about when you put your opinions forward but how you do it. There\u2019s a very wide range of actions you can take depending on what you\u2019re facing. When you intervene The nuclear option is to directly say \u201cwe should not do this\u201d and try to shut the project down. This almost always requires escalation to your leads and the leads of the owning team, requiring great conviction in both the fact that you\u2019re right and that this project will be actively harmful. But on some occasions, this is the right thing to do, especially if the cost of not saying something can be existential to your project or team. A slightly softer but still quite risky variant of this is, instead of doing a direct escalation, you raise concerns in directly with the team. Usually this is done with a meeting with the team or a strongly worded \u201cconcern\u201d or \u201crebuttal\u201d doc. The goal is to speak in strong enough terms that the team themselves conclude that this the project might not be a good idea. Then there are the smaller interventions, nudging things in the right direction. These are perfect for when a team is about to do something that makes sense from a high level but they are going about this the wrong way. I see this often with Perfetto: a team sends a design doc proposing a complex use of Perfetto that I know will cause them pain later. I sit down with them, understand their actual problem, and guide them to a better solution. It costs an hour but saves them months. If you do it right, you can even be seen as a helper rather than a hindrance, even if you do slow down the team. When you don\u2019t Sometimes you conclude that the ROI just isn\u2019t there to do anything direct: the political momentum is too strong, or the issue is too small to justify spending any influence. At this point, what you do depends on how much your team is involved. If it overlaps with your team\u2019s work heavily then it might be best to make some subtle contingency plans: reducing your dependency on it or building abstractions to cope if it goes away. There is also a long game trick here. Even a bad project usually has an \u201cessence\u201d of a good idea, a specific problem it was trying to solve or an insight it was based on. If it fits with your job, it\u2019s often a good idea to take that essence and see if you can naturally incorporate a better version of that specific solution into your own project. That way, if the bad project stalls or gets canceled, you can be proactive instead of reactive to the fallout. Alternatively, if you\u2019re not involved, it\u2019s easy: just stay out of the picture. Vent to friendly colleagues in private, commiserate, but in public, live with the reality. Managing your team through it Finally, you must manage your own team through the process. If you can see the flaws in a project, other senior engineers probably see them too. Don\u2019t try to gaslight them or \u201cwalk the company line\u201d by pretending a bad project is actually good. It destroys trust. Instead, be honest about the facts on the ground without going into unnecessary political details. Tell them that you will do the best you can under these constraints. Conclusion So what did I tell my mentee? \u201cI\u2019ve learned that being right and being effective are different things. I could go tell them my concerns. They probably wouldn\u2019t listen. I\u2019d burn some goodwill. And in six months, nobody will remember that I called it, they\u2019ll just remember I was the guy who tried to block their work\u201d. When you\u2019re earlier in your career, you want to believe that good ideas win on merit, that if you just explain clearly enough, people will see reason. It took me quite some time to accept that big companies don\u2019t work that way. But this doesn\u2019t mean you stop caring. It means you get strategic about when to spend your credibility. Pick the battles where you can actually change the outcome, where your team will be hurt if you stay silent, where the cost of being wrong is low but the cost of the project failing is high. And for everything else? You vent to colleagues, you make quiet contingency plans, and you watch. Sometimes you learn something. Sometimes you\u2019re wrong and the project actually works. And sometimes you get to feel that grim satisfaction of predicting exactly how things would fall apart. None of this is as satisfying as fixing everything. But it works and keeps me sane. If you enjoyed this post, consider (/page/about/#newsletter) subscribing to my newsletter or following via (/index.xml) RSS . You can also share it on (https://news.ycombinator.com/submitlink?u=https%3a%2f%2flalitm.com%2fpost%2fwhy-senior-engineers-let-bad-projects-fail%2f&t=Why%20Senior%20Engineers%20Let%20Bad%20Projects%20Fail) Hacker News or (https://lobste.rs/stories/new?url=https%3a%2f%2flalitm.com%2fpost%2fwhy-senior-engineers-let-bad-projects-fail%2f&title=Why%20Senior%20Engineers%20Let%20Bad%20Projects%20Fail) Lobsters . (/post/why-senior-engineers-let-bad-projects-fail/) # 10:48 / (/tags/careers) #careers (/tags/software-engineering) #software-engineering (/tags/big-tech) #big-tech (/post/one-number-i-trust/) One Number I Trust: Plain-Text Accounting for a Multi-Currency Household \u2192 " ], "output": "htmltotext.txt", "pwd": "/data/archive/1768757156.629201", "schema": "ArchiveResult", "start_ts": "2026-01-18T17:26:32.409807+00:00", "status": "succeeded" } ], "media": [ { "cmd": [ "/usr/local/bin/yt-dlp", "--restrict-filenames", "--trim-filenames", "128", "--write-description", "--write-info-json", "--write-annotations", "--write-thumbnail", "--no-call-home", "--write-sub", "--write-auto-subs", "--convert-subs=srt", "--yes-playlist", "--continue", "--no-abort-on-error", "--ignore-errors", "--geo-bypass", "--add-metadata", "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)", "--skip-download", "--cache-dir=/data/yt-dlp-cache/", "--cookies=/data/yt-dlp-cache/cookies.txt", "--proxy=socks5://tor-socks-proxy:9150", "--no-playlist", "https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/" ], "cmd_version": "2024.10.7", "end_ts": "2026-01-18T17:26:39.020262+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1768757156.629201", "schema": "ArchiveResult", "start_ts": "2026-01-18T17:26:34.849962+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/" ], "cmd_version": "2.2.3", "end_ts": "2026-01-18T17:26:32.380101+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1768757156.629201", "schema": "ArchiveResult", "start_ts": "2026-01-18T17:26:29.132489+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmpaf0t1w66", "https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/" ], "cmd_version": "0.0.11", "end_ts": "2026-01-18T17:26:18.355602+00:00", "index_texts": [ "When I was a junior engineer, my manager would occasionally confide his frustrations to me in our weekly 1:1s. He would point out a project another team was working on and say, \u201cI don\u2019t believe that project will go anywhere, they\u2019re solving the wrong problem.\u201d I used to wonder, \u201cBut you are very senior, why don\u2019t you just go and speak to them about your concerns?\u201d It felt like a waste of his influence to not say anything.So it\u2019s quite ironic that I found myself last week explaining to a mentee why I thought a sister team\u2019s project would have to pivot because they\u2019d made a poor early design choice. And he rightfully asked me the same question I had years ago: \u201cwhy don\u2019t you just tell them your opinion?\u201d It\u2019s been on my mind ever since because I realized I\u2019d changed my stance on it a lot over the years.The answer is that being right and being effective are different.In large companies, speaking up about what you see as a \u201cbad project\u201d is a good thing. But only in moderation. Sometimes the mark of seniority is realizing that arguing with people who won\u2019t listen isn\u2019t worth it; it\u2019s better to save your counsel.Bad projectsWhat I mean by a \u201cbad project\u201d is many things:UX: making product complicated, solving a problem which doesn\u2019t exist, breaking existing workflowsTechnical: overcomplicated design, wrong library, poor performing architecturePolitical: chasing hype cycles, exists primarily to justify a promotionIt\u2019s important to point out that for much of the lifecycle of a project, whether it\u2019s \u201cbad\u201d is highly subjective. Software engineering is largely a game of tradeoffs and making decisions which are not perfect but the best possible with the information available. There often can be disagreements on whether correct choices are made and it only becomes obvious much later on, potentially years after a project has shipped.But as you become more senior, you\u2019ll start to have \u201ctaste\u201d when it comes to software projects and that will cause you to look at some fraction of the software projects and feel \u201cthis doesn\u2019t make sense\u201d. And this gut feeling is the sign to me of a \u201cbad project\u201d, one which you can see in advance of when it\u2019s obvious to everyone.Drawing on my personal experience, the most memorable example was a few years ago at Google . There was a high-profile announcement internally of a \u201cgame changer\u201d project that sat right at the intersection of two extremely large organizations. It was technically amazing and elegant, and full of clever ideas for really hard problems.But I distinctly remember sitting in the room for the announcement, turning to my lead and whispering, \u201cThis project has no chance of succeeding, right?\u201d He turned to me and just said, \u201cYup.\u201d We both realized the problem immediately. The project was entirely based on a platform team asking a flagship product team to give up control of their core user flow: technically the right move, but no lead or PM would ever cede ownership of something that central to another team. Politically, this project was a total fantasy.The project kept quietly chugging away in the background for almost two years. Every time it got close to launch, it would get pushed back as \u201cnot ready yet.\u201d Over time, we heard less and less about it until, eventually, the inevitable \u201cstrategic pivot\u201d email appeared in my inbox. Resources were reallocated and the code was deleted. We were told the company \u201clearned a lot from the effort,\u201d but to me it felt like it was doomed from the beginning. Politics and solving the correct problem matter just as much as technical beauty.Why you cannot stop them allWhen I started noticing \u201cbad projects\u201d and I felt that I had some expertise to share, the temptation for me was to start calling them out. Reach out to the team doing it, tell them \u201cthis doesn\u2019t make sense\u201d and explain to them why. Use facts and logic to persuade.And I did do this. But only for a very short time before I realized that there are a lot of costs to doing this that I just wasn\u2019t thinking about.Firstly, software companies have an inherent bias for action. They value speed and shipping highly. Concerns, by definition, slow things down and mean people have to look at things which they hadn\u2019t budgeted for. And so unless your concern is big enough to overcome the \u201cpush for landing\u201d, there\u2019s little chance for any meaningful change to come from you saying something. In fact, it\u2019s very likely that you\u2019ll be largely ignored.Related to this, even if the team does take your concern seriously, you have to be careful not to do it too often. Once or twice, you might be seen as someone who is upholding \u201cquality\u201d. But do it too often and you quickly move to being seen as a \u201cnegative person\u201d, someone who is constantly a problem maker, not a problem \u201cfixer\u201d. You rarely get credit for the disasters you prevented. Because nothing happened, people forget about it quickly.There\u2019s also the problem that every time you push back, you are potentially harming someone\u2019s promotion packet or a VP\u2019s \u201cpet project.\u201d You are at risk of burning bridges and creating \u201cenemies\u201d, at least of a sort. Having a few people who disagree in a big company with you is the cost of doing business, but if you have too many, it starts affecting your main work too.Finally, there is also the psychological impact. There is one of you and hundreds of engineers working in spaces that your expertise might help with. Your attention is finite, but the capacity for a large company to generate bad ideas is infinite. Speaking from experience, getting too involved in stopping these quickly can make you very cynical about the state of the world. And this is really not a good place to be.Manage influence like a bank accountSo if you cannot stop all the bad projects, what do you do? You get strategic. Instead of trying to fix everything, view your influence as a bank account. You have a certain amount of \u201cinfluence\u201d coming in every month as you do your job, help people, ship successful projects, and generally remain low friction.Then, when it matters, you should be ready to make \u201cwithdrawals.\u201d Every time you block something or raise concerns, no matter how small, you are writing a check against your balance. But not all checks are the same size:The $5 Check: A nitpick on a code review. Cheap, daily expense.The $500 Check: Challenging an architectural decision or pushing back on a timeline. Requires some savings.The $50,000 Check: Trying to kill a VP\u2019s pet project. This is a massive spend. You might only afford this once every few years.The problem comes if you spend $5 on every minor inefficiency you see. If you are constantly saying \u201cno\u201d to small things, your account will be empty when you need to write the big check to stop a true disaster.If you \u201cgo overdrawn,\u201d you enter political bankruptcy. People stop inviting you to meetings, they stop asking for your opinion, they essentially start working around you. Once you are bankrupt, your influence drops to zero and you not only harm your ability to influence things but also start hurting your own ability to get things done.When to spend influenceGiven that we\u2019ve now accepted that we cannot weigh in on everything, we need to figure out when it does make sense to do so.The most important thing to do first is to be humble and evaluate whether you actually have the expertise to make a judgment. Seniority often brings opinions, but those are not always informed opinions. For example, while I have some frontend experience, I do not feel qualified to give deep advice on it because my knowledge is \u201cenough to get by\u201d rather than deep expertise that comes from long term ownership. It is easy to lose sight of the fact that high-quality judgments require informed opinions. If you find yourself in this position, see yourself as an opinionated observer and stop there.You must also internalize the fact that just because you say something does not make it the truth. You are raising awareness of a point of view, not issuing a decree. So if some team doesn\u2019t listen to your concerns and decides to go ahead with what they were doing anyway, then you have to accept that and move on: at the end of the day, you\u2019re an engineer, not a CEO with authority over them!Given these points, I use three main factors to decide when to speak up:How close is the project to my team?If it goes wrong, how much impact will it have on my team?If it goes wrong, how big will the problem be for the company?Proximity. If a project is close to you, the \u201cprice tag\u201d of saying something is lower. If it is within your own team, the cost is near zero because you have high trust and a quick conversation often solves it. If it is in your broader organization, the price goes up; you have to spend social capital and potentially stake your reputation. If it is outside your org? The cost is often prohibitive. You have zero leverage, different reporting chains, and stopping it would require a massive withdrawal.Team Impact. Sometimes another org does something that deeply affects your work. For example, because Perfetto (the performance tool I work on) has users throughout Google, sometimes a team will ask us to sign off on a very complex integration. This is a classic risk: if things go right, they get the credit, but if things go wrong, your leadership might expect you to help solve a problem you didn\u2019t create. In these cases, the payoff of speaking up is high because you are protecting your team.Company Scale. Finally, consider the blast radius. Some projects are self-contained; if they fail, they only take themselves down. Others are so intertwined with core systems that their failure causes widespread damage or creates technical debt that persists for years. These can be deadly to the long-term health of a project.How to act with bad projectsIt\u2019s also not just about when you put your opinions forward but how you do it. There\u2019s a very wide range of actions you can take depending on what you\u2019re facing.When you interveneThe nuclear option is to directly say \u201cwe should not do this\u201d and try to shut the project down. This almost always requires escalation to your leads and the leads of the owning team, requiring great conviction in both the fact that you\u2019re right and that this project will be actively harmful. But on some occasions, this is the right thing to do, especially if the cost of not saying something can be existential to your project or team.A slightly softer but still quite risky variant of this is, instead of doing a direct escalation, you raise concerns in directly with the team. Usually this is done with a meeting with the team or a strongly worded \u201cconcern\u201d or \u201crebuttal\u201d doc. The goal is to speak in strong enough terms that the team themselves conclude that this the project might not be a good idea.Then there are the smaller interventions, nudging things in the right direction. These are perfect for when a team is about to do something that makes sense from a high level but they are going about this the wrong way. I see this often with Perfetto: a team sends a design doc proposing a complex use of Perfetto that I know will cause them pain later. I sit down with them, understand their actual problem, and guide them to a better solution. It costs an hour but saves them months. If you do it right, you can even be seen as a helper rather than a hindrance, even if you do slow down the team.When you don\u2019tSometimes you conclude that the ROI just isn\u2019t there to do anything direct: the political momentum is too strong, or the issue is too small to justify spending any influence. At this point, what you do depends on how much your team is involved.If it overlaps with your team\u2019s work heavily then it might be best to make some subtle contingency plans: reducing your dependency on it or building abstractions to cope if it goes away. There is also a long game trick here. Even a bad project usually has an \u201cessence\u201d of a good idea, a specific problem it was trying to solve or an insight it was based on. If it fits with your job, it\u2019s often a good idea to take that essence and see if you can naturally incorporate a better version of that specific solution into your own project. That way, if the bad project stalls or gets canceled, you can be proactive instead of reactive to the fallout.Alternatively, if you\u2019re not involved, it\u2019s easy: just stay out of the picture. Vent to friendly colleagues in private, commiserate, but in public, live with the reality.Managing your team through itFinally, you must manage your own team through the process. If you can see the flaws in a project, other senior engineers probably see them too. Don\u2019t try to gaslight them or \u201cwalk the company line\u201d by pretending a bad project is actually good. It destroys trust.Instead, be honest about the facts on the ground without going into unnecessary political details. Tell them that you will do the best you can under these constraints.ConclusionSo what did I tell my mentee? \u201cI\u2019ve learned that being right and being effective are different things. I could go tell them my concerns. They probably wouldn\u2019t listen. I\u2019d burn some goodwill. And in six months, nobody will remember that I called it, they\u2019ll just remember I was the guy who tried to block their work\u201d.When you\u2019re earlier in your career, you want to believe that good ideas win on merit, that if you just explain clearly enough, people will see reason. It took me quite some time to accept that big companies don\u2019t work that way.But this doesn\u2019t mean you stop caring. It means you get strategic about when to spend your credibility. Pick the battles where you can actually change the outcome, where your team will be hurt if you stay silent, where the cost of being wrong is low but the cost of the project failing is high.And for everything else? You vent to colleagues, you make quiet contingency plans, and you watch. Sometimes you learn something. Sometimes you\u2019re wrong and the project actually works. And sometimes you get to feel that grim satisfaction of predicting exactly how things would fall apart.None of this is as satisfying as fixing everything. But it works and keeps me sane." ], "output": "readability/", "pwd": "/data/archive/1768757156.629201", "schema": "ArchiveResult", "start_ts": "2026-01-18T17:26:15.996580+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/" ], "cmd_version": "8.10.1", "end_ts": "2026-01-18T17:26:14.904732+00:00", "index_texts": null, "output": "Why Senior Engineers Let Bad Projects Fail - Lalit Maganti", "pwd": "/data/archive/1768757156.629201", "schema": "ArchiveResult", "start_ts": "2026-01-18T17:26:14.877412+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "https://web.archive.org/web/20260118172643/https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "Why Senior Engineers Let Bad Projects Fail - Lalit Maganti", "warc": null, "wget": null }, "link_dir": "/data/archive/1768757156.629201", "newest_archive_date": "2026-01-18T17:26:39.058689+00:00", "num_failures": 0, "num_outputs": 9, "oldest_archive_date": "2026-01-18T17:25:59.608679+00:00", "path": "/post/why-senior-engineers-let-bad-projects-fail/", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01KF928PTEF0C5A6E301XVPDCT", "snapshot_id": "92e0473c-6271-4995-b5ac-bcfa3bbb359a", "sources": [ "/data/sources/1768757155-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1768757156.629201", "title": "Why Senior Engineers Let Bad Projects Fail - Lalit Maganti", "url": "https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/" }