Ownership: An often overlooked and undervalued soft skill in tech.
It always amazes me how frequently ownership in tech seems to take a backseat. Ownership is something that hiring managers tend to latch onto, but in my experience, many never pursue this skill. This is especially true for engineers. Let’s peel this onion and try to understand what it means to own your role.
What is Ownership in Tech?
When you hear the term ownership, what comes to mind? I suspect most people already know what it means to be an ‘owner’ of something. Many of us at least ‘own’ a car. In Tech, Ownership goes beyond simply having liquid cash in something.
Instead, ownership refers to your ability to ‘take charge’ of a situation or product. Put another way, having ownership in tech is more about being an owner of your domain knowledge. That is to say, your domain knowledge is a driving force behind your decision-making.
To be clear, I’m not referring to ownership as a manager or leader in an organization, though that does certainly have its own merits.
What often happens in tech?
In my experience, more often than not, the ‘customer’ maintains ownership. We’ve probably all heard the phrase The customer is always right. This still shows itself even in the tech industry. As a result of trying to build a project and get it off the ground, it often happens that we tailor everything to the customer. It’s not uncommon for these style companies to become Yes Man companies. A company that, to please a customer, will cut corners and say yes to any request a client makes, regardless of the potential results and how much value it adds for other customers. Additionally, these often tend to be gut-response requests that are done almost immediately without any actual realistic planning.
The movie Yes Man starring Jim Carrey demonstrates this mentality and the resulting fallout from an individual perspective.
Instead of allowing the engineers to be an expert in their domain, we instead insist on doing whatever we can to make the customer happy. That is to say, the engineers aren’t allowed to own the product in favor of a happy client.
The problem you begin running into with this mentality is that it ends up creating two very repeatable, very real issues. The first issue is that as you continue to cut corners, you are driving up your Technical Debt in a very aggressive manner. More often than not, the corners cut or the custom features are done in a shotgun approach that leaves little room for future planning and management of the software.
The second issue is that as your Technical Debt continues to be driven up (because you never have time to pay down the Technical Debt), you will have to start cutting additional corners to get around issues caused by the corners you’ve already cut. You are putting in workarounds for the workarounds. Furthermore, you’ll eventually reach the point where you will come to a full stop and have no choice but to pay down the debt.
I have seen this scenario time and time again when it comes to keeping third-party packages up to date. With PHP, upgrading Composer packages is easy, but with all the corners cut and the lack of automated testing, any upgrade you do is bound to have backward incompatible changes that you have no way to find quickly. The issue is that since you’ve spent so long not upgrading, you now are on an outdated PHP version and your hosting vendor is no longer supporting it. All Stop.
What does it mean to be an expert in your domain?
Let’s change subjects for a moment. I want you to imagine for a moment that you suddenly get really sick. What do you do? Obviously, you jump on WebMD and research all your symptoms, and determine that you have some random cancer that you cannot pronounce. You find out that there is a medicine you have to have to live, so you go to the doctor and tell them what your cancer is and tell them what prescription to use, even if you can’t pronounce it on top of it being several thousand dollars a dose. You’re an expert, so clearly you know what you need.
Let’s be real. No doctor in their right mind would just hand you a prescription because you tell them to. So, let’s rewind that and redo it.
You may spend some time looking on WebMD, but you know you’re not a doctor and could be panicking for no reason. So you go to the doctor. You tell the doctor your symptoms, and the doctor asks you several questions. In the end, the doctor tells you that you have caught a bad case of the flu and prescribes you a simple cough medicine.
When you visit the doctor, you expect them to be an expert in their domain. You don’t tell them what to do or how to treat you. You expect them to use their knowledge and experience to tell you. In other words, you expect the doctor to be an expert in their domain.
While I consider the ‘doctor’ example to be the most relatable, you can easily substitute it with plumbers, chefs, or even taxi drivers. The point is that you expect them to use their knowledge to help you as you are their ‘customer’.
To be fair, I realize there are going to be exceptions to this rule, but I’m focusing rather exclusively on the 90% of realistic scenarios.
Owning your Role
So, let me ask this question: If you expect your doctor to earn the money you have to pay them, are you doing the same? Are you being the expert you are paid to be?
It boggles my mind to see how frequently people fail to have this ownership, especially software engineers. Rather than being an expert in their domain, many are perfectly fine with putting their headphones on and coding the day away.
You can be an expert in your domain, but not be owning your role. Coding isn’t the only thing to being a software engineer.
Owning your role isn’t just about coding. It’s about owning your product as well. Planning, thinking about what the future can hold for the product, and doing everything you can to ensure a quality product are all part of owning a role. Many engineers are happy to code new features, and some refuse to do anything but new features. While no engineer wants to spend all their time on maintenance, owning your product means acknowledging it as required.
Let’s go back to the earlier package example. As a software engineer, you know that software is constantly getting updated. Even if your software isn’t, the supporting software and underlying SDKs are. Further, you also know that the longer you take to do this upgrade, the more work it’s going to take to do the upgrade. On top of this, what happens if a security issue like the Log4J CVE-2021–44228 comes up? This was a Zero Day bug that affected thousands, if not millions of applications. Companies had to drop all work to fix any broken applications immediately.
Taking ownership means that when you see a problem, you bring it up. The greater the problem could affect the team in the future, the louder you have to be about it.
Taking ownership means that you ask awkward questions like ‘Does this work actually provide value for all our customers?’ I have seen (and made) plenty of ‘awesome’ features that took weeks, if not months, only to never have a client actually use the feature and then it later is removed.
Taking ownership means that you can admit that the current process is flawed and changing one step will eliminate hours if not days in the test process.
Taking ownership means that you acknowledge that, sink or swim, you and your team are in the same boat. If one person starts to get behind, you have an obligation to help them get back on track.
Owning yourself
While ownership does focus on the product, it also focuses on yourself. To be honest, it’s really difficult to own the product if you fail to own yourself.
Taking ownership means acknowledging your mistakes.
Taking ownership means acknowledging what you know and what you don’t know, and being open about it.
Taking ownership means not playing the blame game when something breaks or goes wrong.
Taking ownership means being honest with yourself and others about how good you actually are.
Don’t be a Donkey
Something I have to address when talking about ownership is that it doesn’t take an ego to be an owner. The moment you start getting an ego is the moment your co-workers start to hate you. Just because you know a lot, it doesn’t mean you’re the smartest at the table, nor does it mean you are the only one whose opinion matters. If anything, the greater ownership you have, the more humble you will become in the eyes of the beholder.
I was discussing a project with a co-worker once and this co-worker went in and did a lot of hard work, taking several weeks to complete. Their team lead at the time didn’t like their work, so the team lead went in and changed half the code, and never explained why they changed it. This is something I have seen multiple times in my career.
These types of people make other people want to quit. Being an owner equally means not being a ‘donkey’ to everyone else on the project. As I said above, you all sink or swim together. It is entirely possible, and honestly necessary, to have candid conversations without fear of being ridiculed by your co-workers.
When I talk about ownership, being willing to admit what you don’t know is equally important to what you do know. I’ve certainly read (and experienced) my fair share of ‘stories’ and I can assure you that anyone who knows their domain will be able to tell if you don’t know yours. The only ‘ownership’ you are showing at this point is job security, and that has no benefit to the product, company, or your co-workers.
Sadly, while I say this, in my experience, the people who fall into this category tend to be the type that don’t recognize there is a problem. They will deny there is a problem, even if you prove them wrong. Seeing as in my experience they tend to have a fixed mindset, I’d be surprised to even find them reading this.
Common Scenarios
Now that I’ve explained what it means to take ownership as a soft skill, I want to spend some time discussing some of the common scenarios I’ve seen throughout my career and what you need to do to start taking ownership in these scenarios.
Before diving in, it is worth saying this: In most instances below, one responsibility will remain the same. Specifically, you must be able to stand on firm ground. You need to establish what needs to be done, why it needs to be done, how long it’ll take, and the fallout or risks if you do it later versus doing it now. You will need to be clear, upfront, and direct while maintaining a humble disposition. Don’t be a donkey!
There are higher priorities/We have no time
More often than not, this comes from the Product Manager. Don’t get me wrong, it’s their job to drive the product from the business side. It’s your job to drive the product from the tech side. While not an exact analogy, your relationship with your PM has to be that of a sibling relationship, not that of a marriage or partner relationship. It must be mutually respectable, with you working together towards a common goal. You may get into heated discussions, but go for a beer afterward.
Every Product has some form of ‘cycle’ or ‘iteration’. This could be Agile sprints, quarterly releases, or ‘the next priority’. Once you establish this cycle, you must ensure that AT LEAST 10% of your capacity is focused on Technical Imperatives. Whether this be something simple like upgrading packages to the latest patch version or something major like upgrading your underlying SDK/Software to the latest major version, you MUST plan for this. Paying down Technical Debt, Upgrades, Refactoring, CI/CD, Automation, etc, are all things that should be classified as Technical Imperatives.
While I say 10% above, I prefer a 20% minimum instead.
It’s cultural
Sadly, I know what you mean. Multiple times throughout my career I’ve worked with people on an international level. It was especially apparent in specific regions. What often stands out to me is that those on the tech side will frequently openly admit things need to change when pushed for answers on why things are the way they are. More often than not, they quickly become defensive when pushed for answers. While I can’t be sure, in my opinion, there is an underlying fear that drives these responses. I’ve not quite determined what that fear is exactly, but in my opinion, it seems to be related to job security.
The best thing to do is to maintain your ownership, even if your cultural co-workers are unwilling to be owners too. You have to be the one bold enough to bring up these discussions.
I’m going to be honest: You’re likely going to make enemies and burn bridges in this process, so still make sure to tread carefully. You will have to make decisions about which hills you are willing to die on. I wish this wasn’t the case, but I’ve yet to figure out the best way to break down the cultural wall.
It’s the way we’ve always done it
This phrase is something that never settles well with me. I realize that there are times when you may have to do it a certain way, for reasons outside your control (IE: HIPPA). Furthermore, it’s possible that doing it the way you want to may lead directly to issues you are unaware of.
However, in this particular scenario, part of your ownership is a willingness to question and even change the status quo. Equally important in this scenario, is part of your ownership is understanding WHY it’s being done the way it is. You may find out the why and start scratching your head. On the other hand, you may realize it’s a necessary evil to meet requirements, business or otherwise.
I have no choice
This is another place where you have to make sure first you understand WHY. Why do you think you have no choice? As I mentioned before, I understand that there may be reasons like HIPPA, Legal, or some other regulation that prevents you from suggesting changes, much less enforcing them. However, this doesn’t lessen the need for you to fully understand the ‘WHY’. There is nothing wrong with not agreeing with the ‘WHY’, but you must understand it too.
Something I like to do is what I refer to as the ‘Why Game’. Simply put, if you don’t know the underlying reason for something, ask ‘Why?’. When you get the answer, ask ‘Why?’ again. Keep asking ‘Why?’ and you’ll eventually understand the true, underlying, reason.
We have no choice.
Why?
Because our boss said so?
Why?
...because they are in charge?
[Okay, but] Why [did the boss say so]?
Something about we aren't allowed to.
Why?
I think there were legal reasons.
Why?
If we do, we'd violate the client's SLA.You will undoubtedly come across exceptions to this. You have to be careful of going in circles too. I’ve seen many people get upset by doing this. Admittedly, even I have been irritated by this. However, I find it a necessary exercise. Utilized correctly, you will be able to find the underlying reason behind why something can’t be done. Once you do find that underlying reason, it’s up to you to make the next move.
What that next move is, will ultimately differ on a case-by-case scenario. You may decide that you don’t like the reason, but you at least understand it. At the same time, you may start a different line of questions. Using the example above, you can start asking questions like ‘Can we change the client’s SLA.’
In my experience, outside of Legal or Brand reasons, there is rarely a case where you legitimately cannot make changes. Mind you, you must take responsibility for anything you do change.
It’s not my responsibility
[Insert your favorite expletive]. This is in my opinion one of the most immature things anyone can ever say in their career. I’ve also heard comments like ‘I’m not paid enough for this.’
I’ve said this several times already, and I will say it again: Everyone on the team will sink or swim together. Taking ownership means you know that phrases like this will get you in trouble.
To be clear, it is not my intent to bash anyone who genuinely considers themselves painfully underpaid, overburdened, or stretched thin. If you are in this scenario, then by all means please focus on improving your situation, but don’t lose sight of your ownership. You can, and should, still show your ownership even if you are in a difficult situation, but don’t burn yourself out over it. If it is so bad that you have lost interest in the product or truly believe that your only option is to say something like this, then in my opinion you’re burnt out and it’s time to move onto a new position you can be passionate about.
Conclusion
In my opinion, the level of ownership a given person has will have a direct result on how far someone can go in their career. If you’re the type to own nothing but writing code, chances are that you’re never going to get it to be more than where you are now. Ownership will not only elevate your career, it’ll also help dictate the direction of the product as a whole.
While this article was mostly directed at software engineers, it is worth saying it applies across the board. For example, if the Tech Lead shows ownership for requiring an upgrade now, a Product Owner must show ownership by explaining why an upgrade cannot be done now. You have to work together in this regard.
Have an idea for an article you’d wish me to discuss? Please feel free to make any suggestions!
