You’ve probably been in this meeting. Two engineers are debating a solution. Someone says “that won’t work” without explaining why. The other person goes quiet. Things feel tense, but everyone’s trying to solve the same problem.
After years of software development and working with many different people, the main thing I’ve learned is technical excellence means nothing if we can’t talk to each other.
Why team communication matters
You can write pristine code, architect beautiful systems, and ship features on time. But if your teams can’t communicate with patience and honesty, those wins are temporary. Codebases become battlegrounds. Decisions are revisited endlessly. Good engineers leave.
Working on platform teams has taught me that the strongest technical foundation is built on trust, and trust is built on how we talk to each other when things get complicated.
The gap between goals and solutions
In software, there are a lot of ways to achieve the same goals. That’s when we see the most conflict. Everyone wants to provide a solution. The problem is each team member identifies a different issue to solve.
We’ve found the most productive path is to first agree what the problem is. Ask your team these questions:
- What are we trying to achieve?
- What constraints do we have?
- How does your approach get us there?
Everyone has different backgrounds and experiences. While you may be confident about your approach, a coworker may have a solution you never considered. It’s easy to dismiss something new, but that solution could be the one that works best to solve your problem.
The context gap
Most heated technical discussions have a turning point. It’s usually when someone says: “Oh, I didn’t realize we were dealing with [legacy constraint/requirement/deadline].”
By then, you’ve already spent energy on misaligned arguments.
In most cases, people won’t volunteer that they don’t know. They keep critical context to themselves because they don’t want to come across as uninformed. I’ve certainly done this in the past. You’ve probably done it too.
It’s not a competition
One of the most toxic patterns in engineering discussions is treating them like debates to be won. This mindset poisons everything. It turns what should be a shared problem-solving exercise into a contest between teammates.
It shouldn’t be us vs. us. It should be us vs. the problem.
The truth is you succeed when the team ships the best solution, regardless of who suggested it. The end user doesn’t know or care who made the decision. They care that it works.
I’ve seen engineers dig in their heels in on a solution not because they believe it’s superior, but because backing down feels like admitting defeat. You propose something and teammates question it. Suddenly you’re defending it harder than you originally believed in it because changing your mind feels like losing face. In that moment, you’ve stopped fighting the problem and started fighting your teammates.
When this happens, the goal shifts from finding the right answer to being right. You stop listening for better ideas and start listening for weaknesses in other people’s proposals. You anchor to your first instinct and miss signals that a different path might work better. The problem sits there, unsolved, while everyone argues about who’s solving it.
If technical discussions feel like battles, people opt out. It creates an environment where the team loses access to perspectives that could have led to more productive solutions. The only thing that should feel challenging is the problem itself, not the people trying to solve it with you.
Communication best practices that have worked for our team
Building better communication in a team starts with aligning on the nature of the problem. Here are a few best practices that can foster collaboration to discuss and implement solutions:
Set context for everyone
If you’re leading a discussion, ensure everyone in the room is caught up. Even if it feels redundant, if one person indicates they need clarification, they may also have a great solution.
If you’re a participant, instead of making assumptions about shared context, don’t be afraid to ask:
- “Is there context I’m missing?”
- “What solutions have we already tried?”
- “How do other companies handle this?”
- “When did this problem start?”
These aren’t delaying tactics. They may uncover insights that may lead to better outcomes.
Avoid making assumptions
Two dangerous assumptions live in every technical conversation:
“They obviously know X.” They might not. Ensure everyone is properly informed before diving deep.
“They obviously don’t know X.” They might. Clarify the knowledge the audience has.
Both assumptions waste time. Both create resentment. You can easily avoid them.
Practice active listening
Active listening isn’t waiting for your turn to speak. It’s an opportunity to inhabit someone else’s perspective, even when you disagree. Spending time to see the problem from their angle can reinforce or challenge your own perspective. Maybe they’re missing context and need more information. Or maybe their idea is the better choice. You’ll only know by actively listening.
If you’re in a virtual meeting, use the raise hand feature if you have a question while someone is speaking. It sounds trivial, but it works. It forces you to hold your thoughts, which encourages you to actually listen to them. You might realize your counterpoint is irrelevant. Or your colleague may address it while you’re waiting to speak.
Acknowledge better ideas when they show up
Acknowledging good points from your teammates is another way to find a solution as a team. When you say, “That’s a really good point about X” or “I hadn’t considered Y,” it shows you’re listening and evaluating ideas.
Be willing to let go of your ideas when a better one comes along
If you put your ideas forward with confidence but set them aside in favor of a better solution, you’re putting the team’s interests above your own. Be open when listening to another suggestion. Ask yourself if it’s potentially better. Maybe you don’t fully understand the proposal and need more clarification.
Saying “You know what, given the constraint you just mentioned, your approach makes more sense” isn’t defeat. It’s what good engineering looks like. You learned something that changed the equation.
Once a decision is made, it doesn’t matter whose idea it was. Your job is to make it work.
Solve together to ship better
Your reputation isn’t built on how often your specific solution is chosen. It’s built on your judgment, your ability to collaborate, and your track record of helping the team ship good work.
People remember the engineer who listens carefully, asks good questions, and helps the team make better decisions. They don’t remember who “won” the architectural discussion three months ago.
The best engineers I’ve worked with hold their ideas loosely and focus on outcomes. They propose approaches with confidence but abandon them without ego when something better emerges. They’re as enthusiastic about implementing someone else’s idea as they are about their own.
Be patient. Ask questions. Listen like you might be wrong. If you are, that’s exactly when you need to understand your colleague’s perspective.
Want to get more insights from our engineering team? Check out these technical deep dives:
