The most important SDE skill: Ownership

”Without ownership, there can be no leadership." - http://georgecouros.ca/blog/archives/3791

This post is about one of the most important leadership skills you can find: Ownership. I see it as a root of all other leadership skills. If you don't feel being an owner, you often don't feel neither responsibility, nor interest or empowerment to bring changes.


What is Ownership

Ownership is “the act, state, or right of possession something.” You can own computer, car or house. And as such, you feel an ownership to those things: you can install new software to you computer, clean it up, fight viruses, upgrade it etc. Same story is with car and house: you feel and are empowered to make changes and in your interest to make changes for better.

“Ownership is about getting something done no matter what. ” -http://www.tandemlaunch.com/ownership-versus-leadership/

There is also another definition of ownership. You take ownership when you feel responsibility for the results of your work: finishing up project, taking care of found issues, making future improvements. As an owner, I will get this project done, I will make sure it is tested and properly working, I will make sure that it delivers what my customers expects, and I will make sure that found issues will be resolved.


Ownership in Software Development

Actually, there is nothing special about being owner in software development. Development process is quite well defined: there are phases for gathering requirements, designing and planning, coding and testing, bug fixing and launching. List of artifacts is also well defined: source code, documentation, tests, metrics, list of issues and etc.


Group Ownership

Group ownership is also a shared ownership. Multiple software engineers own codebase, projects and features, specific modules or components. Usually, engineers in a team will have different level of ownership skills:

  • some would just do the work and won’t care much of the result,
  • some would focus on finishing single task successfully and wouldn’t care much of a whole picture
  • others would care mostly about their own feature/component and wouldn’t care of a whole projects
  • others go beyond and focus their attention on a whole project.

The higher ownership skills, the larger area they normally cover. I would call it an “ownership scale”.

Off topic: Ownership and Career Growth

Interesting that you can see a clear match between ownership scale and engineer’s position: junior software engineers are barely understand what is happening and focus on finishing up single task; mid-level engineers are focused on a codebase, features that they work on and, maybe, a few more aspects; senior engineers go beyond that and focus on a whole product or larger part of it.

Ownership level tells what are you focusing on as part of your everyday job and how how successfully you will be able to deliver results.

And based on this, I make a statement that Ownership skill should be an important part of promotion evaluation, same as technical skills are.

Working in a team is always harder than working on your own. Dealing with more people that are owners of the product (just like you) is even harder.

Group ownership requires to take into consideration thoughts and ideas of other owners. There is no a simple way to make a decision now. But luckily you get more than just a headache. Discussion with other owners can help find both consensus and a better way. It is because all owners are focused on improving things and successful delivery, not on own ego satisfaction.

The strategy of “my ownership is better than your ownership” is a lose-lose strategy. Such behavior will kill or suppress ownership attitude in others. As an owner who care about the product, searching for a path to success, you lose like minded people who could help you here. Demotivated ownership might even cause an opposite to ownership behavior. Real owner would grow other owners around, b/c in a team work this is the most effective way to delivery successful product.


Examples

Here I’m going to provide a list of different behaviors and try to give my opinion on ownership level.

  • Mark finally finished the project he didn’t like much. And now he is not eager to work on the related bug that was found recently. I think you would agree with me, if I would say that Mark’s ownership level is not very high. First of all, Mark didn’t like the project and now attempts to skip working on issues that are result of his previous work.
  • Hanna finished working on the project that she was assigned. She didn’t want to work on this project, but business really wanted it. But Hanna took the project and work it through and delivered successfully. Now business loves Hanna and has a new project for her. This is a good example of ownership. Hanna took the project she didn’t want at first, but liked eventually and could deliver it successfully.
  • John was asked to help with task for project X. John was really helpful and could finish task successfully. He also fixed a few issues he had found, and helped Sarah to develop analytics module faster. Project X was released on time with John’s help. This is a great example of ownership. John was just asked to help with a task. Instead, he take a responsibility to fix issues and help Sarah with her work on the project. Don’t be like Mark, be like John.
  • Lisa works only on the tasks that she was assigned. She doesn’t spend much time learning to do her work better. Lisa also doesn’t spend time to see how she could improve the project. Most of the time she spends on tasks added by others. Whenever she finishes with task, she moves next without a necessary testing. I’m not sure that I see any ownership here. Lisa is not owner: she doesn’t care about results and quality of her work.

Summary

In todays world, having a great technical skills is only one important part that makes a successful software engineer. But there is more than it. Ownership skill is another important part. It is important for engineer to get projects done successfully, improve team, processes and software.

If, after so many years improving technically, you still find you need to get better, then switch your focus to improving your Ownership skills.