Avoiding Stack Fights: How to Make Tech Choices Without Conflict

The Inevitable Technology Debate

One of the great challenges in software engineering is that we are not merely dealing with algorithms and data structures. We are dealing with people who write, maintain, and argue about them. Whether it is a new employee advocating for a technology they used in a previous role, a recently released framework that people are eager to learn, or a tool that simplifies implementation, these conversations are inevitable.

As engineers, our job is to create value with the end goal of generating impact. At the end of the day, it is not always about which tool we use but how we wield it to make a difference.

Technical Decisions Are Not Just About Technology

When evaluating technology stacks, everyone on the team will have an opinion. Each language and framework has its strengths, shaped by experience, preference, and the specific demands of a project. If you are working on a sub second financial technology product, C++ has clear advantages when implemented correctly. But choosing the best tool is not just about performance or efficiency. It is about making decisions that align with business goals, support team productivity, and set the team up for success.

The Emotional Side of Technology Choices

Choosing a technology is not just a technical decision. It is a personal one. Engineers often tie their identities and professional worth to the technologies they have mastered. When someone challenges a preferred stack or suggests moving away from a familiar tool, it can feel like an attack on their expertise or even their identity.

Are they the go to person for a particular technology? Have they invested significant time maintaining the part of the stack you are suggesting replacing? It is important to acknowledge these emotions rather than dismiss them. Conversations about technology choices should be handled with empathy, recognizing that people have invested years honing their skills. Encouraging open discussions where everyone feels heard can prevent resistance and lead to better decisions.

The Buy In Constraint

Years ago, I advocated for moving a middleware stack to Apache Mesos, which at the time was a competitor to Kubernetes, more Borg than Kubernetes back then. I got the middleware stack migrated and mostly working on my own, but it did not get adopted because I had not secured buy in. Along the way, I upset the team, and that was on me.

Later, I successfully pushed for Kubernetes adoption, but this time I approached it from a business and people perspective. The team was involved from the start, and buy in was secured, making implementation far smoother.

On another occasion, I pushed for migrating from a REST based application programming interface to GraphQL but backed down because the team was not comfortable with it and it would have slowed us down. Similarly, while I prefer GRPC for on the wire communication, it complicates troubleshooting and has a steep learning curve for those unfamiliar with serialization.

The lesson is that you cannot force a decision on a team and expect it to succeed. Without buy in, even the best technology is as useful as a Ferrari with no gas. If you reframe the debate in terms of business goals rather than technical specifications, you avoid ego driven arguments.

Key Questions to Ask

There are two sides to every debate, but remember that your customers do not care what framework you use.

1. If customers do not care, neither should you.
2. Technology does not just need to work. It needs to work for the people who build and maintain it.

When evaluating a technology change, ask yourself:

• Will the client notice if we change stacks? Customers do not care about your framework; they care about the experience. If the switch does not impact them, does it really matter? On the other hand, technology needs to work not just for the product but for the engineers who build and maintain it.
• Is there a measurable impact? Any proposed change should have a clear improvement in performance, maintainability, or developer efficiency. If the benefits are abstract or marginal, the cost may not justify the switch.
• Are we solving for speed and adoption? The best technology in the world is worthless if the team resists adopting it. A tool should accelerate development, not slow it down with steep learning curves or complex integration requirements.
• How much integration work is required? A framework change does not just affect code. It ripples through CI/CD pipelines, deployment scripts, monitoring tools, and documentation. Have you considered the hidden costs of updating everything?
• Who else needs to be involved? Technology decisions do not happen in a vacuum. Other teams may depend on your stack. Will this shift create unnecessary overhead across the organization?
• Does the team need to learn a new language or framework? The value of a technology is directly tied to the number of people who can use it effectively. If a change requires extensive training, is the investment worth the return?
• How much additional time will be spent reviewing code? Every major change introduces a period of instability. How much of the team's bandwidth will be consumed by reviewing and troubleshooting issues caused by this transition?
• Is this a reversible or irreversible decision? Some technology choices can be undone with minimal effort, while others are difficult to reverse. Are you making a long-term bet, or can you course-correct later if needed?
• Am I advocating for this change because it is better for the business, or because it validates my own expertise? It is easy to push for something that aligns with personal preferences. Take a step back and ask if the recommendation is objectively the best for the company and the team.

