As a tech lead on my project, I’ve witnessed the transformative power of the feature captain role. Let’s explore the concept, how we define this role within our team, the benefits of creating this role, and my experience with its implementation.
Defining the Role
Here’s how we define the feature captain role on my project team:
…a developer who takes responsibility for understanding the requirements, coordinating with stakeholders, defining work in the backlog, and ensuring a feature is successfully implemented per the specified criteria.
A feature, in this context, is multiple units of work related to a desired system capability. These are usually completed by other developers throughout numerous sprints.
The feature captain role bridges the split between the tech lead and developer roles. This means they have more responsibility for a specific feature than another developer but ultimately are not accountable for the software delivered. Instead, accountability still falls onto tech leads for the codebase as a whole.
| Task | Responsible | Accountable | Consulted | Informed |
| feature delivery | feature captain | tech lead | tech lead | project team |
Benefits of Feature Captains
Below are the main benefits of empowering developers to participate as feature captains.
Developers: Grow skill sets beyond programming by practicing the consulting and backlog work required to deliver valuable software.
Tech Leads: Gain bandwidth to mentor feature captains and focus on other facets of the project.
Client: Gets the ability to parallelize multiple tracks of work at once and more easily tap into the insights of other developers.
My Experience with Feature Captains
I realized the importance of feature captains when I became the tech lead on a complex project with a sizable team earlier this year. Despite the team’s support and a great codebase, I found myself in over my head by the project’s domain complexity and the sheer size of the larger systems we are working with.
To tackle this challenge, I delegated some story-writing responsibilities to developers who had more experience with the project. This allowed me to delve into existing feature work to gain a deeper understanding of the domain and tech stack. In turn, I paired with new feature captains, guiding them through planning and execution, while they collaborated with other developers to bring the features to life.
As feature captains take ownership of their respective features, they become the point person, streamlining communication with stakeholders and ensuring a deeper understanding of requirements. Meanwhile, tech leads can focus on broader project aspects, mentoring and guiding feature captains as needed. This parallelization of multiple work tracks increases productivity and fosters a sense of ownership and accountability among team members.
Adapting This Strategy
Finally, I think this role is appropriate for certain software projects and not others. In the situation I described above, a few traits help support feature captions.
- Large team (5+ devs)
- Long runway of planned features from designers
- Isolated units of work so devs aren’t stepping on each other’s toes
- Devs who want to grow and flex other skills
- New tech lead onboarding to the team
This isn’t an exhaustive list, nor is it meant to be prescriptive. Your project may have more, less, or none of these traits. The success of the feature captain role depends on the specific project and team dynamics. And, ultimately, the decision to embrace the role should stem from open conversations within the project team, weighing its potential value against individual project needs.
Overall, the feature captain role has been a boon for our software development team. As we continue experimenting with this strategy, we remain open to its evolution and refinement.