Ownership Cracking this Concept as a Software Engineer

The concept of ownership for a software engineer is a bit vague in many companies but I will do my best to deconstruct this concept. Ownership is a requirement for Senior Software engineers and Software engineers who want to become Senior developers have to know or master this concept.

Simple Explanation of Ownership

When you own things you care. If you own a nice laptop, for example, you will do your best to not damage it and will always keep it up to date to avoid security problems. The same is valid if you have a blog website and you want to keep publishing posts, fixing performance and security issues, making sure you provide good content for your audience.

If you own a nice car, you will make sure it works well,  you will also fill the gas tank,  keep it clean, and will maybe do some improvements. Simply put, when you own something, you don’t need to wait for others to solve your problem. You take action and you get things done. In the example of the car, let’s suppose your car broke down, it’s your responsibility to take your car to the mechanics and get it fixed. This is the concept of ownership, you make sure that whatever you own, is working in the way it will best suit your needs and others.

Practical Ownership Situations in the Market

In the real world, there are a couple of scenarios where ownership takes place. I will list a couple of situations where you can use ownership:

• When you get a task
• When you are in a meeting
• When you create a Microservice architecture
• When you see a process problem in the company
• When you see a code problem that will affect the company profit and productivity
• When you see a problem in a long-term company objective

Let’s see those points in detail in the following topics.

Taking Ownership of a Task

When you get a task, you are responsible to get it done from the start to the end of it. Taking ownership of this task means that you will communicate with your team often enough so that you will be able to reduce the risks of not getting your task done in a reasonable time.

Suppose you get a daunting microservice to get done, then you are responsible to break down the complexity into smaller tasks, understand the big picture scenario. You have to make questions to your stakeholders, it can be product people, your software engineer colleagues, anyone who will get you the clarity you need to get your task done.

You have to make sure you have answers to the following questions:

– Why do I need to create this microservice? What is the purpose of it?
– What do I need to get this microservice done?
– What is the technical architecture/strategy I am going to use?
– What are the possible risks of not getting this task done?
– How does my microservice fit in the big picture product of the company?
– What is the business value of my microservice?

It’s very important that you create a document answering all questions I mentioned above. This will massively help you to understand the big picture of your task. Once you have this document done, it’s time to hold yourself and your team accountable by sharing the document either in a meeting if you feel it’s necessary to or on your chat service such as Slack. To decide whether you share your document in a meeting or in a chat, you can use your judgment by asking yourself if a meeting is really necessary.

If you feel there are many questions and a reasonable context to be explained for your team, you can use both. You can share your document with your big picture view of the task and you can also schedule a meeting with your team so you can present and discuss the strategies from your document. It’s highly important at this point to make sure you understand what you wrote on your document, if there is anything that is unclear, revisit your document, ask questions to your stakeholders, do whatever it takes to make it clear. By doing that, you will get the best value from the meeting since you will be prepared for crucial discussions.

If you feel you don’t need necessarily to create a meeting to discuss the ideas of your document, in other words, if your document is simple enough, then you can simply share it on your chat service in a space you know you can find your software engineers co-workers.

Another great benefit of creating a document in a centralized place is that everyone can see it and it’s also an artifact you generate for the company. Therefore, you make it easier for others to also understand the context of your task and in the case, you get sick or leave the company, others will be able to continue your work.

Taking Ownership in a Meeting

When you are in a meeting, you have to make sure you understand the context of what your teammates are doing. That’s because sooner or later you will be impacted by that if you don’t get what is being explained. Sometimes meetings can be boring, and it can be difficult to keep the attention. Fortunately, you can use some techniques and strategies to understand the content of the meetings better by:

• Engaging in the meeting: try to make a question that might help you understand the big picture. Be careful with your question though, if you feel your question is too basic and you are expected to know the context already, you might be negatively judged by your teammates and you can also take out the focus of the context only to answer your question. Therefore, if you feel that you can look for your answer on Google, or if your question is company-context-only, try to contact someone after the meeting and clarify your doubts. By doing that you will be saving time from others, you will be showing ownership because you are going after the knowledge you need.
• Taking notes: when you don’t have much context about the meeting, it’s even difficult to make a question. If you don’t make a question or don’t engage in the meeting, the chances are very high that you will get distracted by something else. One very useful and powerful technique is to take notes on what is being said, you don’t need to take notes about everything, only on the important points that are being discussed. By taking action on that, your chances to understand the context will be much higher, you won’t get distracted, and also you will be able to share your notes with your team. That’s a way to show ownership because you show that you are interested in the meeting, you share value with your team because they might have forgotten some detail, and most importantly, you understand the discussed concept much better.
• Speaking up when a risk is detected: Often enough, you will notice by your experience that something bad might happen if the decisions of the meeting are applied in the company. Therefore, it’s your job as a software engineer to point out what are the risks, what are the solutions to avoid the risks and a plus for you would be to try to be empathetic and persuasive, remember that most people don’t like to be told what to do. They prefer you to make a thoughtful question so that they come to the conclusion themselves.

