Why Senior Developers Stay Silent About Bad Projects

When I was still a junior, my manager would sometimes share his frustrations during our weekly one-on-ones. He'd point at a project another team was working on and say: "I don't believe this project will achieve any success. They're solving the wrong problem." I'd respond with curiosity: "But you're senior — why not just go talk to them?" It seemed strange to me that someone with the ability to influence a situation would choose to stay silent.

And the irony didn't spare me. Last week, I caught myself telling a newcomer why the neighboring team would have to fundamentally rework their project because they'd gone down the wrong path from the start. And he rightfully asked me the same question I'd asked many years ago: "Why don't you just share your opinion with them?" Since then, this situation has been stuck in my head, because I realized that over the years my position on this matter has changed.

The Answer: Being Right and Being Effective Are Different Things

Large companies encourage voicing doubts about what seems like a "bad project." But only in soft form. Sometimes a sign of seniority and experience is understanding that arguing with people who won't listen anyway isn't worth it, and it's better to keep your opinion to yourself.

Bad Projects

By "bad project" I mean many different aspects:

• UX: overcomplicating the product, solving a nonexistent problem, breaking current workflows.
• Technical: unnecessarily complex design, wrong library choice, weak architecture.
• Political: chasing the Gartner hype curve — exists mainly to justify a promotion.

It's important to note that for most of a project's lifecycle, assessing how "bad" it is will be highly subjective. Software development involves many compromises and making the best possible decisions given available information. There are often disagreements about the correctness of various choices, and truly right options only become obvious much later — or even years after the project ships.

But as you grow in your career, you develop an "instinct" and start seeing "unreasonableness" in some projects. It's this instinct that points me toward a "bad project" whose fate I can foresee when others can't yet.

From my personal experience, the most memorable example happened a couple of years ago at Google. During a meeting, there was a grand announcement about a "breakthrough" project being developed at the intersection of two very large organizations. It all sounded very elegant and technically thoughtful. The project was full of clever solutions to genuinely serious problems.

But I distinctly remember sitting in the conference room, turning to my lead, and whispering: "But this is a doomed project, right?" And he turned back and said: "Yes." We both immediately understood the problem. The project was entirely predicated on the platform development team asking the core product team to hand over control of the User Flow. Technically the right call, but no lead or project manager would ever surrender control of something so fundamental to another team. Politically, this project was pure fantasy.

In the end, it limped along in the background for nearly two years. Every time a launch date approached, it was held back as "not yet ready." Over time, we heard about it less and less, until eventually an email landed in my inbox about a "strategic pivot." The project's resources were reallocated and the code was deleted. We were told the company "learned a lot from the experience." But to me, its doom was obvious from the very beginning. Politics and solving the right problems are no less important than technical elegance.

Why You Can't Stop Them All

When I started noticing "bad projects" and felt I had useful experience to offer, I was itching to help. I wanted to approach the team and say: "This is unreasonable" and explain why, using logical arguments.

And I tried. But only very briefly, until I realized this carries a number of problems.

First, software companies are inherently biased toward speed. They value the pace of writing and shipping software. Any doubts only slow things down and mean analyzing aspects that weren't budgeted for. So people will only listen when the concerns raised prove truly important. In practice, you'll almost certainly just be ignored.

And even if the team takes your comments seriously, you shouldn't do it often. One or two times, you might be perceived as someone advocating for "quality." But if you start offering advice too frequently, you'll quickly become a "negative person" who constantly creates problems rather than solving them. You'll rarely get credit for disasters prevented — since nothing bad happened, people quickly forget.

Another problem is that every time you slow down a project, you're potentially harming someone's promotion, or it turns out to be some VP's pet project. You end up risking burning useful bridges and making "enemies," at least in some sense. Having a few people in the company who disagree with you is natural; when there are too many, it starts hurting your core work.

Finally, there's a psychological aspect. The company has hundreds of engineers working in areas where your experience might be useful. But you're just one person, and your attention is limited. Meanwhile, a large company's capacity to generate bad ideas is infinite. From my experience, excessive striving to fix everything everywhere will quickly make you very cynical about the world around you. And you definitely won't like that world.

Manage Your Influence Like a Bank Account

So if you can't stop all these bad projects, what should you do? Act strategically. Instead of trying to fix everything, treat your influence as a bank account. You have a certain amount of "influence" that you earn each month by doing your job, helping others, shipping successful projects, and not causing unnecessary friction.

When it truly matters, you need to be ready to make a "withdrawal." Every time you slow something down or express doubts, you're writing a check against your balance, no matter how small it seems. And checks come in different sizes:

• $5 check: a nitpick in code review. Cheap, daily expense.
• $500 check: an objection about an architectural decision or project timeline. Requires accumulated resources.
• $50,000 check: going after a VP's pet project. A massive expense you can afford no more than once every couple of years.

The problem arises when you spend $5 on every minor flaw you encounter. If you're constantly saying "no" to small things, then by the time you need to write a serious check to stop a real catastrophe, your account will be empty.

If you go into the negative, you'll find yourself in political bankruptcy. People will stop inviting you to meetings, stop asking your opinion. Essentially, they'll start going around you. When you're bankrupt, your influence drops to zero. At that point, not only can't you influence what's happening — you'll struggle to accomplish your own tasks.

When to Spend Influence

