SJGP Software

 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

SDM Insights: Revise your definition of Success 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 . Separating the two halves of my IT career is a 9-year hiatus, most of which was spent as an Anglican priest in a small, rural parish. Despite knowing better, I internally defined my success by the attendance and financial health of the parish. So as people aged and died, and weekly attendance and giving slowly shrank, my frustration and sense of failure grew. The fundamental flaw was that I was using the wrong definitions of Success. As a developer, my definition of Success was more oriented toward the tasks I was assigned. Was I delivering them on time? Was I increasing the test coverage as I did so? Was I meeting and exceeding my targets for fixes and new features? Was I out-performing the other developers? Those definitions were a mix of qualitative and quantitative,

 Four years ago this week, I started my exciting new adventure as a Software Development Manager (SDM)! It is now the longest time I have been in a single position in technology. My longevity is due in part to how much fun the role has been. I have described it to others as "the most fun I have ever had for a paycheck." In celebration of the anniversary - and new personal best! - I will distill some of my reflections on the nature of the SDM role into a series of short posts. I am tempted to call them the "5 Commandments" but that implies a completeness, that there are only 5 important things. Which is not true; managing a development team has so many factors that matter, not least of which is a depth and breadth of technology understanding.  These are the non-technical topics that I want to cover: Revise your definition of Success Own the errors and failures - yours and the team's Protect your team Know your Domain Management and Leadership only overlap And a f