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 dist
SDM Insights: Own the Failures - Yours and The 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 . About 6 months into my time as SDM, I had to kill a major project, one that had seen three developers invest many months, an entire year for the Senior Dev on the project. The project was the baby / brainchild of my predecessor, and everyone assured me that it was almost complete, just a little more time and effort would get it over the top. SDMs are not always in the position to green-light or kill significant client-facing projects, but as we made our strategic plans for the coming year for Development, it became obvious that we had higher priorities and more lucrative opportunities to pursue, ones that we would miss if we continued to pursue this overdue, over-budget, over-complicated project. So it was terminated, and I reassigned the three Devs to other projec