Beyond ‘This Sucks’: A Smarter Approach to Challenging Tech Decisions

When engineers say “The tech stack adopted in my team is wrong,” what they usually mean is, “The tech stack in my team is not the one I would choose.” This, in turn, often means, “I don’t understand what problems engineers tried to solve when they chose that tech stack,” which ultimately boils down to, “My teammates and I cannot read each other’s minds.”

To resolve such a conflict, you have two solutions:
1. Learn how to read each other’s minds.
2. Learn how to communicate your vision.

While the first one is cooler, in this post, I’ll share my thoughts on how to improve communication in your team. As an Engineering Manager at Tide, I’ve seen how poor communication around technical disagreements can lead to frustration, stagnation, or even silos. This post is based on approaches I’ve found effective in those moments.

Once you have an idea for improvement, you may want to immediately schedule a call with the team or send an email with your proposition. However, improvising such conversations will unlikely bring you the results you want. Instead, follow these six steps:

1. Shape Your Vision — Clearly define what you think is wrong and why.
2. Check with Your Buddies — Validate your thoughts with trusted colleagues.
3. Consider Alternatives — Explore multiple solutions rather than advocating just one.
4. Understand Contexts — Analyze why alternatives exist.
5. Make the Decision — Structure and present your proposal effectively.
6. Accept the Outcome — Handle both acceptance and rejection constructively.

Now, let’s explore each step in detail.

1. Shape Your Vision

There is no better way to bring negativity and ruin the team’s atmosphere than to complain without any concrete propositions for improvement. Over time, this leads to a single senior engineer having to make all the decisions, ignoring the criticism. That’s often how “the tech stack is wrong” situations arise.

Before expressing any disagreement, make sure you fully understand your vision. I recommend writing a draft document that starts with “I don’t like X because…” Your answer doesn’t have to be perfect, but it should be solid enough that it doesn’t sound silly when you read it back.

At this stage, the document might only contain a single sentence, but if you believe in it, you are ready for the next step.

2. Check with Your Buddies

Before bringing a disagreement to the entire team, talk to colleagues you trust. If you say, “I believe X forces us to write too much boilerplate code,” and someone responds, “Nah, it’s there for a reason,” that doesn’t automatically mean you are wrong. That just means there is something you don’t know, maybe a historical context or best practices you don’t fully understand. Learn from your colleagues.

Having such conversations can help you refine your argument, prepare counterpoints, or even change your mind. You may also find allies who support your perspective when you start the discussion. Having someone to back you up is always better than going in alone.

Ideally, you should hear alternative points of view, so now it’s time to move to the next step and do some homework preparations.

3. Consider Alternatives

Starting a conversation with a negative statement, like “X sucks,” is a losing strategy. “We should migrate to Y” isn’t much better. Instead, rewrite your draft: “We have … problem in our current solution. Here is why we should consider an alternative …, and here are the options…”

By outlining multiple options, you make it easy for everyone to see the trade-offs and considerations. More importantly, this approach forces you to empathize with your opponents and understand their perspectives.

While you’ll be collecting alternatives, you will start understanding different points of view better. Some of them might seem obviously wrong to you, but that’s a false thought. Every solution was created in a specific context, and now your goal is to understand it.

4. Understand Contexts

Try to uncover the root causes that stand behind solutions. The famous “Five Whys” method can help to get into why you might want to prefer this particular variant over the other. A discovery on which state management framework to use might shift to “No framework can solve our problem because the real issue is how we adopted clean architecture.”

For example, you may think, “X framework is a bad choice,” so you likely have a different perspective on what a good choice looks like compared to its author and fans. If you focus only on the disagreement itself, resolution can be difficult. However, by identifying the underlying philosophy you can work towards a good solution.

By asking “why,” you may uncover deeper misalignments, such as whether your team believes in “Always create interfaces for all classes” versus “Only create interfaces when needed.” Fundamental misalignments like this belong in a Team Engineering Strategy document. If you’d like me to write more about this, leave me a comment.

Once you create a document outlining all options, listing pros and cons, and highlighting misalignments, it’s time to make the decision.

5. Making the Decision

Now, you can schedule a call or start an email thread. Bring this document you worked on to the table. Structuring it in the RFC format can help make it more formal and digestible. Share your vision and be open to criticism.

If you have done your homework, the decision process will not take long. However, if the conversation drags on without a decision (don’t confuse with the case when the team rejects your proposition), escalate it to stakeholders.

Escalation isn’t a failure — it prevents endless, exhausting debates where people agree to anything just to move on. Instead of cycling through the same arguments, ensure the decision-making process is well-documented so that everyone can trust it was handled fairly.

6. Accept the Outcome

If your proposition was accepted — great! But don’t let that make you think you are smarter than your colleagues. In the end, every decision was appropriate when it was made.

You won’t win every battle. Sometimes, your proposals will be rejected. That’s fine — it simply means your arguments weren’t compelling enough this time, or that the status quo still serves the team’s needs.

Having the conversation is always better than not having it. Thoughtful discussions drive improvement. If you believe the tech stack in your team is wrong, start by understanding why you think it’s wrong — and then communicate that effectively.

About the author

Oleksandr Leushchenko is a GDE in Flutter and Dart, and a seasoned mobile developer with more than a decade of experience in building cross-platform mobile applications. He is a Senior Staff Engineer in a UK fintech company called Tide where he helps a team of 60+ engineers build an international financial services platform.

Russia started an unfair and cruel war against my country. If you found this article interesting or useful, please, donate to Ukraine’s Armed Forces. I can recommend my friends volunteers — the “Yellow Tape”, you can be 100% sure that the money will support our victory. Thanks in advance to everyone who participated.
Glory to Ukraine! 🇺🇦