BEFORE WE START
Let’s acknowledge that software metrics are very important for software teams as they give insight into various aspects of the software development cycle. These metrics give tech leads and product managers the necessary information needed to make business decisions, eliminating the need to pull in a developer merely to get status an update. Developers don’t hate all meetings – just ones that waste their time. Status updates that could have been a dashboard instead will only keep them from getting closer to the set goal.
As an executive, you plot the course and fly the airliner. You need to make sure your team’s efforts are aligned with business goals and that you are doing everything in your power to ensure the success of crucial projects. By viewing things from the top, you will be able to get the proper glimpse into what and how your development team is doing. You can do that by hosting regular meetings, checking in with your employees or just by using Cobraid Deploy dashboards. 😉
HOW OFTEN SHOULD YOU REVISE YOUR KPIs?
The stability of your business plays a role. If you are an established business, with established goals of your site, revisiting your KPIs too often suggests that you didn’t have the right ones in the first place. If, however, you are a newer, (somewhat) flying-by-the-seat-of-your-pants business, I can understand the need to more continuously evolve your KPIs.
KPIs shouldn’t change every month, even for the latter business example. (Would it be unprofessional of me to say, “duh”?) Check out the video bellow, it talks short and sweet on this subject.
You should be consistently measuring against the same yardstick. However, it is often considered as a good practice to revise them every three to six months and make sure your KPIs are useful and complete. (It depends on where you are at in the organization. There is a podcast episode about that in Danish.) Do you need all of them? Or, on the flip side, is there something new that should be included? Perhaps there are new capabilities you have developed that would allow a new KPI to be measured? Software development has been booming like never before, take the advantage of new measurement options.
GOALS ARE SET, WHERE DO WE GO FROM HERE?
Each KPI should be assigned an owner, have a clear success definition of what success looks like, and be visible for all to see. In order not to be blindsided by the result, for the KPI to be tracked and discussed weekly if possible. This will allow you to recognize a potential problem, adjust and avoid disaster. It’s a lot easier to prevent fires than fight them. You should discuss, debate, and agree as a team on what success looks like and what failure looks like.
Make it a routine to have a meeting weekly/monthly/yearly to see how close or far you have come to the set goal. Start the meeting by letting the developers speak first. This way you’ll be able to add some data to the homework you did for the meeting, which will enable you to fine-tune your understanding of the situation. The goals should be as clear as possible for both the manager and the developer.
It is important to identify beforehand who will receive KPI information and categorize them to allocate access accordingly. Primary audience: people who are directly involved in managing and making decisions based on the KPI given. Secondary audience: people in other departments who may benefit from knowing the data. Tertiary audiences are external stakeholders.
Depending on the purpose of KPIs to each audience group, they are reported at different frequencies. For instance, if a KPI is to serve a decision-making purpose, it should be provided more often, whereas if it is to be included in an annual report, it only needs to be communicated once. Effective goals reviews can boost the productivity of the developers you manage. Those goals should be as clear as possible for both the manager and the developer.
TIPS FOR COMMUNICATING FROM COBRAID’s COMMUNICATIONS SPECIALIST
If you are like me- working within the development but not doing it- make sure to take your time in the meeting understanding the processes that get code from an idea to a working product. You can’t lead the team if you are not fully on the same page as them. And don’t try to fake your understanding. It will only leave you confused and them thinking you are an idiot. (Did she really say that?) There’s no need for you to prove your intelligence, we all know you are pure genius.
After discussing the goals and your process of achieving them, allocate some time for a general conversation. This is where retrospectives come in. An agile retrospective, or sprint retrospective as Scrum calls it, is a practice used by teams to reflect on their way of working, and to continuously become better in what they do. Ask the developers how you can help them within the process, what is on their minds, what obstacles they face in day-to-day work, and similar. Wrap the conversation up by stating whether you are happy with their performance in general. It’s important to every employee’s sense of job security to understand where they stand.
Some of the topics you might want to bring up could be:
- Unnecessary or Partial features
- Dependencies between features
- Multiple testing and review cycles (How to optimize and save time)
- Bugs and defects
Lastly, prepare a written summary that can be emailed to the developers and used for future follow-up. It’s useful to go back to this summary, for instance, every time you think that the developer team is going a bit astray and you want to straighten things out. Again, this shouldn’t be done in a brutal or hostile manner. It can be something like “We discussed this in our KPI review, can you update me on the improvements in this field…” Open and honest communication is the key to fostering trust and understanding.
Setting goals with your team is important, but even more important is to follow up on them.