Why I started avoiding the word 'own'

I have started trying to avoid the word “own” in the workplace. Admittedly, it’s a bit of a silly idea, but I do think it’s a worthwhile adjustment that can help improve our professional relationships.

This little word can pop up quite a lot, “Jane owns this project”, “I own this document”, “Pete can you own this?”. It feels innocent enough, but I would argue that it can nudge our mindset in the wrong direction in the workplace.

As engineers, we can slide into feeling that the code or systems we build are “ours” - like kids that don’t like other kids playing with our Legos - this is problematic in companies where we are typically working as a team with many contributors and different ideas about how to do things.

When we ask engineers to “own” a project, it can reinforce this feeling - if you ask someone to own a system, isn’t it natural that they feel like it now somehow belongs to them? What about the other engineers working on the system? Are they simply allowed to work on the project at the graceful behest of the owner? This doesn’t feel like the right way to be thinking about building software.

Furthermore, the word owner to me conveys a sense of importance, without actually implying any useful work on the part of the “owner”. For contrast, to drive or be responsible for a project is to sweat the details, to keep on top of communicating status, to go the extra mile with testing and get the work done on time. If you ask someone to own a project, aren’t they within their rights to simply not do anything and forget about it? After all, they do own it, so why shouldn’t they do what they want with it?!

It’s important to remember that the feeling of importance conferred by being the “owner” of a project must be balanced with equal measures of hard graft to be meaningful. By avoiding the word owner and using more precise words, we can be more upfront about our expectations.

Don’t ask someone to own a project, ask them to drive it

When I want to hand out responsibility of something to someone, I now try to ask them to “drive it”, or to be the “directly responsible individual” (DRI) for it instead. To me this feels more in line with what we really mean. We are asking someone to make sure this project succeeds. It feels clearer that we expect the work to be shared by many, the “driver” is just going to be the current responsible person for making sure the details don’t get dropped and that everything runs smoothly.

Personally, I like the idea of contributing to a project driven by someone else more than the idea of contributing to a project owned by someone else - even if it amounts to the same thing, the subtle difference does feel useful to me.

Don’t own a document, author it

The word “owner” can also appear in tech specs, ReadMe’s, documentation, and in other written text. In many of these cases, I believe the correct word to use is author.

As an example, at my current workplace the default document template has a field for “owner”. I personally don’t like this default. Usually, when I write a tech spec or a system design, I am just putting down ideas to share with others. In fact, I am often hopeful that someone else will run with it and decide to drive the project themselves.

I know I’ve previously felt put off after seeing a doc on something I care about starting with the words “Owner: $MY_COLLEAGUE”. Probably this wasn’t even the author’s intended meaning in the first place, they probably don’t really believe they own this project personally. So why not start using “author” instead - which captures exactly the intended meaning - “I authored this doc, come to me if you want to know more or have questions”.