Task vs Relationship Conflict - reading through Adam Grant's "Think Again"Published on 09 June 2021

There are these books that hit home. They just do, and there's not much you can do about it. You hear a book is good, add it to your "Want to read" list and when you finally pick it up, every chapter is a small revelation.

"Think Again: The Power of Knowing What You Don't Know" by Adam Grant is such a book. A piece about a subject so "trivial", most of us don't even think (no pun intended) about it. Mind you, I haven't finished the book yet, but the chapter on conflict, entitled "The Good Fight Club" is so fascinating I couldn't pass up writing a post about it. Like you, I imagine, I deal with conflict on a daily basis. And when I haven't had enough, I fire up a movie or a video game, to find myself sitting through even more conflict.

It seems as though there's never enough of it, whether made-up, or real.

At work, having a heated argument with another engineer about "inline svgs" or "CSS-in-JS vs plain-old CSS" is a constant, never-ending battle (for those of you not into front-end, or web development, think of these as life-defining, application-breaking decisions. Because that's what they ab-so-lutely are. Tooootally). And yet, when the argument's over, we go back to our jobs as if though nothing happened. In "Think Again", Grant quotes organisational psychologist Karen "Etty" Jehn, who puts it quite nicely: you're not seething at the other person because the conflict you're having isn't personal conflict, but task conflict. You're not trying to shoot each other, Mexican stand-off style, because the other guy broke into your farm and burned down your fields (I've played way too much Red Dead Redemption 2 lately, please don't @ me), you're trying to accomplish a job, and work towards a common goal.

As Adam points out in his book, in the case of task conflict:

"We don't challenge because we're insecure, we challenge because we care."

How do you keep steering the course, though, walking that silver lining between, as Adam puts it, "getting hot" and "getting mad"? Because when you get mad, and windows shatter to the high-pitched tone of your "MY IDEA IS BETTER THAN YOURS", that's when task conflict transforms into relationship conflict. Emotions run wild. And that's the keyword: emotions. When each side is arguing about why their shinier approach is, indeed, shinier.

The thing here, according to Adam, is to "turn away from arguing about why, and start arguing about how".

Let's take a front-end development analogy. It is my everyday job, after all.

Ask a React developer why is CSS-in-JS better than plain CSS and they'll pull out their pedestal and preach about the developer experience of styled components, or the out-of-the-box theming solution that comes with the ThemeProvider, or simply go "Dude, it's React".

Ask them how it works, and they'll dig their teeth into the documentation, and probably realise that the landing page they're making has no need for all of those bells and whistles, and just writing a couple CSS classes is a faster way to go about their job, without installing another npm package, without bundling it into the code they ship, without having to teach everyone about a new API, and just... Using the stuff that's native in the browser and everyone is familiar with, is the solution they're looking for.

Ask them how you're going to integrate it into your current stack, and they might stutter, because it's often a nail-biting process of working alongside legacy CSS, maybe even SASS, maintaining both for a (usually long) period of time, slowing down your work and your builds, selling it to your product manager, and in the end (depending on your project size), you'll probably be better served by just cleaning your existing CSS or, if you're using SASS, just dropping the preprocessor (because admit it - you're mostly using it for the variables).

Yeah yeah, ri... Oh my gawd, I am, aren't I?!

And pulling away from code analogies, as someone in a married relationship, this advice rings Notre-Dame-sized bells, for whenever my wife and I have had a conflict about something as trivial as ordering food or which movie to watch (why should we watch an umpteenth rom-com is a bad bad bad question to ask and instantly veers into "you and your sci-fi" or "you and your serious HBO shows").

Thing is, it's just easy being a preacher, right? Rambling on about our thing, wrapped in that two-sided board hanging from our shoulders, locked up in our own bubble, our own feed. It's comfy in there, safe. We often want something to just be, especially in these times. We care about the why - because we want it, plain and simple. The how - well, that's a wholly different matter. From how our phone works, to how we eat, to how we watch, speak, exchange, take the bus. The how opens up a can of worms we just... Want to close, because, let's be frank: we don't always know the how, and we don't always want to know about the how. It complicates things, and we're already living complicated enough lives.

For starters, I guess, we can start slow and read the documentation.


  1. For the sake of the argument: CSS-in-JS absolutely has its merits and a purpose. For big applications, like the one I'm working on over at Aircall, that can benefit from white-labelling & theming, strong component reusability, as well as DX, when you have a big team and maybe even a shared design system, it's a pretty good match.