Atomic has added Crucial Conversations to our short list of required reading, meaning new hires will be expected to digest this book within their first weeks on the job. We think it’s important enough to rank right up there with Extreme Programming Explained (1st edition!) as a book that explains how we work and what we expect from one another.
This might sound kinda strange at first… Crucial Conversations isn’t even remotely technical and doesn’t specifically mention software design or development. But a growing number of us have read it, and we’re finding value in the description of good dialog and its significance. We could all use better tools for recognizing dangers to dialog and for bringing us back into meaningful conversation.
Crucial Conversations Are Common Here
Shawn blogged earlier this year about Dealing with Bad Behavior and Broken Communicatin in Teams, describing how employing the knowledge and skills from Crucial Conversations can help you disarm and heal potentially toxic situations. This improvement alone would be enough to get me excited: it would be good for everyone to gain such skill in case the talking gets tough, either amongst our fellow Atoms or between us and our customers.
But beyond coping with tough conversations (which on good days, we’re not having so many of), I’ve got this this tantalizing feeling of familiarity as I read about “safety in dialog” and contributing to the “pool of shared meaning.” These concepts seem criticial to any useful communication, and we enjoy their benefits fairly regularly within the walls of Atomic.
Then it struck me. Many of us already have developed Crucial Conversations skills, incidentally, as we learned Pair Programming. I think effective pairing — as a learner or mentor — requires that you are able to participate in an ongoing form of Crucial Conversation.
Let me dwell on the importance of Pair Programming for a moment, then I’ll round back to what I mean by that.
Pairing Can Be Like Having a Crucial Conversation
Pairing is extremely valuable to our developers and designers as a core practice in our daily creation of software. When we pair, we’re more effective and produce better output, we maintain better momentum, we share more responsibilities and knowledge, and we present a more robust interface for our customers than we could as individuals. It’s also our best channel for training; learning; propagating new ideas, tools and practices; and building trust and mutual purpose. We’ve been pairing since day one, and each year gives us another chance to appreciate its role in our success. There’s lots of momentum here; it’s in the bones of our culture.
But institutional pairing doesn’t come easy; many organizations and developers continue to reject the practice. So while we sometimes take it for granted, we shouldn’t. There’s something at work here at Atomic that lets us pair when others cannot. Reading Crucial Conversations has tipped me off on what it might be.
The book describes a crucial conversation as “any conversation where the stakes are high, opinions differ, and emotions run high.” So where’s the similarity with two developers working together on code? (Or two designers sketching wireframes, or a developer and a designer hammering out CSS and markup?)
- High stakes? Yes. We’re building something for a paying customer, and we’re running out of time and money. Whatever we decide to do, it counts.
- Different opinions? Yes. Developers and designers are sweating through the solution to a tricky problem. Duh.
- Strong emotions? Frequently. We hire passionate people who align their desire for success with the success of our customers. The operative word here is “passion.”
In these ways, pairing with someone can feel like a crucial conversation. The same skills that foster meaningful dialog are useful here, perhaps because pairing requires dialog, and what might seem like a straightforward technical exchange can suddenly become emotionally charged. Maybe a newcomer is uncomfortable with sharing their thoughts and keyboard with another developer or designer. Or a mentor challenges a learner’s assumptions about how to build software, implying ignorance or inadequacy. Or a learner fears reprisal for pointing out her mentor’s mistakes. Or a developer struggles with providing candid feedback. Or two long-time peers butt heads over a design choice and have difficulty deciding whose opinion is best.
Pair Programming Builds Dialog Skills
The people of Atomic have consistently overcome these challenges and mastered Pair Programming. But if pairing is like dialog, how have we been succeeding without explicitly practicing the skills outlined in Crucial Conversations?
For starters, we’ve got some momentum in our culture to support pairing. There’s ambient peer pressure to at least open your mind to the possibility that it might work. As you walk in the door to Atomic, you’re seeing people pairing all around you: developers, designers, up-front teammates.
You’re free to challenge the practice. “We’ve always done it this way!” isn’t a good enough reason, and we’re always ready to sit down and discuss, demonstrate, and teach what it takes to pair effectively. Pairing is hard, and if disagreements are treated as arguments to be won by the more experienced partner, we’d basically be making you “drink the Kool-aid” and accept by force something you don’t really value. We strive to avoid this, which means having real discussions when you raise a concern and providing real answers to questions. As mentors, we’ve learned to resist the temptation simply split off and avoid pairing (silence) or, to shout “because I said so!” (violence) to force a decision. Time and again, we have to remind ourselves why we’re here and why we value pairing, to discover what’s getting in the way of someone new, and to help them re-engage in the conversation and continue to grow into pairing.
So in some ways, we’ve already started adding key ingredients to the Atomic cauldron. I believe our common experience of “solving” pair programming overflows into the atmosphere of our workplace and adds something to our culture. At Atomic, it’s relatively easy to:
- Find Mutual Purpose
- Earn (and Show) Respect
- Build a Foundation of Trust
- Feel Safe
Looks like we’re all Crucial Conversations veterans already!
…or perhaps not.
Improving Our Crucial Conversation Skills Can Improve Our Pair Programming
The most critical Crucial Conversations skill is recognizing that you’re having one. Recognizing that safety has been violated, realizing that we ourselves are detracting from that safety, restablishing self-control, and stepping outside the conversation to restore safety are so important that the sooner and more consistently we do them, the better. Some people are naturally good at this, but most need practice, and to practice, we need language and structure to describe what we’re trying to do and why it will work.
Having read Crucial Conversations, I feel better equipped to start improving myself in dialog, even though I think I’ve mastered Pair Programming and its many dialog-related challenges. In the past I’d been approaching my general work interactions and difficult conversations from an intuitive, ad-hoc standpoint, but I now have a framework to understand what’s going wrong and how to get back on track.
And I don’t think I’m the only one; I think this could help every software developer at Atomic understand where a lot of our success has come from, and how we can build more. To new hires, I want to point at Extreme Programming Explained and say “this is how we roll,” then point at Crucial Conversations and say, “this is why we can.”
This analog to Pair Programming could have been enough for me to want to bring Crucial Conversation into our required reading at Atomic. But it’s actually just the beginning, something in our soil, and (to be honest) something we’ve got a firm grasp on and will continue to be successful at. There have been some bigger, scarier, less-intuitive situations at work that I know I would’ve handled better if I’d only read a portion of the Crucial Conversations book, and that’s what pushes me tell anyone who gives a shit: “Read this book immediately.”
(More on that later!)