This piece explains why senior engineers don't rush to intervene when they judge a project to be flawed, and instead take a strategic approach. It emphasizes that speaking up just because you're right isn't always the move — what matters is using your influence wisely to drive effective outcomes, and deciding when and how to step in based on the ripple effects it will have on your team and company.

1. Being Right vs. Being Effective

Early in one's career, it's natural to wonder why a senior manager who clearly sees a project's problems doesn't just say something. But as the author became a senior engineer and started receiving the same question from mentees, they came to realize that being right and being effective are different things. In large organizations, speaking up about a "bad project" can be valuable — but too much of it backfires. Sometimes the wiser senior move is to hold back advice rather than argue with people who aren't going to listen.

2. What Is a "Bad Project"?

The author describes "bad projects" as taking many forms:

• UX perspective: Makes the product more complicated, solves a problem that doesn't exist, or disrupts existing workflows
• Technical perspective: Overly complex design, wrong library choices, poorly performing architecture
• Political perspective: Chasing trends, or a project that exists primarily to justify someone's promotion

Whether a project is "bad" can be highly subjective over its lifecycle, since software engineering is a trade-off game of making the best decisions with available information. But as you become more senior, you develop an intuition — a gut sense that "this doesn't add up" — and that instinct is often a signal that you've spotted a bad project before it becomes obvious to everyone else.

The author shares an experience from Google involving a project that was technically impressive but politically doomed from the start. It sat at the intersection of two large organizations and was full of technically sophisticated, clever ideas — but structurally, it was asking one platform team to get a core product team to relinquish control over a key user flow. The author whispered to a leader at the time, "This project has no chance of succeeding, does it?" The leader replied, "Nope." Everyone knew that no leader or PM would willingly hand over ownership of something core to another team. The project quietly dragged on for nearly two years before dying with a "strategic pivot" email — resources reallocated, code deleted. That experience taught the author that political fit and solving the right problem matter just as much as technical elegance.

3. Why You Can't Stop Every Bad Project

When you spot a bad project and want to share your expertise, the first instinct might be to step in and call out the problem directly. But the author came to understand that direct intervention carries real costs.

3.1. The Cost of Intervening

• Bias toward action and speed: Software companies have a strong action bias and place enormous value on speed and shipping. Concerns slow projects down, so unless your concern is compelling enough to override launch momentum, it's likely to be ignored.
• Being labeled "the negative person": Once or twice you might be seen as someone who upholds quality. But raise issues too often and you become "the person who always causes problems." You rarely get credit for disasters you prevented — because nothing happened, people forget quickly.
• Damaged relationships: Every objection risks hurting someone's promotion or a VP's pet project. That can sever connections and create enemies.
• Mental exhaustion: There are countless projects and engineers in the world where your expertise could genuinely help. Trying to stop every bad idea risks making you excessively cynical — and that's not a healthy place to be.

4. Managing Influence Like a Bank Account

If you can't stop every bad project, what do you do? You take a strategic approach. Think of your influence as a bank account. Every month, you make deposits by doing good work, helping people, and delivering successful projects.

And when it matters, you need to be ready to make a withdrawal. Every time you object to something or raise a concern, you're writing a check against that balance. But not every check is the same size:

• $5 check: A minor nit in a code review. Cheap — an everyday cost.
• $500 check: Challenging an architecture decision or pushing back on a deadline. Requires some savings.
• $50,000 check: Trying to block a VP's pet project. Enormous expenditure — something you might only afford once every few years.

If you keep writing $5 checks for every minor inefficiency, your balance will be empty when you need to write a big one to prevent a real disaster. When you run out, you hit political bankruptcy. People stop inviting you to meetings, stop asking your opinion, and start working around you. Once bankrupt, your influence drops to zero — which hurts not just your ability to have impact, but your ability to get things done at all.

5. When Should You Use Your Influence?

Once you accept that you can't intervene in everything, you need to figure out when it's actually wise to do so.

5.1. Humbly Assess Your Expertise

