Learning negotiation: Never Split the Difference

Never Split the Difference: Negotiating As If Your Life Depended On It is a book by a former international hostage negotiator for the FBI Chris Voss. What can learn from it in relation to software engineering and startups?


We all have to negotiate in our lives. Whether it’s about future salary, where do you go for lunch with your colleagues, or if the honeymoon is going to be just lying down on a beach in a resort. So we all negotiate one way or the other. But are we doing it right?

Does it work for us and - maybe more importantly - does it work for both sides of the table?

I finished reading my first book on negotiations. One of the pieces of advice found in the book is even in the title: Never Split the Difference. But why? And what else can we find inside?

The book

Here are some of the book chapters and some of their ideas. I am using my examples to translate them.


The new rules

Don’t commit to assumptions and test all assumptions during negotiation. Assuming is not knowing. Do you assume your trial customer is a big and wealthy company? What if in reality they just had a bad quarter or the particular team testing your software in underfinanced? Are you assuming they like your proposal based on your privacy-oriented policies since most other customers do? Could it be that they are only interested in cutting costs with you?

Negotiation is not a battle of arguments. Coming to a negotiating table thinking that your offer is good enough on some general terms is wrong. Maybe you are cheaper than a competitor, but the person buying your software is somehow attached to the current solution. Maybe their team does not want to learn new software. Maybe they don’t care your desktop software is in native GTK instead of Electron.

Slow it down

Quiet voices in your head and focus on the other side. Hear them out. We can hardly move on to present our proposal before really hearing the other side out. Listen to customer complains in detail and full. Are they quitting because they have no use for your software or because they just got a special offer from your competitor?

Slow it down. If you can, try to slow things down. The idea is that if you go too fast people won’t feel as being heard. It gives you time to think as well. It gives you time to reveal unknowns.

Adjusting your voice is another trick. Mostly you want your tone to be positive, sometimes assertive. Always smile.

In short, we have to find out what the customer wants, and stay positive!

Be a mirror

Empathy is super important in any negotiation. We should listen to the other party carefully. We should use mirroring to repeat what was said and label their fears (by words). This will give the other party feeling of being heard and understood.

If you know there is some dirt the other party has on you, you should come forward and put it on the table first. It removes their leverage and in the end comes as a much smaller deal.

Beware “yes” — Master “no”

No is not a failure. It’s the start of a negotiation. It gives the other side opportunity to relax and feel in control. They already declined, they are safe and secure in their position.

Quick yeses might mean the exact opposite. Remember telling people yes only to send them away? It’s not a real yes. They are not on board. Getting a quick yes will backfire on you.

Let people say no. Continue your negotiation and slowly get a yes. If you can convince the other party that your solution is their idea you win.

Don’t push your potential customers to a quick yes for a trial. It will lead to nothing. Rather get them really on board first.

Bend their reality

Splitting the difference means you will wear one black and one brown shoe to the party if you argue with your wife about the color of your shoes. Nobody wins. Never split the difference. Don’t settle for a compromise in which neither party gets what they want.

Deadlines make people behavior impulsive, slow down.

Use extreme anchors and ranges for less aggression. Remember the Moroccan street vendors? They would start with an extreme price to invite you to negotiation. Similarly you can start with much lower or higher values that would benefit you (closer to what you want). Combine with giving a range.

Create the illusion of control

The control is on the listener side. The one who is talking is the one revealing their position and possibly oversharing information. Let the other party do the talking. Take notes. If you can, don’t listen alone. You will always miss something.

Ask calibrated questions of How or What. How should I pay you until Sunday if my bank opens on Monday? Avoid Why?

Guarantee execution

When negotiating there might be other players behind the table. You should try to identify them and their motivation. Make sure everybody is on board. You can ask questions such as “How will it affect everybody?”

Most important is your body language, then your voice, and finally what you are actually saying. Make sure you are sending the right signals. Prefer face to face time.

Find the black swan

There things we know - known knows. They should guide us, but not blind us. There are also things we don’t know - unknown unknowns. Or Black Swans.

We should ideally find these unknown unknowns and use them as leverage multipliers. They can change everything. They are three categories; positive (to give), negative (to hurt), and normative (to bring them around).

As an example you can find about other party religion, world and life values, to have a normative leverage. What does it mean? It might mean that a guy will not shoot himself, because suicide is against his Christian values. Or that the potential customer will never use Google Analytics even though he argues your product is expensive since he can have free analytics from Google.


The book is quite interesting. If you want to read some FBI negotiation stories while getting some advice, go and read it. It’s not a long book, but could be even smaller to carry the same message. Also, Chris Voss comes out a little bit egocentric for my liking. Nevertheless, it’s worth a read.


I wrote a complete guide on web application deployment. Ruby with Puma, Python with Gunicorn, NGINX, PostgreSQL, Redis, networking, processes, systemd, backups, and all your usual suspects.

More →