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, of absolute and relative performance. And they were either within my control or ones over which I had significant direct impact.
As a Manager, on the other hand, I am one or several steps removed from the hands-on-keyboard side of Development. I have less opportunity to do what needs to be done myself, to ensure that the feature is completed and solid and tested.
Now, I need to align other factors that clear the way for my team to do their jobs. My definition of Success needed a change.
So what is Success for a SDM?
I define Success along three different overlapping time scales.
Daily-Scale
The shortest such time scale is Daily. On any given day, have I handled any crisis that arose? They could be a tech issue blocking progress, or a production issue needing immediate attention, or interpersonal conflict. Have I blocked distractions from interfering with my team? have I adequately moved forward the future projects that depend on me? Any given day can have the Urgent interrupt the Important, so have I properly prioritized tasks and challenges? When I can end my work-day satisfied that I did good work and am set up well for tomorrow, then the day-to-day definition of Success has been met.
Sprint-Scale
Next is the Sprint-scale measure of Success. Mid-Sprint 1-on-1 check-ins with each Developer, keeping the pulse of the issues in the Daily Scrums, these and other techniques give me as SDM a chance to forecast and affect as necessary how the Sprint will measure up against its commitments - the definition of a successful Sprint being to complete all tickets to the agreed-upon state by the end of the Sprint.
When I started this role, the team's Sprint board regularly had 70 or more tickets on it, the vast majority of which would be carried over from Sprint to Sprint. In order to create more successful Sprints, we needed changes to several processes, and clearer articulation of expectations. We needed a cultural change, one that is still not complete although we have moved closer to a culture of successful, targeted and realistic Sprints.
Release-Scale
Finally, the Release-scale measure is the ultimate, long-term definition of Success. A Software Development team's purpose is to build and maintain quality software and get it into the hands of our clients. Whether the releases happen monthly, quarterly, or continuously, this scale is a vital factor in SDM Success. Did we deliver what we needed to deliver, on time and on budget? Once in the hands of clients, was the software solid and stable? What bug reports or significant production issues arose as a result of the released code? Whether a single individual or a whole team contributed to the feature and release, these measures across the whole team contribute to the SDM success.
As a Developer, achieving Success felt like something I could directly influence.
As an SDM, Success is more influenced by the rolling together of the individual successes of everyone on the team, plus the goals and objectives for the team as a whole. As someone who is passionate about helping others be their best selves, I have embraced this broader definition, even as the control-freak side of me has lamented being a step removed from the direct hands-on-keyboard influence.