Article summary
Projects with big teams introduce a slew of interesting problems–problems like keeping developers fed with multiple tracks of work, understanding areas with large technical risks, and sharing knowledge. On a recent project, we developed a role to help solve these problems. I call it the utility player. In this post, I’ll define the role, the required skills, and my experience in the role.
The Role
The utility player has four primary responsibilities. In order of importance, they are:
- Keep the team moving
- Complete technical spikes and chores
- Help other roles
- Improve development quality of life
1. Keep the team moving
The most important function of the utility player is to keep development moving. Teams get stuck for a variety of reasons, such as waiting for help to make technical decisions or debugging an issue in the code. In any case, the utility player is responsible for jumping in to get the rest of the team over the hurdle. Because their success hinges on availability, the utility player should be interruptible nearly all day.
2. Complete technical spikes and chores
When development is running smoothly, the utility player’s most valuable responsibility is completing technical spikes and chores. This work complements the top priority of keeping the team moving in two ways. Because the work is independent, the utility player is easily interruptible for questions or issues. Also, technical spikes should produce more concrete work for the team, keeping them fed with stories.
3. Help other roles
Developers aren’t the only team members who can use extra help. The utility player should feel comfortable working with all other roles on the project, including the delivery lead (or project manager), tech lead, and design lead. One day, the utility player might work with the delivery lead to create more actionable work for developers. Another day, they might work with the design lead to generate wireframes for a new workflow.
4. Improve development quality of life
The final responsibility of the utility player is to improve development quality of life. This encompasses a wide range of possible tasks including better automation of deployments, better tools for automated tests, and small refactors to improve code quality. Again, this keeps the utility player available to the team for their top responsibility.
Who Should Fill It?
The utility player should have the following skills:
- Experience in the tech stack
- Ability to context-switch quickly
- Ability to “zoom” in and out
1. Experience in the tech stack
The utility player needs to have the technical answers. Therefore, it’s important that they know the tech stack, including conventions, best practices, and limitations. The utility player should rarely need to pull the tech lead in to answer a question, especially when it comes to purely technical questions. The goal is to have one person constantly available and interruptible. The more people the utility player has to bring in, the more development slows.
2. Ability to context-switch quickly
A utility player should welcome interruptions. This supports their top priority of keeping teams unblocked. It also allows them to work within other roles on the team. They should be efficient at handling these interruptions and getting back to their tasks as soon as the interruption has ended.
3. Ability to “zoom” in and out
A utility player needs to be able to dive deep into technical details, while understanding the overall approach to a solution. This skill helps them give strong recommendations to teams that run into problems. It can also help them pair more easily with other roles on the team. If they understand the domain and the project goals, they can be effective on the project-planning side as well as the technical side.
My Experience as a Utility Player
I recently had the opportunity to play this role on a large project. I personally enjoyed the role very much. It was a great mix of technical research, sharing past experiences, and energizing the team. I had the opportunity to dive deep into technical issues, and zoom way out to have discussions about the product vision. I learned a lot about effective context-switching.
Also, I saw the benefits this role had for the rest of the team. It allowed less experienced developers to take on more responsibility, knowing they had a resource to lean on if needed. It gave developers someone to be in the trenches with them when they were debugging a nasty technical issue. It gave the delivery lead a trusted person to whom they could delegate backlog refinement and technical research tasks. There was someone on the team that could recognize patterns between parallel tracks of work and bring consistency to the codebase.
Overall, I’m very excited about the role and am looking forward to refining and improving it on future projects.