When was the the last time you realized a project was doomed? That time you knew the plug should have been pulled, but you kept things quiet and watched the work painfully fizzle out.
If you care enough about the work, you probably have these feelings often.
Maybe there’s context you’re missing and you’re being too sensitive. Maybe the implementation is fine and you’re being too pessimistic. But—maybe you’re right and you have the opportunity to save the company years of toil and unmeasurable amounts of opportunity loss.
Realistically, you probably can’t affect the situation. Who are you to call off an important project? Who is another person to question your work? Everyone, from managers to executives, has a hard time with this. Nevertheless, your opinion matters; you might be able to nudge the ship and prevent a terrible outcome. At the very least you can try.
Why bother? When is this appropriate? How do you even communicate this?
Why
As a professional, you have the responsibility to voice concerns affecting the success of organization. Stopping what isn’t working is equally important as investing in what’s working.
If not for the sake of the organization, raise the alarm for the sake of yourself. Practice your seniority. Give a proper escalation with measurable impact, all while communicating effectively and respectfully to the right people. Few can do this.
Honestly, it doesn’t matter if you don’t get your preferred outcome; just knowing that you spoke up counts for something.
When
Consider voicing your opinion when stakes are high:
- Large change in architecture
- e.g. Initial steps towards a monolith to microservice migration, first attempt at event sourcing.
- Large change in deployment
- e.g. On-premise to “hybrid” to cloud, back to on-premise, and everything in-between.
- Large change in development
- e.g. Splitting all the repos, merging them all back, adopting a tool, deprecating it later.
If your development environment is distributed and isolated between teams, changes are less likely to have broad impact. However, watch out for situations where you’re working in a highly-shared system. This is when any change easily becomes high-stakes. As with anything, the more people it affects, the more significant it becomes. Here are some other questions to ask:
- Is the project overly ambitious?
- Is the project taking forever?
- Is the lead engineer on the project too defensive?
- Are the goals of the project now irrelevant with respect to the company’s strategy?
If you’re having uneasy feelings, I guarantee that there are other engineers feeling similarly. It’s common for a group of people to question something but to collectively do nothing about it.
If you care enough and the stakes seem high enough, this might be the time to do something.
How
How is the trickiest.
If you’re a senior engineer, who are you to raise the alarm on projects that support the Principal Engineer’s 5-year strategy? High-stakes changes are accompanied by strongly-held opinions. Someone has spent a lot of time thinking about this. If you believe there is a fundamental flaw in this work, things will inevitably get personal. As much as we’d like to believe we are detached from our work, we are not.
99% of the time, you should not attempt a direct approach. It’s unlikely that expressing your concerns in a 30-minute call with that Principal Engineer leads to the company killing a project.
Throughout the process, keep an open mind. You don’t have all the information. You will learn more about the issue as you engage with it. If at any point in the process your worries are assuaged, feel free to stand down. If at any point in the process you feel like your concerns aren’t being properly comprehended, feel free to push on.
Find a Supporter
I recommend the “How” to be indirect. Raise your concerns with someone who is not involved with the project.
The default person is your manager. You need to communicate your concerns clearly and share the reasons why you believe this project will not succeed. It’s important to include an appropriate severity level—what is the actual impact? Too often engineers raise critical issues only to have a follow-up be placed at bottom of their manager’s TODO list.
I believe this {architecture change, adoption of new tool, migration, insert project here} is unlikely to succeed because we {don’t have the right expertise in place, don’t have the right staffing in place, have overlooked a fundamental design issue, insert concern here}. If we continue to pursue this, we may be at risk of {accumulating a significant amount of tech debt, risking a heavy blow to morale, severely destroying our velocity, insert other trigger phrase here}.
You
Communication goes both ways. You need to simultaneously be a good communicator and a good listener. For the managers, pay attention to subdued escalations—do you think the engineer is downplaying the situation to not upset someone? For the engineers, be clear about impact and get your point across—is your manager actually connecting with you on the severity level?
Hopefully, you deliver your concerns effectively and your manager decides to take action. Consider this effort a close collaboration; this is not a baton pass from you to the manager. Use the manager to assist with back-channel alignment at higher levels. Write a concise summary of your concerns (an “asset” if you will) that your manager can reference and disseminate. Work together on how to propose additional accountability for the project at different levels. Figure out a way to get the right people in a room with the right set of expectations.
In the situation where your manager does not perceive your warning to be particularly significant, you may want to take things into your own hands. This will be de-motivating, but if you still care enough to do something—good for you.
Your feelings of unease are shared. Locate others that have similar concerns and consolidate multiple voices into one. This will give your collective opinion more weight. You are now the voice for the group. The nice part about this is that you’ll be more motivated to keep pushing forward knowing others are with you.
With a stronger signal in hand, find an objective third party, as senior as possible, and have the same conversation as you tried to have with your manager. For example, approach a Principal Engineer who has nothing to do with the project and get their thoughts. The goal here is to connect with as much seniority as possible, convincing them that they need to care about this.
If the third party engages with you, use your discretion to get a feel for how they’d like to follow up. Are they taking things seriously and willing to follow up without you? Are they mildly interested and want to get more data points? Are they not interested whatsoever? You may need to approach multiple people. Most of the time, an objective third party doesn’t have a stake with your personal concerns because it’s not their job to worry about your concerns (like your manager’s is).
Whether or not it’s your manager or a random Principal Engineer, your goal here is to have multiple people care about this as you do. If you’re actually able to do this (the hard part), subsequent pieces will flow naturally.
The Outcomes
The good outcome is impossible to measure. If you escalated an issue and stopped a doomed project, you will never know how much potential time and money you saved.
The bad outcome is when you do nothing and the project continues. The work causes years of pain until finally an executive pulls the plug and you were proven right. In these situations, do not give a “I Told You So” speech.
The probable outcome is that you raise your concerns, but the project continues and eventually fails. Upon failure, your contribution may or may not be retroactively recognized. The unfortunate (but still positive) outcome is that you and the organization learn from the experience.
What is actually important?
The actual organizational outcome is not that important. You will rarely succeed at “raising the alarm” and stopping a project. Companies learn the hard way through wasted time and excessive tech debt.
What is actually important is the action you took.
The act of maturely and professionally raising a concern is what’s important. You practice your seniority by aligning the right people, communicating impact, and getting your opinions out there.
If you are able to do this—or even just make an attempt at it—then consider this whole effort a win.
What is actually hard?
The hard part in this whole process will be that you’re going up against another person. It will take courage to raise your concerns and in doing so you will inevitably upset people. Very few can truly detach from their work. This includes you as well; you will need maturity to concede when things don’t work out your way.
If you care, you can at least try.
Either way, you should not be attached to the outcome.