Shipping
After months and maybe years of stress, meeting, late nights, bug reports, dogfooding, requirements changes, dependency changes, management changes, user testing and actual coding, you're ready to ship your significant rebuild. What happens next?
There's often some kind of anti-climax at the launch. If your site has existing traffic, you can't just flip a switch. You need a/b testing, holdbacks, gradual rollouts, comms. It can take a lot longer than expected.
With an established software development team, you've probably pivoted the whole team away from the day-to-day mission, to focus on this rebuild.
Managers will be familiar with Tuckman's stages of team development: forming, storming, norming and performing. With any luck you'll be a fast efficient team in the performing stage of the project. Indeed, the smaller tasks near the end, where the team are very familiar with the code (because they've just written it), can feel the most productive.
Your team has been focussed on a mission. The mission was the project, and the project is nearing completion. But what is a team? It's a group of people with a mission. Without a mission, there's no team.
In 1977, Tuckman added a fifth phase "adjourning" to the model, recognising the end of the team, and to allow for a cyclic process for teams. What might that phase look like?
Folks will leave. Either the company or the team. It's likely many have stayed to complete the project anyway, and you'll have seen unusually low attrition for the last third of the project. That will catch up.
External stakeholders will come knocking. It's likely that you had to freeze some features or push back on requirements for the duration of your project. Those external partners will be expecting more attention, likely before you've even shipped. A human aspect is that they felt left out of your project launch and expect compensation.
Management will reorg. Rather than leave the high-performing team alone, senior management often sees this as an opportunity for a reorg. Like the external partners, they've seen slow responses to requests and received pushback on their requirements because of the long project. Perhaps your team has been left out of previous reorgs to keep the project on track. Senior management will be looking to normalize the team with the rest of the company, possibly simply by disbanding it.
From the point of view of the team, all of this can be stressful. The team likely has a significant backlog of technical debt which was taken on to achieve the deadline, there'll be an accumulation of key knowledge in the team which should be codified, there'll be bugs to address, there'll be cleanup tasks for the previous systems, especially if they're still running in parallel. With the team's future in question, it can be hard for the team to focus, especially when they believe they should still be celebrating the launch.
To make this easier, I have some ideas:
Get closure
- Celebrate the launch.
- Look for signs of burnout and manage it. Let folks take extended vacations and reassure them that they'll be welcomed back.
- Be honest about the end of the project and how you plan to address the wrap-up work. You should have that work fully scoped before you launch. Don't make it a six-month documentation sprint.
Prepare the next phase
- Compensate the team. You now have the most skilled team in the current codebase that there will likely ever be. Increase salaries rather than giving spot bonuses. It'll be more clear that they're valued after the project rather than being compensated for work done.
- Be honest with your manager if you're considering leaving the company. It gives them a chance to either offer you more opportunities, or at least to manage the transition early.
Start the next phase
- Consider a new mission but be careful how you discuss it - allow the team the time to enjoy the launch but let them know there will be meaningful work afterwards.
- Consider the team at the forming stage again. New processes need to be established. Stakeholders should be reviewed and reconnected.
The acknowledgement of the "adjourning" phase allows the group to respect the end of things the way they were, and to move onto the next project.
Thanks for reading! I guess you could now share this post on TikTok or something. That'd be cool.
Or if you had any comments, you could find me on Threads.
Published