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, “I don’t believe that project will go anywhere, they’re solving the wrong problem.” I used to wonder, “But you are very senior, why don’t you just go and speak to them about your concerns?” It felt like a waste of his influence to not say anything.
So it’s quite ironic that I found myself last week explaining to a mentee why I thought a sister team’s project would have to pivot because they’d made a poor early design choice. And he rightfully asked me the same question I had years ago: “why don’t you just tell them your opinion?” It’s been on my mind ever since because I realized I’d 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 “bad project” is a good thing. But only in moderation. Sometimes the mark of seniority is realizing that arguing with people who won’t listen isn’t worth it; it’s better to save your counsel.
Bad projects
What I mean by a “bad project” is many things:
- UX: making product complicated, solving a problem which doesn’t exist, breaking existing workflows
- Technical: overcomplicated design, wrong library, poor performing architecture
- Political: chasing hype cycles, exists primarily to justify a promotion
It’s important to point out that for much of the lifecycle of a project, whether it’s “bad” 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’ll start to have “taste” when it comes to software projects and that will cause you to look at some fraction of the software projects and feel “this doesn’t make sense”. And this gut feeling is the sign to me of a “bad project”, one which you can see in advance of when it’s 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 “game changer” 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, “This project has no chance of succeeding, right?” He turned to me and just said, “Yup.” 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 “not ready yet.” Over time, we heard less and less about it until, eventually, the inevitable “strategic pivot” email appeared in my inbox. Resources were reallocated and the code was deleted. We were told the company “learned a lot from the effort,” 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 “bad projects” 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 “this doesn’t make sense” 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’t 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’t budgeted for. And so unless your concern is big enough to overcome the “push for landing”, there’s little chance for any meaningful change to come from you saying something. In fact, it’s very likely that you’ll 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 “quality”. But do it too often and you quickly move to being seen as a “negative person”, someone who is constantly a problem maker, not a problem “fixer”. You rarely get credit for the disasters you prevented. Because nothing happened, people forget about it quickly.
There’s also the problem that every time you push back, you are potentially harming someone’s promotion packet or a VP’s “pet project.” You are at risk of burning bridges and creating “enemies”, 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 “influence” 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 “withdrawals.” 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’s 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 “no” to small things, your account will be empty when you need to write the big check to stop a true disaster.
If you “go overdrawn,” 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’ve 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 “enough to get by” 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’t 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’re 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 “price tag” 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’t 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’s also not just about when you put your opinions forward but how you do it. There’s a very wide range of actions you can take depending on what you’re facing.
When you intervene
The nuclear option is to directly say “we should not do this” 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’re 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 “concern” or “rebuttal” 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’t
Sometimes you conclude that the ROI just isn’t 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’s 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 “essence” 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’s 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’re not involved, it’s 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’t try to gaslight them or “walk the company line” 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? “I’ve learned that being right and being effective are different things. I could go tell them my concerns. They probably wouldn’t listen. I’d burn some goodwill. And in six months, nobody will remember that I called it, they’ll just remember I was the guy who tried to block their work”.
When you’re 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’t work that way.
But this doesn’t 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’re 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.