Culture of ownership
Feeling responsible for our product
Responsibility in software development can manifest itself in many ways. Developers can be responsible for incidents caused by our code, misunderstandings about the requirements of what we are developing, or potential performance issues that our systems may have. However, our responsibility should not stop there. We should have complete ownership of our product or the project we are working on. End-to-end ownership that guarantees the highest quality and viability of the solution developed.
A shared ownership within the team obviously, and with well-defined scopes and responsibilities among its members, but an ownership that the whole team assumes and oversees on a daily basis.
Culture of ownership
Therefore, we as developers should also cultivate a culture of ownership over what we develop.
Before I go any further, just clarify that I don’t mean that we are responsible for all decisions about the product, but that we should get involved and feel responsible for its success. Within a team we are all rowing in the same direction and although part of the decisions are not our responsibility, we should ensure the success of the project and user satisfaction.
This means that we have collective ownership of the quality of the product we develop, how it fits the needs we are meeting and its ability to adapt and evolve.
Ownership over development
As developers, we have clear responsibilities and explicit ownership over the code we write and the systems we develop. As part of the collective ownership of the project, we must ensure that our individual contributions follow our quality criteria and contribute to the objective of the product.
This means thinking about the big picture and developing with a focus on our product and the problem we want to solve. It means ensuring quality and that the solution we are developing is as adjusted as possible to the needs and context of the product.
This involvement beyond the development of tasks reminds me of an example that clearly shows how developers can contribute by taking ownership of our product.
A team I’ve worked with at Mercadona Tech was implementing an iteration of a crate counting feature in one of our warehouses. It involved changing in some way the physical process and the tool that went with it. The problem was that the data did not show to be very positive, the count of the crates sometimes deviated from the real one and was not giving good results.
So design and product came up with a second iteration to further fine-tune the processes so that these problems would not occur. However, a colleague of mine who was involved thought it didn’t make sense, that there was to be something else behind those deviations in the crate count. So she started reviewing logs, checking the entire end-to-end flow and how workers were using the tool.
Eventually, she discovered that the new count they came up with had a basic problem as soon as two people did it at different times. She discussed this with the rest of the team and they realized the problem and found a simple solution to implement together.
This shows that feeling responsible for the product as well, she researched and became interested in the results they were getting. Although the team had prematurely concluded that the problem would be fixed with a second iteration, she didn’t give up and searched for the cause. Thanks to that, the product won and the team solved the problem in the best possible way.
Ownership is being responsible
To have ownership is also to be responsible: responsible for our failures and those of our team.
When we work as a team, we don’t have to see ourselves as different separate pieces that are part of something bigger. We are a single entity working together to build a product.
This means, for example, that if there is a technical problem, it is not a matter of the “Tech Lead” (who is ultimately responsible) but it should be a problem of the team. If there is a problem in the conceptualization of the product, it is not the designer’s problem, it is still the team’s problem (although I emphasize that this does not mean that there is no person responsible, there is still a responsible person but the whole team should feel ownership over the solution and ensure its success).
Because of this philosophy, this ownership requires something very important: a blameless culture. As a team we should not point out individual faults, but we should work together to solve the problems that may have arisen.
Ownership is communicating
Therefore, the fact that we have a culture of shared ownership requires that we communicate constantly. We don’t work in isolation, we work as a team and that means working together and in the same direction.
Here I emphasize how important it is to have a good habit of feedback where we are used to giving and receiving it. As I mentioned before, in the end the individual responsibilities of the team will be distributed among different people and roles, but it is important that we give each other feedback to be able to see other points of view and enrich our decisions.
For example, one of the parts I like most about my job is talking to the designer on my team about the solutions we are proposing, thinking about use cases and challenging them about what I may not have understood. I do it because I like it and because in the end I have that feeling of ownership over the product: not only do I implement it, but I ensure its success.
Ownership is knowing the problem
And finally, as I’ve discussed in previous articles, developers need to know more about the business than the business itself. And this is very much related to the issue of ownership.
To develop the best solutions, we need to know the problem as well as possible. And that means getting down into the mud, getting to know the user, understanding the physical process or the needs we are meeting and feeling it in our own flesh.
Cultivating a culture of ownership will allow us to create a product of the highest possible quality and will also make us proud of it.
TL;DR
Cultivating a culture of ownership goes beyond taking responsibility for specific bugs or problems in the code and extends to a complete commitment to the success of the developed product.
Shared ownership within the team is key, where each member takes on well-defined responsibilities, but shares overall responsibility for the success of the project. This ownership doesn’t mean making all decisions about the product, but about feeling responsible for its overall success.
As developers, we must also have clear ownership over the development, making sure that individual contributions meet quality criteria and contribute to the overall goal of the product.
To have ownership is to be responsible, both for successes and failures. It’s important to view the team as a unified entity, where technical or conceptual issues are problems of the team as a whole, not assigned to specific roles.
Developers need to know the business as well as the business itself. It is important that we immerse ourselves in the knowledge of the user, that we understand the processes and needs in order to develop the best solutions.
Cultivating a culture of ownership not only leads to the highest product quality, but also builds a sense of pride in the team for their contribution to the success of the project.