*This post about Radical Candor and mental health discussions at work was contributed by Chris…
Radical Candor and Software Engineers: Interview with ZenHub
We frequently hear about companies who are excited about Radical Candor and trying it out in their organizations. Each time, our first reaction is to ask, “Wow! How’s it working for you? What have you learned? How can we make it easier?” We’ve been chatting with a few different companies to learn about their Radical Candor experiences, and we think their stories and specific contexts can help others as well. So we want to share those experiences with you, so that you can get inspiration and tips for your own Radical Candor rollouts.
We recently learned about ZenHub’s book, Better Software and Stronger Teams, which shares strategies, including Radical Candor, to help software engineering teams become more collaborative. ZenHub is known for building the new standard in developer collaboration tools, and they’ve written about how they apply the principles of Radical Candor to their internal engineering organization.
The ZenHub Team
We talked with ZenHub’s Matt Butler (CEO) and Paige Paquette (Head of Marketing) to learn more:
How was Radical Candor introduced to your team?
We found out about Radical Candor through Kim Scott’s wonderful talk that was featured on First Round Review in 2015. We were already practicing many of its principles internally, and the framework solidified the ideas and gave us a great way to talk about and develop our habits.
We realized that a lot of the time, we were operating in the Ruinous Empathy quadrant — which is to say that we were so focused on being “nice” that we glossed over issues that led to consequences down the line. Learning about the four quadrants that Kim described helped us view our culture at ZenHub through a new lens.
What was the initial reception like on your team?
We’ve always been a low-hierarchy team that tries to keep the workplace as BS-free as possible. However, though every member of our team certainly cared about the work we’re doing together, actually having a critical conversation could be a challenge (we’re in Canada, after all.)
Developers rarely seek out conflict, and engineering meetings have always struggled with this point. We found ourselves holding retrospective meetings that focused on what went well. That’s the easy part. But we were missing the mark on finding out why things went wrong. As a result, we were encountering the same problems again and again without really knowing why.
Legitimizing the simple practice of Radical Candor did a lot to encourage meaningful feedback. We developed our retrospective meetings, a common practice in software teams, in a way that encourages constructive feedback, not finger-pointing. We wrote about how we achieved this in our new book, Better Software and Stronger Teams.
Can you tell us a little bit about retrospective meetings and how you use Radical Candor to structure those meetings?
Retrospective meetings typically happen after a big feature launch, or after what are called “sprints” — a two- to four-week period of work with the goal of shipping valuable code at the end. These meetings are meant to uncover what went well, what could have been done better, and most critically, where things went wrong.
But they can be notoriously difficult because nobody wants to point fingers. We call it the problem of politeness. Without candor, problems have the tendency to snowball, resulting in inaccurate information, late features, and failed software projects. The problem of politeness is costing companies a lot of money.
The problem of politeness is costing companies a lot of money.
The way Kim described Radical Candor as the intersection of “caring personally and being willing to challenge directly” is a really concise way to frame our own internal approach for ensuring feedback is shared.
Two strategies we discuss in our book are “start, stop, and continue” and root cause analysis.
“Start, stop, or continue”
During the meeting, ask each team member to name things they should start, stop, and continue doing. “Continue” items are the things that are helpful but aren’t yet habits.
Root cause analysis
Root cause analysis is a fancy term that means “tracing a problem to its source.” It can help you figure out what happened, why it happened, and what steps you can take to prevent it from happening again.
We apply Radical Candor through each of these two strategies.
What is unique about practicing Radical Candor on an engineering team?
Engineering teams need to be agile, and there are a lot of moving parts — particularly for distributed teams, which are very common these days. Because there are so many moving parts, features can often ship late, over-budget, or not at all, and the reasons why are unclear. Even though we have more collaboration tools than ever — from GitHub, to Slack, to products like ZenHub — it’s still incredibly difficult to find the root causes of problems.
The speed at which agile engineering teams move can make it difficult to slow down and ask the hard questions. It becomes even more difficult when your team is spread over 5 countries and 3 different time zones. That’s why it’s so critical to make space in your hectic development process to reflect.
Radical Candor is particularly helpful to engineering teams because of this hectic process. Being able to give quick, effective feedback without damaging relationships is important for building a high-performing team, and Radical Candor makes that possible. People say what they think instead of letting it build up, unspoken, over time.
What has been the impact of Radical Candor on your team?
By fostering a culture of impromptu feedback in our team, we’ve been able to move even faster as an agile company. We get to the root of issues faster, but we also are able to mentor much more effectively.
For example, instead of just commenting on things that are incorrect during code reviews, our team actually puts an incredible amount of detail and discussion into *why* something could be done better. We take mistakes as an opportunity to learn and teach.
In this way, code review has become an engineering mentorship tool for us, which is really unique. We even see interns improving the code of our most senior team members, which is unheard of at some companies.
What recommendations do you have for other teams that want to start introducing Radical Candor?
The most effective practices are the ones that you can make habits. Radical Candor is one of those practices. Nothing is required besides a little effort and consideration, so consider making the effort.
When someone provides feedback, make a point not to point fingers or introduce shame. By celebrating feedback when it’s given, whether positive or negative, you’re setting an example and building a culture for others to follow.
Has your team or company introduced Radical Candor? We’d love to hear about your experiences and feature them here! Get in touch.