Ownership
The topic of ownership has been on my mind recently. It's not a new topic. I've written about it before as well as many others such as James Shore, Martin Fowler, and Pierre Raynaud-Richard, to name a few. Most of the time, when talking to software engineers about ownership, the focus is on code ownership. While that should be a big focus, I think the issue of ownership does extend beyond that. Not only does ownership affect how we think about the code we work with, it also affects how we think about everything at our job.
So, what is it about Ownership that's sparked so many people to write about it? Why has it been on my mind of late? How can ownership help you in your career? What does that word mean? I took a moment to Google that word and found one definition that really made the meaning of ownership clear in the sense that we use it in business:
An attitude of accepting responsibility for something and taking control of how it develops
I think this definition brings out an important aspect of ownership. While many software engineers will never own companies and may never be interested on owning companies, you don't have to be the CEO to feel some degree of ownership for what happens at work. Ownership isn't about who's name is next to a commit message or even who knows the most about a given area of code. Ownership is a mindset--a way of looking at the world. It's realizing that what you do and don't do has significant impact at work and it's doing your best to make your company successful. Let's take a minute to dive into that a bit more.
An Example
Let's say you're fresh out of college with a nice, shiny Computer Science diploma hanging on the wall. You've spent around four years of your life applying yourself and learning what you can in order to prepare for this time of your life when you have a real job working for a real company making real software. And now here you are! You've just started at your first job! You're simultaneously ecstatic and terrified. You have a real job! But are you really ready for it?
The first few days and weeks fly by. Before you know it, you're starting to get your bearings in the office (finally remembered where the bathroom is!) and in the code. You're slowly being given more opportunities to write code and work in the system. As you work in the system and observe the processes within the company, sometimes you can't help but notice things that don't seem quite right or quite as good as they could be or that seem to be the opposite of what you learned in school and what you thought was good.
A Choice
Let's pause right there. Now, I haven't mentioned anything specific at this point--just some generalities that things don't seem to be as good as they could be. This sentiment is true for nearly every company out there. You may be thinking "big deal, nothing's perfect and we shouldn't expect it to be," and I agree. I want to pause right here because I think this is a critical moment and one that can help illustrate the point of ownership.
So, you've noticed some things that could be better at the job. You're the new kid on the block and are just getting your feet wet with professional software engineering. What do you do? I think you have two basic choices here: 1) acknowledge that things aren't ideal and move on (or even complain) or 2) acknowledge that things aren't ideal and do something about it. I think this seemingly little choice, especially at this moment in your career, can be an important one. Let's talk about a few reasons why.
One reason why I think this is an important choice is that what you choose here is likely what you'll choose down the road when another choice like this comes up. You may think, "I can let this go, but if I see something that's worse than this, I'll speak up." While that can sound good (believe me, I've said similar things before), not speaking up now will make you much more likely to not speak up later. If you're nervous now, think how much more nervous you'll be when choosing not to speak up sooner ended up costing the company money or missed opportunities.
This small choice can make a big difference on your job satisfaction. Making the latter choice (choosing to do something) will likely lead to you feeling more engaged at work while the former choice will likely lead to you feeling less engagement and likely less satisfaction at work. The second choice will likely lead to conversations where either you learn something you didn't know before or you help affect change at your job (or both).
In the end, the choice here is between taking some ownership for what goes on at the company or not. This does not mean taking complete responsibility for the items you've noticed, but it does mean you care, that you're interested, and that you want the company to succeed. If you choose to let it go (or worse, complain about it but not help improve the situation), your sense of ownership will diminish which can lead to high levels of dissatisfaction; however, if you choose to say something about it, your engagement and sense of ownership will increase.
Even though, in this example, you're a new employee and you're young in your career, you were hired for a reason. Not only did the company hire you, because you're an employee, you now have a stake in the success of the company. If the company does well, you get to keep you job and keep getting a paycheck (and dominating at the ping pong table). If the company doesn't do well, you may lose your job or at least cause some pretty significant changes to the culture at work. So, if you have an idea for how the company could do well and be successful, don't be afraid to bring it up with someone. Bring it up with your manager, your mentor, a friend, the VP, the CEO, whoever you think would be the best one to hear it. You're an employee there. Your ideas matter. You are (or should be) empowered to make the right decisions necessary to do your job and enable the company to be as successful as you can make it in your role.
What Does Ownership Look Like?
Trying to identify exactly what ownership looks like is no small task. I think it varies from person-to-person, but I do think there are some common threads that are shared with those who take and exhibit ownership at work. Ultimately ownership, as I mentioned above, is a mindset. It's a way we approach our work and view what we do. The next paragraph is an attempt to enumerate a few examples of what ownership might look like.
Ownership is caring about the code you write, about the code your coworkers write, about the success of those around you, about the success of the company, and about the processes the business follows. Ownership is striving to do the right thing even if you might be met with resistance. Ownership is defending the business's processes and values. Ownership is knowing that you're a professional and that your peers are professionals. Ownership is giving your best every day. Ownership is caring enough to speak up even when (and especially when) it might be hard. Ownership is proactively making decisions rather than waiting on decisions to be made at higher levels. Ownership is realizing your actions impact those around you and the business. Ownership is being engaged and searching for valuable things to do rather than merely doing what you're told when you're told to do it.
For me personally, when I feel ownership for what I'm doing, I take the time to do it "right." I make sure I can focus on it and limit distractions. I take time to think it through and think of possible outcomes or ways things could go wrong. When I feel ownership for something, I generally take a bit more time to communicate clearly about the things I'm working with and I try to involve the interested or affected parties early on in the processes. When I feel ownership, I do my best to see that it either succeeds or we learn something from it.
Get Tactical!
There are a number of things you could do when you feel ownership. What you do largely depends on you and the situations you find yourself in. There's no one way to feel or exhibit it. With that in mind, let's dive a little deeper into some specific examples and how you might act if you have a mindset of ownership.
Example 1
Let's say one day you're working on a defect in an area of the code that you're pretty familiar with. In the course of debugging it, you realize that the root cause of the issue isn't in the code that you're familiar with but is in a section of code that's somewhat "owned" by another team. What should you do?
There are many good ways to handle this situation. One way I'd recommend against going is being afraid to change the code because you don't know the code or because you fear what the team that owns it may think or say. Please, don't do this. Remember that you are a professional just like they are. You're employed by the same employer and you're all peers. You aren't any less because you don't know this part of the code and they aren't any better because they do. One way you might choose to handle this situation is to take some time to understand the code, derive a solution, and then have someone from the team more familiar with it look at it with you. Another way you might handle it is reaching out to that team directly to have one of them walk you through the area that's causing the issue. There are plenty of good ways to handle this that show ownership and responsibility. Please don't spin your wheels or avoid it because it may be hard for one reason or another.
Example 2
Let's say that at your work you follow the Scrum methodology. This means that you plan once every two to four weeks, commit to that plan, and don't make changes to that plan unless something significant comes up and the entire team decides to make a change. One day, a few days into the sprint, your team's Product Owner says that he's getting a lot of pressure from higher up to get certain features done. As such, he wants to pull a few defects out of this sprint and replace them with more feature work. What should you do?
One way you might approach this is to reiterate the team's sprint commitment and to ask why these features are more important than some of the other items in the sprint. You might also choose to explain some of the repercussions of displacing the other items in the sprint. In general, you'd want to get to a shared understanding of the value of the items the PO wants to bring in and the cost of moving the other items out. If you can reach a shared understanding, you will make a much better decision.
One thing you likely shouldn't do is to blindly accept the changes. While you should trust the PO to do her job, making changes to a sprint affects you, too, and you have a right to voice your opinion and seek understanding. Not only does changing a sprint affect the team, it can affect the company as a whole. If new features are prioritized over defects and bugs, instead of along with them, you can likely expect software quality to decrease and releases of the software to be delayed until quality is addressed. This can cause delays in sales which will cause incoming revenues to slow which can cause the company to lose money and, potentially, go out of business (though that's not very likely in most cases except for small startups).
Conclusion
Feeling ownership at work is a mindset. It's feeling a sense of responsibility for the outcomes at work. That doesn't mean you are to blame for them, but it does mean that you realize your place and how your actions impact those around you and the company as a whole. Having a sense of ownership can take many forms but it always requires action. It's usually a harder road than if you don't feel ownership, but it's a more rewarding path more often than not.
So, the next time you see something that could be better or the next time you wonder why you're being asked to do something or you wonder why things are done in a certain way, speak up! Keep an open mind and don't be afraid to learn more about the company and to better understand your role and how you impact the company. Spending time to learn more and to increase your sense of responsibility will increase your job satisfaction and engagement.
Agree? Disagree? Want to share a thought or experience? Comment below!
This article was originally posted on my personal blog.
Top comments (1)
Great article! I really enjoyed reading it. 😃
Another important point is, that you communicate any action with the team before making changes that might impact other people's work. Especially when in this area of the code is being worked on. It turned out to be a good practice to talk with the ones working in the area and mutually agree with them on a certain way of to implement the feature/fix the defect. Gently remind them when they don't stick to the agreement. If this won't change anything, you can take action and change the code with the agreement of management on your own.