People fear losing status more than they desire gains. A debate over technology is rarely just about the technology itself—it is about identity, expertise, and influence. If people feel safe to debate, they are more likely to accept compromise and focus on the best decision rather than defending their own stance.

Before pushing for a decision, consider:

• Am I seeing my colleague as a person or as an obstacle? It is easy to frame disagreements as a battle to be won, but real progress comes when we view our teammates as partners, not opponents.
• What are their concerns, and how do they align with their experiences? Every engineer has a background that shapes their preferences. Are they resisting change because they do not believe in the technology, or because they have seen similar decisions fail before?
• Have I created space for them to express their reasoning? A decision that feels forced breeds resistance. People are more likely to support a direction if they feel heard and valued in the discussion.
• Am I inviting collaboration or fueling division? The way a discussion is framed matters. Are you rallying support for an idea or creating an us versus them mentality? The former builds alignment; the latter builds resentment.
• Am I advocating for the best outcome, or just reinforcing my own expertise? Sometimes we push for a decision because it affirms what we already know. It takes self-awareness to separate personal validation from what is actually best for the team.
• How would I feel if my preferred technology was being questioned? If the roles were reversed, would I be open to feedback? Would I feel defensive? Empathy goes a long way in making discussions constructive rather than contentious.

The People Factor: Leading with Emotional Intelligence

Approaching these conversations as a neutral mediator, which is easier said than done, helps navigate emotionally charged discussions. When emotions run high, creating psychological safety is crucial. This ensures all parties feel respected and heard.

Start with shared purpose by acknowledging that the goal is to make the best decision for the team and company. Use curiosity to explore differing perspectives rather than shutting them down. When tensions rise, step back and ask whether the conversation is being driven by ego or genuine concern for the product. Encourage open opinions while making it clear that differing viewpoints are not personal attacks.

Creating a Safe Space for Technical Debate

Avoid falling into a collusion cycle, where people seek validation only from those who share their perspective. This reinforces division instead of fostering understanding. Strong teams embrace differing opinions, knowing that healthy debate leads to stronger decisions. Keep discussions focused on problem solving rather than personal validation.

How to Handle Technology Change Proposals

Once all opinions have been heard in an open environment, you have a few options:

1. Reject the suggestion. There is nothing wrong with this if done transparently. However, if the real blocker is a persons discomfort with the new technology, that is a separate performance issue.
2. Offer a proof of concept. Engineers become emotionally invested in what they build. If they analyze all dependencies inside and outside the solution, a proof of concept can be invaluable.
3. Experiment in a controlled setting. Try it in a separate cloud account, Docker container, or virtual machine. Stay away from production data and minimize risk. This forces engineers to uncover dependencies they might not initially see.
4. Schedule the migration properly. Everything has hidden complexity, so it is best to reduce risk early. If you commit to change, ensure it remains a priority when issues arise.
5. Avoid splitting your stack. Running two stacks is like driving a car while building a second one next to it. It creates technical debt and overhead, eventually requiring full migration while maintaining two systems.

Giving People a Chance to Shine

When possible, allowing someone to implement a new stack that benefits the business can be a great technical challenge. Just ensure proper reviews are in place and keep new code in a separate branch until everyone is ready to merge. Even if the attempt does not succeed, the lessons learned are rarely wasted if your organization can afford the risk.

Know Your Audience

Understanding your audience is crucial when advocating for a technology change. If your organization relies heavily on key performance indicators and objectives and key results, have them ready and in context. Consider whether you need to convince only technical colleagues and leadership or also business teams. The approach should be tailored accordingly. Use technical terms when speaking with engineers, but keep them minimal when engaging with project or design teams. If your business teams rely on specific dashboards or reports, frame your proposal in terms of how those would change. When addressing executives, focus on business impact and risk rather than implementation details. Finally, always ask for explicit permission to proceed. Do not assume that posting a large merge request means everyone is informed. Seeking both approval and feedback ensures alignment across the team.

The Bigger Picture: Making Tech Decisions That Work

Technology choices reflect group identity. Engineers are not just picking tools. They are picking identities. When an engineer says, “I think we should use Go,” it is not just a suggestion. It is a declaration of intellectual alignment.

The best decision is not always the most optimal technology. It is often the one with the most advocates, the least friction, and the broadest buy in. Aligning decisions with both the rational and irrational forces that govern human behavior ensures they succeed.