Book Review: Never Split The Difference

One of the last things I did in 2021 was read Chris Voss's excellent book, Never Split The Difference.

The book left such an impression that I decided I needed to take notes and to share what I learned from it during the weekly beach showcase. I've made a copy of my presentation (without the nice Thoughtworks branding) so that I can link the PDF of the slides, guilt-free.

tl;dr: required reading for anyone who has to negotiate or persuade. Which is everybody.

Why should a developer read this book?

I heard of this book a couple of years ago, probably when it was first released, but the idea of reading a book about negotiation called "Never Split The Difference" didn't appeal to me. I thought the mantra of "Never Split The Difference" sounded aggressive, almost like a challenge -- "hey you, I dare you to come up against me in a negotiation, and we'll see what you can walk away with!". When I learned that Chris Voss was a former FBI hostage negotiator, that just made me feel like this book wasn't for me.

Over time, I saw this title pop up enough times that I became intrigued. A co-worker said she was reading it, and that our manager had recommended her the book. It was on the list of book recommendations for Learning and Development. A comment here and there that the book was useful for consultants, for product managers, for anybody who had to manage stakeholders.

Still, it wasn't a priority as long as I saw my job primarily as delivering code.

That changed with my experience on the SIP project that inspired my last two posts. The project was much more consultative than I expected, much more about shifting existing notions of how to build software, and much less about writing code.

I came to realise that in most contexts, delivering code is just one aspect of impact. In fact, the shorter and more constrained the project, the more important it is to be able to come to a shared understanding of what good software practices look like. Negotiating the space between what you and your client understand to be good software engineering is essential to making sure the impact extends beyond your time on the project.

What my presentation covers and doesn't cover

The book is so jam-packed with great information that it was impossible to put everything I thought was useful into the presentation. I had to leave out a lot of the theory, a lot of the examples, and focus mainly on the set of tools that I think will be most useful for the consulting context.

That means that key negotiation and behavioural concepts such as anchoring and adjustment, loss aversion, etc. – and even some ideas that are relevant to consulting but that aren't associated with specific techniques, such as voice, tone and emotional control – have been deliberately left out.

What I ended up doing was focusing on the idea of "never splitting the difference", and then on six techniques, three for active listening and three for negotiating:

• Active listening
  • Mirroring
  • Labelling
  • Summarising
• Negotiating
  • Questions that trigger "no"
  • Calibrated questions
  • Black swans

These are covered briefly in the presentation, so that you can get an idea of the ground that the book will cover.

But seriously, just read the book.