SDM Insights: Protect Your Team
In celebration of my fourth anniversary as a Software Development Manager (SDM), I've written a series of reflections on some lessons learned. See the full list here.
My team has been 100% remote from day one, with developers in multiple countries and time zones around the world. So we communicate a lot with online tools like Slack and Skype and Zoom. This lets the team better collaborate, and also gives a direct connection between Support and Development.
Too direct, it turned out. Often Support would encounter an issue with a Client and ping the Development team. If no developer responded quickly enough, or if the issue piqued her interest, the Product Manager would regularly jump in and assign a developer to investigate the issue immediately.
Everyone would then wonder, at release time, why the Development team was only able to deliver a fraction of the expected new features and fixes. The problem was in part a process that was too open to distraction, interruption and priority shifting.
When I identified the process as the problem, I inserted myself into the interaction between Support and Development. We worked to distinguish between critical issues that need to be escalated - such scenarios easily justify interrupting the Sprint plan! - other issues that impact a client but do not impede them, and still others that may be pain points but that we can address through the regular planning process.
It was an important experience in protecting my team. The success of each Sprint rose as the noise diminished and the developers were better able to focus on their assigned work.
Support also ultimately benefitted from the change, by having clearer guidelines of what to expect in terms of response from Development. And the lower tension between the two groups made for an increase in helpful back-and-forth discussions on the shared forums. Development was more likely to check the forum regularly, confident that it would not blow up their days. And Support got more answers more quickly.
Building quality software is a creative process. It requires careful thinking and concentration, and benefits from large blocks of time for deep-dives into the challenges. Interruptions to this flow are frustrating to the team and ultimately less productive.
An SDM, on the other hand, is inherently more fragmented in tasks and in the shape of the day. Interruptions are expected. In the above situation, adding one more interruption to my day was a very small tradeoff to make for a large increase in team productivity.
There are other ways the SDM needs to protect the team. When things go wrong, the SDM needs to be the point person to the larger organization (see my post on Own the Failures). Blame for a disaster rarely rests with a single individual, and it is not in the best interests of the team or the organization for that individual to be singled out, humiliated, terminated. By being the point, the SDM protects the health and productivity of the team. Bad consequences may still be necessary, but they are better handled at the level of the team, not the organization.
Team productivity, culture, makeup, assignments and more are affected by outside influences. A key role of the SDM is to protect the team in appropriate ways from those outside forces.