Over the last decade or so, many companies (especially in tech) have adopted a “No Jerks” policy. The idea is to have policies in place for dealing with workplace bullies and jerks, and to have safeguards in the recruiting and hiring pipeline to prevent them from being hired in the first place. Much of this wave of emphasizing workplace civility seems to have begun with Robert Sutton’s 2007 book, The No Asshole Rule and the numerous articles that followed. When I was at Google, this topic was emphasized in a 2013 internal memo from a senior executive that was (and still is) widely circulated around the company.
These kinds of articles and memos can serve as great introductions to understanding the impact bullies and jerks have on teams and the entire organization, and the more extreme examples of this behavior are often easy to spot. However, I found that some of the examples in Sutton’s book, while true reports of actual situations, were so extreme that they bordered on caricature. It became all too easy to dismiss them, feeling that my workplace doesn’t have any of those people.
But what I have found in my experience is that most people are not overtly jerks most of the time. People tend to be far more nuanced, and the behaviors that can lead to discord on a team are far more subtle, and often unintentional.
The risk of teams and organizations only focusing on avoiding negative behavior is that they will, at best, trend toward neutral behavior. It’s not enough to simply not be a jerk. We must strive to be intentionally positive.
Being intentionally positive is not something that happens by accident. It’s not something you stumble into, and I suspect that it does not come naturally to many people. By definition, being intentionally positive is a conscious and deliberate choice to behave in a particular way.
So what does it mean to be intentionally positive in the workplace? It’s really nothing profound or surprising. It’s about being respectful to coworkers, empathetic and thoughtful in communication, quick to correct and apologize when you make a mistake, and quick to forgive when others do. I’ve always worked in engineering organizations, so I’ll give two concrete examples from my experience there, but the lessons apply to any kind of work.
Building a better future
Any sufficiently complex software project is going to have bugs. The documentation is never as clear as you would like, and the tests are never as thorough. Decisions or policies that were made years ago might no longer make sense, and there may be no one left that even remembers how or why they were made in the first place. We nearly always work in imperfect situations, but the attitude we have toward that can have a big impact on a team.
Off-handed remarks about how poorly a piece of work has been done, or how short-sighted a decision was, sets the tone for how other’s work is evaluated. When done in a critical rather than constructive manner, it only serves to tear people down, even if they’re no longer around to hear it. In fact, it’s especially important if they’re no longer around, since this signals to the current team how they should expect their own work to be discussed after they’re gone.
There’s a concept in improvisational acting and comedy called “Yes, and…”. It’s a technique of accepting whatever idea or direction your partner gives you (the “yes”), and then building on that (the “and”). Even if the idea seems preposterous or isn’t where you were wanting to go. In business settings, this is often discussed in connection with brainstorming sessions, but I think it applies here as well because it’s really about attitude. If we’re dealing with legacy code or unclear policies, we accept whatever we have today, and then build on it. We may still end up changing it, even drastically, but it means we will do so with an intentionally positive attitude.
Bob Ross was famous for saying that “we don’t make mistakes, we have happy accidents”. What is that, if not applying “yes, and…” to his painting? Yes this thing happened, and we’re going to work with it and turn it into something positive.
Communicating with care
I think one of the hardest skills in life, and one I’m not sure I’ll ever truly master, is effective communication. Especially as more people are working remotely, and conversations are split across a variety of communication channels, the opportunity for misunderstandings is ever increasing. Whether it’s a simple code or design review for a teammate, or answering the same customer question for the 100th time by a new-hire that doesn’t know any better, there is a huge opportunity to be intentionally positive in our communication.
In technical reviews in particular, I have found that short, to-the-point comments meant to be expedient can also be received as brusque, impatient, or dismissive. Projects like Conventional Comments suggest a structured way to prefix comments with additional context, but I’ve also found that simply responding in complete sentences often leads to clearer communication. Or asking questions rather than giving commands: “Have you considered X here?” rather than “do X here”. (I’ve also seen this backfire where such a Socratic method led to frustration with a reviewer that clearly seemed to have an opinion but just wouldn’t outright say it.)
When dealing with customer questions, we can start by being careful to fully understand their specific situation, since it may actually not be the same as those before them. And then we can be friendly, helpful, and understanding of their problem. This isn’t about platitudes or fake hospitality (that really drives me crazy); this is about genuine empathy and kindness.
While being intentionally positive with how we communicate toward others, it’s equally (if not more) important to take the same attitude when we’re on the receiving end. This is often described as “assuming good intent” or the principle of charity. If something that someone says could be interpreted multiple ways, assume that they meant it in the best possible interpretation. Even if you know that they didn’t, it can sometimes be effective to simply ignore that fact and respond as if they did.
The cost of being intentionally positive
Like any other skill, this will not come naturally for everyone (I know it often doesn’t for me). It may require conscious effort, and it may feel awkward at times. And that may mean that it takes longer to reply to an email or complete a code review because you have to spend extra time thinking about how you respond. That’s okay. As a manager, I’m willing to sacrifice velocity in order to improve team health because I know that we will only get better at it and it will come more naturally with practice.
The only way to build the kind of team that I would like to work on is to make deliberate decisions to be that team each day.
(I picked up the term “intentionally positive” from the IndieWeb Code of Conduct which begins, “IndieWeb is an intentionally positive community”, which I absolutely love and it’s always stuck with me. I did some digging, and it was added by Tantek Çelik in February 2013.)