So we agree we can't influence everything, and now we need to understand when it even makes sense to try.

First and foremost — be restrained and always assess whether you actually have enough experience to be giving advice. Experienced specialists often have opinions. But those opinions aren't always built on solid enough ground. For example, while I have some frontend experience, I don't feel expert enough to give deep advice on the topic. My knowledge is just enough to handle my own tasks and move on, but I don't possess the deep wisdom that comes from long-term product management. It's easy to overlook the fact that for a quality assessment, your opinion must be grounded in clear understanding of context. If you find yourself in this situation, view yourself as a biased observer and stop.

You also need to understand that your words aren't necessarily truth. You're expressing an opinion, not issuing a decree. So if a team doesn't listen to your comments and decides to keep going their direction, you need to simply accept it. After all, you're an engineer, not a director with authority over them.

Given all these nuances, before voicing my opinion, I answer three questions:

• How close is this project to my team?
• If problems arise, how severely will my team be affected?
• If problems arise, how much organizational damage will it cause?

Proximity. If the project is close to your work, the "cost" of objecting drops. If it's within your own team, the cost approaches zero — you have high trust, and a short conversation is often enough. If the project belongs to distant parts of the organization, the cost rises. You'll need to spend social capital and potentially put your reputation at risk. And if it involves a completely different organization? Often the costs are simply too high. You have no leverage and must work through other chains of command, so stopping the process requires enormous expenditure of savings.

Impact on your team. Sometimes another organization's actions deeply affect your work. For example, since Perfetto (the performance evaluation tool I work on) is used across different divisions at Google, sometimes a team asks us to approve a planned complex integration. Here a classic risk emerges. If everything goes smoothly, they get their benefit, but if something goes wrong, your leadership might pin the cleanup on you for problems you didn't create. In such cases, speaking up is very important because you're protecting your team.

Company-wide impact. Finally, consider the project's blast radius. Some projects are self-contained. If they break, they don't drag anything down with them. But some are so deeply woven into internal systems that their failure causes extensive damage or creates technical debt that persists for years. Those can be lethal for your own project's long-term health.

How to Act Regarding Bad Projects

It's also important to understand not just when to speak up, but how. There are many possible actions depending on the observed problem.

When You Intervene

The hardest option is to directly say "don't do this" and try to stop the project. This almost always requires notifying the leaders of both your team and the team implementing the project in question. You'll need to present convincing arguments defending your case and explain that the project will cause real harm. But in some cases, this is the right choice — especially if the consequence of silence could fundamentally impact your own project or team.

A slightly softer but still risky option is to express your concerns directly to the team. Usually this happens in a meeting or as a clearly formulated document with "concerns" or "objections." The goal is to express your thought convincingly enough that the team can reach the conclusion on their own that this project isn't such a great idea.

An even gentler form of intervention is nudging the project in the right direction. This works great when a team plans to implement something reasonable but approaches it incorrectly. I often see this in Perfetto. A team sends a design doc proposing complex usage of the tool that I immediately see will cause them pain down the road. I gather their specialists, understand the problem, and guide them toward a more effective solution. I spend an hour now but save them months later. Done correctly, you're perceived as a helper, not an obstacle, even if you slow the project down.

When You Don't Intervene

Sometimes you realize the potential payoff doesn't justify direct intervention — the political aspect is too strong, or the problem is too small. In that case, your actions depend on how much it concerns your team.

If the problematic project significantly overlaps with your work, it may be wise to implement a contingency plan — reduce dependency on that project or create abstractions for protection in case it fails. You can also play the long game here. Even a bad project usually contains a good idea at its core — a specific problem it aims to solve, or some insight it was based on. If that idea aligns with your work, the right move is often to build a better version of it into your own project. That way, if the bad project stalls or gets cancelled, you'll be acting preemptively rather than scrambling to deal with sudden fallout.

If the problematic project doesn't affect your work at all — just don't get involved. You can share with close colleagues privately, express sympathy, but in the public sphere, accept reality.

Working Through It With Your Team

Finally, you also need to work through this with your team. If you see flaws in a project, other senior developers likely see them too. Don't try to gaslight them or "follow the company line," pretending that a bad project is actually good. That behavior destroys trust.

Instead, be honest about the obvious facts without diving into political details. Tell your colleagues that you'll do your best within these constraints.

Conclusion

So what did I tell my junior mentee?

"With experience, I've learned that being right and being effective are different things. I could absolutely go tell them about my concerns. But they almost certainly won't listen, and I'll just spend some of my reputation. And in six months, nobody will remember that I warned them. People will only remember that I tried to slow down their work."

When you're just starting your career, you want to believe that good ideas deserve recognition, that if you just explain everything well, people will understand. And it took me quite a while to realize — in large companies, it doesn't work that way.

But this doesn't mean you should just give up. It only means you should spend your reputation points strategically. Choose battles where you can actually influence the outcome; where your team will be at risk if you stay silent; when the cost of your mistake is low but the cost of project failure is enormous.

And in all other cases? Just share with colleagues, build contingency plans, and observe. Sometimes you learn something. Sometimes you're wrong and the project actually succeeds. And sometimes you get that grim sense of satisfaction from having foreseen its collapse.

None of this brings the satisfaction that fixing all mistakes would. But this approach works and lets me keep my sanity.