(Update: Sarah Mei posted a great tweetstorm about how to deliver effective criticism. Very relevant to this topic.)
One of the enduring management challenges in any engineering group is finding the balance between competition culture and collaboration culture. Competition culture is represented by what I think of as the “classic” (or “deplorable”) engineer style: combative, arrogant, and always needing to prove one’s technical ability. Once I had a member like this on a small technical team with me. He was a recent college graduate, and was probably the smartest person in raw intelligence that I ever worked with. Unfortunately the only thing greater than his intelligence was his arrogance. He was always right and you were always wrong. When he finally left the company it was a great relief to the rest of the team.
Taken to the extreme, this competitive style is pretty obviously detrimental in almost any team setting. However, competition is sometimes quite necessary. Sometimes your team will need to engage a difficult technical problem - one with a high level of ambiguity. In this environment it is important to drive towards the best ideas. I have often counseled engineers that work for me that they need to bring strong opinions to a discussion. They may have the most insight into a problem, and it’s important that they are able to argue their ideas convincingly. It’s very important to demonstrate personal humility - we all make mistakes (I know I do!) and we’re going to make more in the future. But it’s also important to bring your technical depth and experience to a discussion.
But many engineers really prefer a culture of collaboration. They place a high premium on getting along effectively, believing that effective collaboration will be key to solving any problem that the team faces. And of course there is significant truth to this. The famous Google team study determined that psychological safety was the key attribute of effective teams. However, I have seen teams that were simply too collaborative. They placed such value on getting along that they found themselves stuck in the face of hard problems. If the one person with the right answer is unwilling to argue strongly for their approach, then it can leave the team in a state of perpetual deliberation.
Finding the balance
I try to encourage natural technical leaders and foster an environment of healthy technical debate. The key insight is to train your competition culture engineers how to do competition right. Technical discussions should always be grounded in respect for all participants. It’s critical that people leave out personal attacks (“that idea is stupid!”) and work hard to have effective discussions. Here’s a little rulebook that I use with the “competitive” engineers:
- Be humble - We all have things to learn, and places to improve. And there’s always things to learn from the people you work with. Take those opportunities to learn.
- Start by listening. Listening well is a skill to master. Work to understand the other perspective on the issue under consideration. You are more likely to convince someone else of your position if they believe you have made a serious attempt to understand theirs.
- Improve your emphathy Work on getting better at understanding other people’s points of view. Practice putting yourself in someone else’s shoes. Replay their points and arguments to make sure you are understanding where they’re coming from.
- Stop trying to be right all the time. There are places and settings for in-depth technical arguments, like a scheduled architecture meeting. But daily team chatter in Slack is not the place to constantly prove how smart you are at everyone else’s expense.
- Recognize that everyone needs psychological safety. This means being careful to recognize and acknowledge your colleagues’ strengths and experience at the same time as you may be disagreeing with them on a point. “I can see lots of situations where that would work, but because of detail XYZ I suspect it will be problematic in our case. I’m happy to discuss further.”
- Don’t die on every mountain. You will have your areas of expertise, but you don’t need to argue the technical points around everyone else’s expert areas. Pick a limited scope to exercise your technical authority.
Generally the collaborative engineers have less work to do, but I do try to help them see some of the needs and benefits of competition:
- Some of our problems are really hard, and at times we will need a vigorous debate to find the best solutions.
- A key factor for our team velocity is how quickly we can make decisions. If we try to achieve consensus every time we are going to move too slowly.
- Your colleague almost certainly respects your abilities, but sometimes they will argue in a style that makes it seem like they don’t. Try to engage with them about this directly, and help them to understand how they can improve their interactions.
Finding this balance will help you create teams that can move fast, solve hard problems, and keep everyone happy working together.