It’s also important to understand that you don’t need to be talking about anything in a meeting just to show presence. To make noise in a meeting is usually worthless and only takes precious time from everyone. Therefore, anything you say in a meeting, try your best to create value with questions, suggestions, opinions, and healthy discussions.

Creating a Reliable Microservice Architecture

Nowadays, with microservices, the ownership culture is more present than ever. That’s because services are usually decoupled from each other, also developers have to make sure their microservices are working properly providing the value it’s expected.

When you are in the process of doing your microservice architecture there are a couple of actions you can take:

• As always, make sure you understand the big picture problem by creating a document with macro-level questions:
  • Who is the user of this microservice?
  • How many users will be accessing this microservice?
  • What is the business flow for this microservice?
  • Does this microservice need to be highly scalable?
  • What are the SLA(Service Level Agreement), SLO(Service Level Objective), and SLI (Service Level Indicator)?
  • Is there a standard framework in your company to build microservices? If so, will you be using it? If not, why?

Once you have a high-level view of your architecture design, then you share your ideas with your team and discuss the possible risks of using the architecture you decided. The possible risks are that your architecture might be too complex, not scalable, not maintainable, or there might be something in your way in terms of company processes. Sometimes, for company policies, we are unable to use certain technologies, therefore, a task would be much more complex because you would have to persuade high management to use that technology and that can easily take months to be accomplished.

Taking Ownership in a Process Problem in the Company

Many companies still fail in the processes, some are too disorganized, don’t have a framework to get things done, and here you have two options, to take ownership and look for solutions or complain and whine. Therefore, it’s much better to think of a solution that might solve this issue in the company and take ownership of that.

Let’s put the following scenario, the company just got started in a country and it’s struggling to have clear requirements, you have to contact external teams in other countries, you don’t know exactly who to talk to, there is also the challenge of timezones.

To contact external teams, you have to work until late or wake up very early. But then you figure out that offices that got started in other countries are not going through the same challenge where your office got started. Therefore, one obvious action to take is to ask those teams at those offices what they did to have clear requirements. When you take this action, you are taking ownership. As a software engineer, you are not even expected to take this action but it doesn’t matter, your goal is to solve a problem that is really serious in the company. You don’t need a title to be a leader or to take ownership.

Then you might figure out that the gap that is missing in your office is that there isn’t a Technical Project Manager in your team in a strategic timezone position so that requirements are collected often enough and synchronized between your office and external offices. Another crucial role from this Technical Project Manager is that she will figure out what is the point of contact that will be crucial in your task implementation.

There are a lot more common processes problems in companies. Another serious problem is when security is compromised and there is no action being taken to mitigate that risk. An example of your take ownership of that is to identify those problems and propose a plan of action to solve those issues. A security issue might get a company bankrupt or take serious damage.

When the culture in the company is toxic, this is a very serious problem. You can also take ownership and give suggestions to the management to reduce how toxic is the company. This is another example of taking ownership, you propose a culture of knowledge sharing for example. By doing that, you reduce unhealthy competition, you also reduce fear of people being fired.

Fixing Bad Code and Bad Practices

Bad code, bad architecture, and bad practices are unfortunately present in many companies. Some companies are still using very old versions of software, frameworks that are obsolete, or even worse, internal tools that are maintained by the company. To reinvent the wheel by creating internal frameworks is usually a bad idea since the company will have to maintain that tool.

Bad code is usually caused by a problem in the company process, sometimes short deadlines are imposed on developers and they have to deliver it no matter what. You can also take ownership in that situation and say no, you refuse to create a low-quality throwaway project just to create numbers. You do that not because you want to create high-quality code but because you know this is harmful to the company, you know there is an issue in the company process. When you see software engineers stressed out, managers desperate to deliver features, you know that there is something wrong.

You have to work hard on your persuasion skills, you have to understand the big picture of what is going on in the company. You have to figure out what is the root cause of this problem. If you notice that the problem is at the CEO level then it’s a very difficult problem to solve but you still can try to solve it. You can create a detailed presentation explanation of why this is harmful to the company, showing numbers, how many good developers are leaving the company, the stress level in the team, the number of bugs, the number of paid hours from developers to solve bugs… You have to make your case to convince your manager, CTO, CEO that this is harming the company’s profits and the long-term growth of the company will be certainly damaged.

In Conclusion

To be a senior software engineer, it’s very important to have the concept of ownership clear in your mind. I deconstructed many situations where you can apply actions that will show that you have ownership. In other words, taking ownership means being a leader and getting the job done. By taking the actions I explained you will for sure become better at taking ownership and will be able to go to the next level in your career.

Don’t forget to leave your questions/comments/suggestions below so we can take this discussion even further!