Creating Team Ownership with Better Language

We are code creators and we become personally attached to the code we write. We may even think of a pull request as adding “my code” to a project. I believe that with a fundamental shift towards thinking and communicating about it as “our code” we can create a more open and constructive working environment.

Try the customer support platform your team and customers will love

Teams using Help Scout are set up in minutes, twice as productive, and save up to 80% in annual support costs. Start a free trial to see what it can do for you.

Try for free

Shifting from Me to We

In the context of chat it can be easy to slip into using first person “I”. This can reinforce the personal ownership of code. Consider the difference in these two Slack messages:

This simple shift in tone moves the class from being owned by the original author to being owned by the entire team. Small shifts in tone can promote shared ownership and make other developers more comfortable refactoring, improving, and extending code.

By rephrasing the question, we can immediately change how our team members will engage with the code by framing it terms of shared ownership.

A Friendlier Tone In Code Review

We can make a similar change to the language that we use in pull requests and in other discussions about code. We can minimize the use of “I”, “me”, “my” and instead promote ownership and shared responsibility with “we”, “us”, “our”. Let’s look at a couple of ways that I can write the same feedback on a line of code.

In the first example there is underlying blame. The meta-message is that the author has done something wrong. In the second, I’m asking if there is a better option for us as a team. The tone is shifted from “You’re wrong” to “We could be better”.

There is an exception for the use of “I”. It is acceptable and lovely when used to share praise and positive comments. Because we pour so much into the code that we write, receiving a positive comment from an individual can be personally validating and enormously rewarding.

Writing Pull Requests for Shared Ownership

In many projects, a pull request may represent the work of a single developer. In this case it’s extremely easy to think of the code as “mine”. Instead, I urge you to consider it as your contribution to the codebase as a whole. With this in mind, we can look at a final example.

The same content is delivered by both messages, but in each the underlying tone is quite different. The first example shows clear personal ownership. The second message builds team ownership and promotes shared responsibility.

The Benefits of Shared Ownership

If a coworker had written a particularly complex class and continued to refer to that code as “their code”, I might be less inclined to work on it. If there was a bug in it, I might even tend to blame them for the bug. If I were to work on that particular class, I might try to fix the bug with as little code change as possible — perhaps with a dodgy if statement instead of a proper refactoring. The complexity of the class would get even worse, and any subsequent fixes would only continue to degrade it.

However, with our change in tone this particular class belongs to us. Now, we have a particularly complex class, and I would certainly be willing to wade into improving it for the good of us all. I’d certainly consult with the original author about how we can make it better for us. In the end, we’ll end up with easier to maintain code and each developer can have broader experience in the codebase.

Shared ownership is about building common goals, improving development velocity, and helping to prevent developers from getting siloed. Some developers may even be hesitant to comment on code if they think that it will be heard as criticism of the author and not as a recommendation for “our code”. If the author immediately introduces the code as “ours”, it can elicit more open and productive discussion.

By removing blame from our communication tone, we promote a positive work atmosphere where developers can collaborate without hesitation. We can have higher quality code and happier developers with faster development velocity.

An Experiment for You

You can experiment to see how this change in tone makes you relate to your coworkers. In your next code review or in your next day of chat messages, you should try censoring your use of the following: I, me, my, mine, you, and yours.

You can even go a little overboard with the experiment and remove those words completely from your language for the day. More importantly, read messages from other developers and then try re-reading them as if they had been written with this new rule and see if the messages would affect you differently.

We’re all in these projects together, so let’s start starting communicating like it!