Structuring Your Team: Feature Owners
The growing importance of technology in the industry has caused a surge of technology focused jobs to be in high demand. It is not uncommon for businesses that use to rely on a few software engineers to employ thousands only a few years later.
These teams are typically split up by domain, for example an eCommerce website might split up their departments into Users, Promotions, Inventory, Orders, and whatever sub-systems they need. Then each department would have ownership of all the features in that domain, for example the User team may have enrollment, alerts, and account information, whereas the Promotion teams may be in charge of managing site wide promotions and product application.
As the technology in these growing companies has matured, so has the business requirements behind them, and with that the complexity and work needed to maintain them. I remember the only things we use to do with accounts was to be able to change our password, but nowadays the minimum is to be able to set two-factor authentication, link some single sign-on provider, and now wipe all your data from their servers — along with all of the subtle cases that come with each of those features. It’s beginning to become harder to manage the size of our teams when we can no longer divide them between domain boundaries.
And that’s where Feature Owners come in…
Feature owners is an extension of the idea that we can organize teams around domains, but applies it down to how to organize team members within the team. The basic idea is that we want to delegate responsibility for a feature to a person or a group of people so that they have extensive knowledge of that feature.
Why do we need Feature Owners?
Feature ownership will help you get the most out of your team and promote greater sense of purpose within the team.
Mastery
The need stems from a basic pillar of software development, and that is mastery. The quickest way to become proficient at something is to attain mastery in it, whether that be a language, a framework, and in our case a feature. By focusing your efforts on one section at a time, you will gain more knowledge and understanding than if you were to spend bits of time in between many features or systems.
Autonomy and Ownership
Feature ownership empowers developers to think about their work from a holistic perspective. How will my changes to this system affect the design of this system? How will they affect how this system interacts with other systems? How will this affect future changes to this system? By giving developers ownership of a feature, they will have the autonomy to make their own decisions and give them more gratification by having larger impact in that area. It should be highly suggested that they promote their own ideas for their features, which allows them to have input in the process, as well as potentially opening up more opportunities from a business standpoint.
Higher Code Quality
Feature ownership promotes code ownership, which is a key quality in maintaining strong code quality, as developers can be more effective by having experience with the feature and knowledgeable about all the past design decisions and business cases that have led to that design.
Efficiency
Teams stand to gain higher efficiency by being able to delegate tasks more effectively when it is known who knows the most about a feature. It is easier for someone with knowledge to work on a task, as well to know who to ask if you’re given a task for someone else’s feature. Managers stand to gain because less requests need to be routed through them, as it is clear to the team whose responsibility a task is. Decisions can be faster and more decisive when there is a final voice of truth that determines the outcome of a discussion.
How do I implement Feature Owners?
As with any other process framework, you will need to evaluate your team and domain and choose what works the best for you. In this section I’ll give you some guidance for how to setup the basis and you can make adjustments based on your situation.
Define Feature Boundaries
Features should have clear boundaries between what they own. One topic should not be owned by multiple features. If neither can choose who should own it, more often than not it should be it’s own feature. In service oriented architectures, you might have a service be a feature. You may also delegate team roles as features themselves, such as a team librarian or some development aspect such as continuous integration.
Organize Owners
Contrary to popular perceptions, Feature Ownership usually involves more than one person. At the very least a feature should have the primary owner and a secondary owner. The primary owner will be the traditional sense in that they own the majority of the code and knowledge, but there should be a secondary that also knows a lot of the system and be capable of taking over the feature in the event the primary is unavailable. It is also a possibility to have multiple primary owners for a feature, and sometimes may be expected if the feature is sizable and requires a lot of work. Collaborative work between developers is still an important aspect of this model, it is just that we want to make it clear who has responsibility and knowledge for a given feature.
Balance Ownership Load
Ownership is a huge responsibility, and bad ownership can lead to disaster for a feature if it is not take care of properly. To mitigate this we want to make sure that the team can share that responsibility in a manageable way. What I’ve done before is that when starting the process, rank the difficulty of the feature domain, as well as the amount of work being done in that portion. The points are then split up between who are the owners of the feature, and then the total points accumulated are aggregated for each person. From this view we can see who is taking on more, and balance where needed.
Get Your Team to Buy-in
The worst thing you can do is to force this process onto your team without telling them why. You will only cause bad feelings and lower quality code from dissatisfied team members. Feature ownership is a great opportunity for developers to express themselves and make their decisions mean much more. They have a say in the present, and future of the project, and have clear view of their accomplishments.
Have a Feedback Loop
Make sure that team members have a channel where they can provide feedback. Feedback can come in the form related directly to their feature — such as ideas about future innovation that can be done with it. For that case make sure there is a defined process for those to become materialized work. They can also come in the form about the process itself — such as if a feature may need to be split up further.
What to Watch out For
As with any design or process, it can have some drawbacks and you should be actively evaluating and enacting preventative measures against them.
Bus Factor
Bus factor is a measurement of risk by concentrating knowledge or other resources into a few individuals. In the case that the key member “gets hit by a bus”, how well will your organization manage the loss.
To mitigate against this, you can have multiple feature owners to have some degree of distribution of direct knowledge. Depending on the size and complexity of the feature, you will need to find a balance between efficiency and redundancy.
You should be actively promoting the documentation of both technical and business aspects of these features, and who better to write it than someone that knows the system in and out!
Isolation
The quality of a feature or system can quickly deteriorate if the feature owner does not take proper care of the feature itself. It is easy to put things off, or do things the easy way, and be generally negligent if you are the only one working in an area.
It is important that features still be worked on by other developers and input from other developers be received by the feature owner. Collaboration is still key!
Limitation
With great responsibility comes great responsibility, and I meant it that way. By committing to feature ownership, people now have the responsibility of maintaining that thing. That means that while other people can still work on that feature, the majority of the work should still be going to or through them, and they should maintain the overall direction of the project. By focusing on one part, you will have less exposure to the rest of the project as well as less mobility to work on other parts. This means that they are more limited from the total scope of the project.
We can still delegate tasks to other features to increase their exposure to the rest of the project. You should keep a pulse with each developer that they are happy for what features they maintain, and adjust as necessary if they aren’t able to put their full efforts as the maintainer of a feature.
Summary
Feature ownership is a way of organizing your team by defining features that each members are responsible for, which will drive higher code quality, increased efficiency, and higher developer satisfaction with their work. Even if your organization doesn’t explicitly follow this model, more than likely you follow an informal system where people are higher exposure to certain parts of the project. This is just a formal framework for that idea, but expands on it and gives more meaning to each member’s role. I highly suggest you try this within your organization, and see the difference it can make!