The first thing to do is honestly ask whether you have the expertise to make the judgment call. Seniors often have a lot of opinions, but those opinions aren't always well-informed. For example, even if you have some frontend experience, if you don't have deep expertise there, it may not be your place to offer deep advice.

5.2. Acknowledge the Limits of Your Perspective

You also have to accept that what you say is not the same as the truth. You're raising awareness of a particular perspective, not issuing commands. So if a team hears your concern and proceeds anyway, you need to accept that and move on. You're an engineer, not a CEO with authority over everything.

With those points in mind, the author offers three key factors for deciding when to speak up:

1. How close is the project to my team?

   • If the project is within your own team, the cost is nearly zero. High trust means a quick conversation can resolve things.
   • If it's within the broader organization, you're spending social capital and reputation — costs go up.
   • If it's outside your organization, the cost is often prohibitive. You have little leverage, a different reporting chain, and stopping the project would consume enormous influence.

2. How much will my team be affected if things go wrong?

   • This comes into play when another organization's project could seriously impact your team's work. For example, with Perfetto (the performance tooling the author works on), if another team requests a complex integration and things go wrong, your leadership may be held accountable. In those cases, speaking up to protect your team is critical.

3. How much damage will it do to the company if things go wrong?

   • Some projects are self-contained — if they fail, the fallout stays contained. But some are so entangled with core systems that failure causes widespread damage or years of technical debt. Those can be catastrophic for the company's long-term health.

6. How to Handle Bad Projects

Not just when to speak up, but how — that matters too. You have several options depending on the situation.

6.1. When You Do Intervene

• Directly requesting a stop (last resort): Explicitly saying "this should not happen" and attempting to halt the project. This almost always means escalating to your leader and the other team's leader, and requires strong conviction that you're right and that the project will genuinely cause harm. But if the project threatens your team's work or existence, this is the right call.
• Raising concerns with the team (softer but still risky): Instead of direct escalation, you hold a meeting with the team or write a forceful "concern" or "counter" document. The goal is to push hard enough that the team itself starts to question whether this is a good idea.
• Nudging in the right direction (low cost, high ROI): Best for projects that are sound at a high level but poorly executed. For example, when a team approaches Perfetto with a complex usage proposal, the author sits down with them, understands the actual problem, and guides them toward a better solution. One hour can save months of wasted work — and you're seen as an enabler, not a blocker.

6.2. When You Don't Intervene

Sometimes there's no ROI in taking direct action — the political momentum is too strong, or the problem isn't significant enough to spend your influence on. In those cases, what you do depends on how involved your team is.

• When it overlaps significantly with your team's work: Build a quiet contingency plan. Reduce dependencies on the project or build abstractions that protect you if it gets cancelled. Also, even bad projects sometimes contain a kernel of a good idea. If it's relevant to your work, extract that essence and integrate a better version of it into your own project naturally. That way, if the bad project gets killed, you're responding proactively rather than reactively.
• When it's unrelated to your team: Easy. Just don't get involved. Commiserate privately with close colleagues, but publicly — accept reality and move on.

6.3. Managing Your Team

Finally, you need to manage your team well as they live through a bad project. If you can see the flaws, other senior engineers can too. Don't gaslight your team by pretending the project is great or just "following company policy." You'll lose their trust.

Instead, be honest about the situation without sharing unnecessary political details. And let them know that despite the constraints, you'll do your best.

Conclusion

The author's words to a mentee:

"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 lose a bit of goodwill. And six months from now, no one will remember that I predicted this. They'll just remember me as the person who tried to get in the way of their work."

Early in a career, it's easy to believe good ideas win on merit — that if you explain something clearly, people will think rationally. But accepting that large organizations don't work that way can take a long time.

That doesn't mean you stop caring. It means strategically choosing when to spend your credibility. Pick 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: vent to colleagues, quietly build contingency plans, and watch what happens. Sometimes you learn something. Sometimes you're wrong and the project actually succeeds. And sometimes you get the cold satisfaction of having predicted exactly how things would fall apart.

None of that will feel as satisfying as fixing everything. But it's the effective approach — and it'll protect your sanity. 😌