As a software development manager, there are metrics associated with how you manage and lead your team.
There are some that are easily recognizable and others that make us think — how will I measure that? Some are easy and trivial, pulled from a system or report, others are harder to quantify (as they should).
This isn’t about making those harder to quantify metrics easier, this is about getting the easy ones out of the way so you can put more time into the harder ones because the harder ones are what matters more than anything, but oftentimes get treated the same way and/or push aside because we haven’t nailed the easy ones.
You lead a team that builds software. To everyone else, that software is the number one metric that matters — are you on time, are you late, when is the next build going to be ready, etc, etc.
Delivery is a key component of your job and one that you have indirect control over. After all, you are not the one cranking out code for five people, you are the one that is motivating, coaching, and inspiring five people to crank out amazing code.
It doesn’t matter what system you are using — JIRA, excel, DevOps, sheets — you have to get delivery information out to those that matter. You need to show people on an ongoing basis whether you are on target or behind.
JIRA and DevOps track all this for you, giving you the ability to create fancy dashboards or in the worst-case scenario — take the data and build your own reports, and put them into sheets or excel.
Your job when it comes to talking about delivery is to communicate context around those numbers.
“We’re late because of this…”
“We’re going to be ahead by a week because we did this…”
“I don’t know who is doing what…”
“I’ll go see why it’s taking so long…”
“No, I didn’t know they were done…”
Use the tools you have to get this information out there, objectively so everyone always knows what is happening.
Great you can deliver, but the quality is garbage, bug return rates are high, new bug rates are through the roof, test cases are failing, happy scenarios don’t make it past the first gate. If you are delivering what is perceived as garbage to the end-user, then you are delivering garbage.
Bugs are a fact of life and will never go away, new features generate new bugs.
But as managers, we all have that moment where our Spidey Sense starts going off and we realize something is wrong in the current build, something that we missed and didn’t see coming.
Monitoring for quality in your delivery will come down to bug rates (how fast are they coming in) and returning bug rates (why is this bug being reopened).
If we see a new build comes out that generates an excessive number of new bugs, then I know we rushed it, that’s on me, I missed something and I need to figure this out for next time.
If we see bugs being reopened, then we missed something there too, we didn’t understand the problem, maybe the developer needs help or perhaps it’s bigger than we thought. Whatever the case, a bug being reopened is a sign that something is amiss.
If you have someone running QA, they will report on the rest, test cases passed or fail, good, bad, or ugly of regression. In these cases you should be working with them to ensure you understand what metrics they are using, if you are running solo there are many avenues you can pursue to help your team that are easy wins and distribute the workload — unit testing requirements, code reviews, design reviews — all of these activities lead to a more quality product being delivered.
If you are using the tools at your disposal correctly, Delivery and Quality should be handled pretty easily by them. Sure you might need to put some time in at the beginning to make sure they work, but after that, it should be smooth sailing with a few tweaks. The next grouping of metrics is where you should really be spending your time and where your focus truly needs to be
How are People Growing?
If your initial response to this is — “I don’t know” — that’s okay, but now it’s time to think about it. Your team is what will deliver success. They might be happy working on what they are working on now, but who doesn’t want a new challenge? Who doesn’t want to evolve and become something more? Who doesn’t want to learn a new framework?
If you don’t know how your people are growing then who does?
Whether it be training, trying other opportunities, learning new techniques — your role is to further and push their growth, you are there to help them get as good as you are to become something else, something better, something more.
Well, what if they leave?
Yes, you could do such a great job that they might learn some new framework that gives them the confidence to go try some big, new crazy endeavor that they never had the confidence in them to do before.
And this is the best way for them to leave. I would much rather have someone on my team left because I have given them this confidence to try something new than to leave because they were bored and burnt out.
Team Debt Reduction
While everyone else is focused on the now, you, the manager, need to always be focused on the yesterday, now and tomorrow — this is our debt. Debt is what we have taken a hit on yesterday, agreed to today so that we can be successful tomorrow, but knowing tomorrow we are going to have to pay for it.
It doesn’t matter whether it’s code, testing, or people’s debt — it’s your job to make sure it gets paid. Making the decision to take on debt to grow isn’t an easy one — hack it this way, telling a junior to step aside so a senior can fix their code and get it out to a burning customer — these are all examples of the tough decisions you have to make. I like to think of debt as two piles, one is reactive and is proactive. The reactive part is easy, we all do this, we make that initial decision to incur debt and move forward. Things will work out in the short run but we all know sooner or later, they will break, something will go wrong, someone on the team will approach burnout and we are going to have to pay for it, with interest.
This is where the manager steps in by being proactive in terms of what needs to be accomplished;
1. I’ll need to schedule a meeting to tell Jamie why I took him off that code and put Sandra in and what needs to focus on learning.
2. I’ll need to talk to the PM about getting a framework item on the backlog so we can scale our next release, otherwise, we’re capped.
3. At the next project update, I need to explain the hack we made for that burning customer and how it can’t go mainline as a feature.
These are the proactive steps that a software manager takes to constantly be reducing and paying down their team debt.
Last is the pulse, a great manager will have their fingers on the pulse of the team, always. This should be top of mind always for any manager. It’s not focused on anything else we have discussed and it could be as simple as;
What’s our laugh quotient? Does anyone laugh or smile at our meetings? Has everything become transactional?
Should we have a get-together or do something fun online outside of work to get to know each other well?
How is Mark doing with the added workload? I should reach out to him to see if he needs help.
The pulse of your team has never been more important than the events of the last year were more than we could have ever fathomed was happening all around us and everyone was directly impacted by it.
I have learned things over the past year about my co-workers that I probably would not have learned about normally all from asking the simple question — “how are you?”.
As you can see, the first two metrics of software leadership are easier to figure out and know where you’re at — there are even tools that you can probably pay $10/month for to help you with.
Great, that’s the idea and hopefully, that’s the kick to get all of that squared away. If you’re looking at the metrics you have around quality and delivery and find yourself spending too much time on them, then that means you’re ignoring the truly big, significant metrics of — growth, reducing debt, and knowing the pulse of your team.
For these three, I have my own internal barometers for measurement, and between each that I have managed, they have changed based on the skillset, experience, and environment that we work in.
But the categories stay the same and I learn to change what goes into them.