People don't know how to talk to each other: how to have technical discussions

One brain is not enough. We need a whole team to find the right solution if we want to build things well. But the process of finding the right solution is difficult because people don’t know how to talk to each other. A discussion about how to implement something, or how to model the problem devolves into a screaming match. Or worse: radio silence on Slack with a team member who is on the opposite coast.

It is unfortunately the worst when both people care about what they are building. Because in both parties’ heads, they want what’s best for the project. And they don’t understand why the other person opposes their view. Stalemate. Nothing gets done. And there is a terrible tense feeling in the team.

Over the years, I’ve made all kinds of blunders when trying to drive technical discussion. However, I’ve gotten better! I’m not perfect yet, but my blunder-rate has decreased significantly. This is what I’ve learned about talking to other people.

1. There is no perfect solution

The first fundamental is that there is no perfect solution. Each solution has its own set of tradeoffs. You may see your solution as the one that is optimal, but this is only because you have not thought about it hard enough. People fall into the trap of finding the perfect “technical” solution. But the perfect solution with respect to the tech side of things may not be what the business needs. Maybe it takes too much time to implement. Or it requires multiple other components to be redesigned. Maybe a hacky solution is ok for now (and maybe forever) because there are other important discussions to be had and decisions to be made.

2. You are not your idea

You must separate yourself from your idea. People defend their ideas very rigorously because their idea is their avatar. It’s self-preservation. Your objective is not to defend your idea. Your objective is to work with your team to arrive at the correct solution. If your solution is the one that is picked from the pool of ideas - give yourself a pat on the back. But if it isn’t, give your teammate props. A healthy team is egoless.

One way to avoid being defensive about your idea is to try to come up with multiple differing ideas. This helps you to understand the range of possibilities that you may have as a solution, to understand the weaknesses of your first idea. And this also gives your teammates a wonderful thing called choice! When an idea is presented as the only way forward, it becomes hard to disagree with. It becomes you vs your teammates. When in reality it should be the ideas vs each other.

3. People are not reading your slack essay

So now that you have your set of ideas, what should you do with them? One thing that you shouldn’t do (in most cases) is to write a Slack essay about your ideas. I’ve seen and written many of these in my time at work. Avoid them. There is nothing more daunting to your teammates than seeing a wall of text (no matter how many smiling emojis you include). Most likely, they will not bother reading it. If they do, the ensuing Slack thread debate is only going to make things worse.

What works better is to “soft-launch” your ideas as early as possible. Bring it up in a team discussion, ask people what they think about the problem, and see if the solutions that you’re thinking of make sense to them. You’re trying to get their buy-in and co-develop a solution from the beginning. Present it as simply as possible. Create simple examples to illustrate your point beautifully. This way, you don’t shock people. People don’t like new things. Especially when they seem big.

4. Listen to others by summarizing what they tell you

Let’s say you have tried to soft-launch your ideas, and now there is a big debate anyway. Maybe there is no clear winner from the solutions that you’ve proposed. What can you do to facilitate a productive discussion?

This is actually advice that I’ve heard marriage counselors give out: when you’re having an argument, before you say your point, you have to summarize the other person’s perspective and they must agree that you have summarized their point correctly. All you have to say is “Just to check that I understand your perspective correctly, …” and then state their point of view to the best of your abilities.

This ensures that there is no information loss. You may not fully understand the other person’s perspective, and in the process of summarization, you realize that you don’t fully understand them. This puts both people on the same page so that the conversation becomes productive, instead of just you two talking over each other.

It also ensures that both parties feel heard. If either party feels that they are not being heard, that they are not being taken seriously, this damages the working relationship. This can put them off from collaborating closely with you in the future. Losing a whole collaborator over one technical decision does not feel like a tradeoff ever worth making.

5. Give people time to think about it

Finally, let’s say you had your discussion and it seems that you haven’t arrived at a clear answer as a team. What should you do in this case? You give people time to think about it. You say: “It doesn’t seem that we’ve arrived at a clear conclusion yet. Let’s mull it over and come back to it in a bit.” Many times, all people need is the time to think a little bit more about it. They may come to the same conclusion as you. Or maybe you adopt their perspective. Maybe you’re not as smart as you thought you were.

6. Be genuine throughout it all

It’s important to be genuine in all parts of this process. When you are trying to drive technical discussion, trying to convince people of your ideas, it’s important that you treat it sincerely as a process for discovering the right solution. Agree with others when they make a good point. If you are not genuine and pretend to listen to others while planning to stick to your first solution - YOUR idea - the whole time, people will eventually find out. People don’t like working with those who have their own hidden agenda. They might go with your solution this time. They might go with your solution the next ten times. But they will quietly but surely stop collaborating with you.

Conclusion

I have made all of these mistakes before, and I will make the same mistakes in the future. The only thing that has changed is how often I make these mistakes. By outlining what has worked for me, I hope the next technical discussion you have is just a tiny bit more productive.