The Power of Disagreement in Collaboration

August 9, 2017 — Posted by Scott Bain

I’m an old guy.  When I was young, in the early days of personal computers, I mostly worked on my own… developing software with me, myself, and I, as they say.  I did not see other computer programmers as my colleagues.  I saw them as my competition.  There really was not enough work for all of us and I wanted to be the one who knew things.  So, if I knew something useful and/or powerful I didn’t tell anyone about it.  I kept it to myself and increased my value to potential employers.

By and large we don’t live in that world anymore.  Most of the time we work in teams, collaboratively, and our work is also often dependent on the work of other teams, vendors, and technology we did not create.  This brings the importance of effective collaboration and communication into sharp relief.

One example of this is when we disagree.  Disagreement can be an incredibly useful thing.  If you think X and I think Y, and I want to convince you of the value of my point of view, then I must think more deeply about what that is, and why.  It causes me to consider what I believe from another perspective, namely yours.  Your push-back will cause me to think yet more deeply, and perhaps incorporate some of what you are saying into what I think.  The same can be true for you.  Together, we may achieve a much more profound truth than either of us would have on his own.

But this only happens if the disagreement is cordial and non-threatening, if we can avoid the dysfunctional aspects of disagreeing with someone.  Here we can run into a particularly tricky roadblock when it comes to people who work in technical jobs.

Techies are paid, among other things, to be smart.  This is an intellectual business after all.  The idea that I may not know something that (perhaps) others think I should know can be very threatening, and can cause me to act defensively.  This does not lead to effective collaboration.

This comes up in my job as a teacher.  I teach classes in technical subjects like Design Patterns and Test-Driven Development, among other things.  Naturally, my students in these courses are technical people.  A classroom has a lot of similarities with a team; there is a leader to be sure (the teacher) but the engagement is more effective when it is highly collaborative.  Because of this I don’t want all information to come didactically, from me.  I want it to be a mix of me, my students, experiences, collaboration, and so on.  Part of this means that I, on a pretty regular basis, will pose a question to the room and ask the students to try to answer it.

Very early in my experience as a teacher I noticed that this tended to produce a lot of silence.  This varies by student group, of course, but it was not uncommon for the students to just stare at me rather than try to answer my question in front of the other students.  I gradually realized that this was often because nobody wanted to be shown to be wrong.  The whole idea was too threatening.

So, I came up with a technique for overcoming this, and I use it whenever I encounter a group of students that seem to be unwilling to “take a chance” at answering a question.  I think it can be equally useful on a team where people seem unwilling to yield even the slightest point to one another.  I call it…

The King Henry School of Argument

If you have seen “The Lion In Winter”, then you’ll recognize why I use this term.  If not, see it!  Two bucks on YouTube, and you’ll thank me. I even gave you the link.  Anyway, here’s what I do:

I pick a student who seems relatively willing to interact with me.  Let’s call him Jason.  I start by asking him, personally, a question where he cannot possibly be wrong because it is about his own opinion.

Me: Jason, tell me, what is your favorite movie?

Jason: Um, I suppose it’s “Scott Pilgrim vs, The World.”

Me: Oh, I like that one too.  I particularly loved the way Andy Samberg portrayed Scott Pilgrim.

Jason: No, Scott Pilgrim was played by Michael Cera, not Andy Samberg.

I pretend to press the argument for a few minutes, even though of course I know Jason is correct.  Finally, I bring up the IMDB on the projector screen in the room and look up the film in front of the entire classroom.   Naturally when I look up the movie in question it confirms that Michael Cera played the part just as Jason claimed.  I pretend to be surprised by this.

I then turn to the room and ask the group “who won the argument?”  Almost without exception, everyone agrees that Jason won and I lost.  But I then point out that Jason came into the argument with the same information he left it with, namely that Michael Cera played Scott Pilgrim in the film.  I, on the other hand, have left the same argument with new information that I did not previously have and also I have corrected a mistake in my memory.  I have gained something from the interaction, whereas Jason has not (except perhaps a minor stroke to his ego).  To these old eyes, that looks like winning (that’s what I learned from King Henry in the aforementioned film).

I then, of course, own up to the fact that this was all a ruse.  Gotta keep things honest.  The point was to shift their point of view.

When we collaborate, the value we bring to one another is what we can contribute, each to the other.  If you already know everything then my value to you is limited or non-existent.  In the classroom, I point out that if a group of students is already “right” about everything then coming to class with me is a waste of time.  They have come, I submit, to gain knowledge they don’t already possess.  Revealing what those gaps are is just part of the process of learning.  And, by the way, I point out that I always learn from things my students because I am not afraid to admit that they sometimes know things I do not.

Of course, my real intention is to change the interaction from a threatening one to one of promise.  I also believe what I am saying to be the truth.  Nobody knows everything.  We operate in an environment of constant change and innovation, and staying current can be a real challenge.  If we take down the mostly pride- and fear-based impediments then we can be true colleagues, and everyone will benefit from them.

So will the products we create, and the customers that benefit from them.


Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Scott Bain

Scott Bain is an consultant, trainer, and author who specializes in Test-Driven Development, Design Patterns, and Emergent Design.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban