This happens in web development, too. Except when it comes to launch, there’s no grading scale– it’s “Pass” or “Fail, or rather “Go” or “No Go.” To mitigate the risk of a failing grade, we introduced the concept of a Closer. A Closer is a developer who takes over for the project’s original developer in its final stage to plow through launch blockers and help successfully launch it. Just like in Quidditch, the late stages of a project, an original developer may need to be removed from low-level production due to fatigue or for other strategic reasons.
Recognizing the signs can be tough, and varies from person to person. It’s always a good idea at the outset of a project to ask all project team members what their personal signs of stress are, so the project manager can recognize these. But no one is 100% self aware. Some identifiers we keep our eyes peeled for include:
- Overall decreased velocity
- Confusion on previously established project goals
- Frustration with a seemingly never ending list of items
- Over-attention to details that don’t impact the finish line
- Avoidance of launch blocking tasks
- General heightened anxiety about launch
Once the need for a Closer has been identified, a grace period occurs where both the Closer and the original developer work on the project simultaneously. The Closer will gradually take on more and more of the tasks from the original developer, but the original developer will never completely disappear, staying on in a consultative role.
A Closer may take on all the remaining launch blockers, or only a portion, but a Closer should never be brought in without project context. Ideally, multiple potential Closers are identified and included at development kickoff. Closers should follow the project at a high level until they are tapped. One or more Closers will tag-in depending on their respective availability.
Closers should be given specific tasks with very specific instructions, and they should be encouraged to ask questions of the original developer and the project manager. Closers should not be developing entirely new features. Closers should only be used to wrap unfinished work.
Project managers should be clear with Closers about expectations around task priorities and ultimate launch timing. Project managers should also communicate what a failure to launch means, but from a place of transparency and client empathy rather than as a fear-based motivation technique.
Aside from the benefits to velocity, Closers bring an outside perspective to the project that can offer feedback to the entire project team during a retrospective. Tagging-in under pressure creates an opportunity for developers to interact with each other’s product and see what’s easy to work with and what isn’t. Closers, with their fresh mindset, bring a boost of morale to the project team in crunch time and combat developer burnout at large.
For project managers, Closers provide a side-by-side comparison of developer styles in the same environment. Project managers are naturally compelled to maintain a consistent management style that works for the whole team, to make the transition as smooth as possible.
Closers help us not only provide better service to our clients, but strengthen the bond of our team. Closers are a great way to make every project an epic win.