Code Ownership is something nobody really talks about but as a fact it’s one key factor to motivate your developer teams.
What is Code Ownership?
Code ownership means that the technical responsibility lays by the people working on it.
In my opinion there are two categories in this:
- A service, product, domain, feature… is solely developed by your team.
- You are the only team develop in this code base
- If another team else wants to change something – you still do it or at least provide approval of the pull request. Later one only in tight project priorities.
- How much freedom you have to decide on technical decisions
- Core technical decisions are already done on management or architect level? Are you allowed to use a different language than Java? Who decides these?
What is the current situation in companies
This varies a lot in different directions. That’s why I wanna give here some examples.
Project focused – sharded dependencies
In project focused companies there is a tendency to shift around people or domain ownership to get a project faster delivered.
For example. Let’s say you want to implement a new payment method for your customers.
There are some possibilities how you implement it. You probably have a backend team to take care of connecting to the payment provider. You then also need a team that updated the website to show and handle the payment method correct.
This example sounds simple. But what if your backend team is implementing already something else in the same time you want your frontend team to work on it.
Normal solution is trying to find a shared time slot in both teams to get the project done in time.
But due to shifting in priorities of projects, bad ratio in teams to domains, no one saying No to a project, etc. It can happen that suddenly you find another team with a free time slot that will work on the domain as well. Taking over ownership completely of a service for example.
The former owners of e.g. a micro service which didn’t have the time slot available has to do a hand over. The new team on the other hand has to adapt the service to its own way.
Both teams are actually not happy about a giving another team the Code Ownership.
Former owners because they lost what they were working on maybe for years. Your energy your work your passion everything you put into this is now just “gone”.
New owners because they own something which is not the way how they would have implemented it. Different library, code style, tooling or language is used as if it would have been implemented by the new team. Of course also they get something that feels not yet their own. It’s with everything new this will change over time while working on it. Yet this takes time.
Product Focused – family teams
In my former company our team worked on one monolith. We didn’t have much dependencies to other teams. So we could work quite well. There was not much thought about shifting domain. In the end the projects were shifted to fit the teams. This meant a lot of project management hell, but after a while it improved and improved. Because instead of giving the problem further down to the development team the project manager managed it.
It’s like a family where we strove to bring the best out of our product. We knew the pain points best and had good ideas how to solve them. You can then also over time gain a lot of passion towards the product.
What you should take out of it?
In general. Even in the best company at some point there is a change in Code Ownership. Everything evolves over time. The only question is are we talking about months, years or decades? Or the old product is going into maintenance, but no further development will be done on it.
Both extremes are bad to the people.
If you have like no code ownership then the people will just care less.
In the other extreme. If your people are very passioned about the product. Then lossing it can be very emotional for them. In extreme cases resigning from the company.
In my opinion it depends as always. Said that I go for trying to be product focused as it will immensely motivate the people to improve the product for a greater cause.
Keep your people motivated – with passion
As a developer the highest motivation is not the money, but the work itself. If you work on current technology and your project is interesting for the people that’s the best combination to keep your employees happy and therefore working efficiently.
In the end it comes down to how you manage your projects
Do you have top priority projects where all that matters it to get them done? Even though in the end you are shifting so much around with ressources that you loose efficiency and don’t get the small projects done that do some quick win but are not really on someones radar.
For example Java was released every couple of years until recently there is a 6 month release. For the developers on Java it’s a blessing. They are relived from the pressure and focus on single top projects like Lambdas (Java 8) or Jigsaw (Java 9). Which on one hand postpones the release further and further and on the other hand the other small features are getting lower priority though they are good and needed. (This is a true story told by Brian Goetz on one of the many conferences)
Make your product/project release cycle in a way that it won’t matter in the end when it will be released