This article explains why senior engineers don't hastily intervene in projects they judge to be poor, instead taking a strategic approach. Rather than speaking up just because they're right, they use their influence wisely to produce effective results, considering the impact on their team and company when deciding when and how to engage.

1. The Difference Between Being Right and Being Effective

As a junior engineer, the author wondered why senior managers who knew a project's problems didn't speak up directly. But becoming a senior engineer himself, he received the same question from mentees and realized that "being right and being effective are different things." In large companies, speaking up about bad projects is good, but overdoing it can backfire. Sometimes withholding advice from people who won't listen is the wiser choice.

2. What Is a 'Bad Project'?

Bad projects come in many forms: UX problems (making products complex, solving nonexistent problems), technical problems (overly complex designs, wrong libraries, poor architecture), and political problems (trend-chasing, projects that exist mainly to justify promotions). The author shares an example from Google -- a technically brilliant but politically doomed project that quietly ran for nearly two years before being "strategically pivoted" and its code deleted.

3. Why You Can't Block Every Project

Direct intervention carries significant costs: action bias in software companies means concerns that slow projects down get ignored; frequent objections get you labeled as "the negative person"; each pushback risks damaging relationships; and trying to stop every bad idea leads to excessive cynicism.

4. Managing Influence Like a Bank Account

Think of your influence as a bank account. You build deposits by doing good work, helping people, and completing successful projects. Every objection is a withdrawal:

• $5 checks: Minor code review comments. Cheap and daily.
• $500 checks: Challenging architecture decisions or deadlines. Requires savings.
• $50,000 checks: Trying to block a VP's pet project. Enormous expense, perhaps once every few years.

If you keep writing small checks for every inefficiency, you'll have nothing left when you need to prevent a real disaster. Going bankrupt means people stop inviting you to meetings, stop asking your opinion, and start working around you.

5. When to Use Your Influence

Three key factors determine when to speak up:

1. How close is the project to my team? Within your team, the cost is near zero. Within the broader org, it's higher. Outside your organization, it's often unaffordable.
2. How much does it affect my team if things go wrong? When another team's project could cause your leadership to hold you accountable, speaking up to protect your team is critical.
3. How big a problem for the whole company? Some projects fail in isolation; others are so entangled with core systems that failure creates widespread damage or years of tech debt.

6. How to Deal with Bad Projects

When to Intervene

• Direct stop request (last resort): Escalate to leadership. Only when your project or team's survival is at stake.
• Raise concerns with the team: A softer approach through meetings or strong "concern" documents, aiming for the team to conclude on their own that the project might not be a good idea.
• Micro-steer toward the right direction (low cost, high ROI): Sit with the team, understand the real problem, and guide toward a better solution. One hour can save months.

When Not to Intervene

• High overlap with your team's work: Build subtle contingency plans -- reduce dependency on the project, build abstractions for if it gets canceled, or extract the kernel of good ideas and integrate them into your own work.
• No overlap: Simply don't engage. Commiserate privately with colleagues, accept reality publicly, and move on.

Managing Your Team

If you can see a project's flaws, other senior engineers can too. Don't gaslight your team by pretending the project is fine. Be honest about the situation without unnecessary political details, and assure them you'll do the best you can within these constraints.

Conclusion

"I've learned that being right and being effective are different things. I could tell them my concerns. They probably won't listen. I'll burn some goodwill. And in six months, no one will remember I called it. They'll just remember I was the person who tried to get in their way."

Choose battles where you can actually change the outcome, where silence would hurt your team, where the risk of being wrong is low but the risk of project failure is high. For everything else -- commiserate with colleagues, quietly build contingency plans, and watch. Sometimes you learn, sometimes you're wrong and the project succeeds, and sometimes you feel the cold satisfaction of having predicted exactly how things would fall apart. It won't feel as good as fixing everything. But it's what's effective, and it will preserve your sanity.