Situation #
The entire TPM team at GitHub was fully committed to a portfolio of existing programs. At the same time, GitHub leadership kept asking for rapid TPM support to address specific, urgent problems. I could either:
- Say no? Not to the CTO when it’s urgent.
- Yank someone off their important program and stick them on an important project. This happened several times and was very disruptive. After all, programs are, by definition, focused on strategic outcomes.
Behavior #
Understanding that the urgent needs wouldn’t go away, I dedicated 3 TPMs (10% of my team’s capacity) to a new entity called The Flex Team for a 6 month experiment.
The hypothesis: it was better for GitHub to have experienced TPMs sitting on the bench waiting for something to go wrong an urgent need, that to disrupt strategic programs mid-flight.
We created a dedicated comms channel with our CTO (#flex-team) and established a rule: anyone could ask for help from this dedication team, but only the CTO had the ability to say “Do it!”
The Flex Team handled several high urgency, high importance projects in the 6 months that it was fully funded. The projects included responding to an urgent security issue involving a large number of team at GitHub. The issue was resolved rapidly due to TPM coordination across hundreds of Hubbers across tens of Engineering and Product teams.
How the Flex Team was formed
Impact #
- Immediate success. Critical projects were staffed withing minutes-to-hours, with systems and processes being in measurably better shape within days-to-single digit weeks.
- Long-term sustainability. We learned something: the types of issues that came up repeatedly turned out to be areas of underinvestment. So over time I spun up dedicated programs for those areas—security, availability, scalability—and the Flex Team TPMs transitioned to full-time leaders of those programs.