Many companies are suffering from a lack of ownership problem in the projects they have. The ownership problem is ingrained usually in the culture and process in the company.
When there is no ownership in projects, developers will probably take a lot of time to solve something that should be simple. The business people will get frustrated because it’s hard to collect requirements. The company will suffer the impact, products will have less quality and will have to be rebuilt more often. When there is no clear understanding of what is being built and the teams don’t really own their projects, they will push to implement a solution that is not ideal just to make it work.
It’s very common to see legacy bad code in companies. If there is no owner in such a project and if someday maintenance is necessary, the team who gets this responsibility will certainly suffer. Projects that were built in a rush to deliver business value don’t usually deliver high-quality software.
With no ownership, it’s easier for the company to develop a toxic culture of blaming each other. It’s very easy to point fingers when there is no owner in a project, anyone can be blamed. The lack of ownership problem triggers other very serious problems for a company. Lack of ownership makes developers demotivated, developers leave, the company will have a lot of work to hire new developers.
Therefore, it’s a very important topic to be discussed, even if it’s not exactly technical.
Why there is a Lack of Ownership in Companies?
When a company is still small, the lack of ownership doesn’t cause a big impact. The negative impact starts to raise when the teams start to grow and the understanding of other projects becomes necessary. Usually, in young companies, they don’t develop high-quality code in the beginning, they instead develop something that works to validate the business. Once the company has its business validated with a high level of cash-flow, then they decide to invest in code-quality and infra-structure.
When the investment in code-quality and infrastructure becomes a priority and teams start to grow, things get difficult. When a company is small, there isn’t the need for ownership, everyone usually owns everything. However, when projects get bigger, it becomes impossible for developers to know all projects. It’s necessary to separate responsibilities between teams where each team is responsible for their own project. By doing that a company can be far more effective, deliver more, and profit more.
As we are in the cloud era, many companies who aren’t in the cloud are moving their projects to the cloud. The moving to the cloud is intensifying the lack of ownership problem but in my point of view, it’s still not the root cause of the problem.
Not having a clear vision of the future of the project is another reason for the lack of ownership. This happens because, with no clear vision, projects that shouldn’t be ignored are ignored, and then when maintenance is necessary it becomes a nightmare for developers.
The business is another key player for ownership in projects. To acquire business knowledge takes time, in any company. If there isn’t ownership for projects in the company, chances are that many features will be implemented in the wrong way. Software development is also an area where developers change jobs very often. Therefore, to bet on developers that will stay in the company longer is a recipe for disaster.
To make new developers absorb all the business quickly from the company is to wish the impossible. It’s better to be strategic instead, to plan ahead of time to leave each team with a part of the business. By doing it that way, the teams will have a deeper knowledge of each part of the business, they will develop more quickly, things will be more smooth. It won’t be necessary to understand the whole business of the company, instead, it’s necessary to understand the specific business area.
Teams who are responsible for many projects are also the one root cause of the lack of ownership problem. That’s because teams who ‘own’ many projects become overwhelmed very quickly, they are usually not able to handle such high demand. Instead, those teams should pass on the knowledge to other teams but due to short deadlines, they postpone this action again and again.
Lack of documentation about the technical and business knowledge of the project is another root cause. When there is poor or no documentation at all, it’s very difficult for teams to take over a project. Without documentation, the teams need to dig into the projects and figure it out by themselves. This is possible but it takes time and the possibility to implement something wrong is very high. What happens is that the teams will waste a lot of time, will re-write solutions very often and it will be stressful.
What is the Impact of Lack of Ownership for Software Developers?
The impact is really big not only for developers but for the whole company. When developers waste a lot of time to implement a feature in a project nobody owns, the business suffers. The day-to-day work of developers becomes stressful.
Usually, when developers don’t own projects, the code start to rot gets confusing and nobody will be willing to touch that code. Then things get really complicated because the code is no longer understandable and it’s very difficult to implement anything in a project nobody owns.
It’s very stressful and frustrating for developers to figure out a project quickly to implement a feature. Sometimes, weeks are wasted to implement a simple feature.
Another very stressful factor is that when there is no ownership, we don’t know who to ask for. When working on a new project, we will have questions about the business but when there is a lack of ownership, this becomes challenging. Very often we have to ping and ask around people in the company to hopefully find an answer. This process leads to a great waste of time and energy only to figure out who to ask. Sometimes, we even figure out that there is no one to ask about this solution, then we have to simply dig code, and hope that the solution will be correct.
It seems to be a simple and inoffensive problem but it actually causes a lot of stress and frustration. Software developers inevitably feel the impact when the company is struggling to define a strategy to action.
When the infrastructure is owned by the ‘DevOps’ team this causes the lack of ownership problem as well. The negative impact of that is that developers will tend to throw the blame to the ‘DevOps’ team in case something goes wrong and the ‘DevOps’ team will do the same. To avoid this fight between ‘DevOps’ and developers, the company should allow developers to work on the ‘Ops’ side and deploy their applications.
The ‘DevOps‘ culture is even more crucial when we are working with microservices. Most of the companies nowadays are using a microservices architecture. If there is no ownership between microservices, then things get very complicated. Let’s suppose a new team has to create a new microservice and it’s not clear how security is implemented for all microservices. Then, again, we would have to go through the process of asking around to figure out who did it. Then we would have to go through the code and someway connect the security project to our microservice.
What is the solution for the Lack of Ownership?
Only a structural change in the company teams can solve the problem. Defining and planning ahead of time the teams who will work for each project is a great step to solve the lack of ownership problem. Other than that, it’s also important to have the DevOps culture well implemented in the projects. If only the infra team is responsible for the infrastructure, the concept of ownership is broken again. Developers have to also be able to deploy the application to production as well. With a mature process of continuous integration and continuous deployment, this is possible.
Teams who are responsible for many projects should instead, pass on their knowledge to other teams. Teams should also create high-quality documentation about the technical and business knowledge so other teams can have a reference to take ownership of the project. If there is well-organized documentation in a central source such as the most currently popular, Confluence, developers can take over projects in the company far more easily and onboarding new developers become easier.
A clear vision of what will be the final product is also crucial to avoid the lack of ownership problem. If the vision of the project is very abstract and developers have yet not understood the big picture, developers will be confused. It won’t be clear for developers about what they will be developing.
How to develop a clear vision of the project? Meetings should be arranged between the most knowledgeable business and technical people to develop the big picture vision. Once the big picture is developed, each team should ideally have a business person in their teams to clarify the business idea.
The management team of the company should implement a plan for a structure where developers know clearly what to do. Developers can also take charge of this problem by proposing solutions with a presentation for example. Remember that no one needs a title to be a leader. You have the choice of being a victim and be complaining or take charge of the situation and take action.
Conclusion
In a company where there is a lack of ownership problem, it will be usually very hard to deliver business value. Therefore, the company stakeholders should get involved in this problem to figure out a solution. Even if your action is small, this action will count. With one small action you influence others, if others take also a small action to improve the company culture, those actions will get multiplied.
Don’t wish others to do something different and don’t do something wrong just because the others do it. Be the change you want to be in the company, take the actions you think will improve this situation. If you take small daily actions you will get better as a professional and will increase chances of changing the situations for the better. It’s not an easy problem to solve though, culture change takes time because it involves many people. But with your consistent actions, you make the change you want to happen.
Don’t forget to leave your comment in this article, any questions, observations, suggestions, feedback are all welcome, I will make sure to answer you as soon as possible!
Thanks for very informative article. Well I would be very interested in your opinion how as an individual should approach strategically. Because companies don’t run only based on your suggestions. Its more of stagnant what’s already there. As I understood this is more of generic approach which is very cumbersome in practical world. If you can write on a developer stand point then that’d be beneficial. Thanks