‍Have you ever handed over a dashboard to your team, hoping it would foster a data-oriented approach, only to see it ignored? You probably had the best intentions, envisioning your team using it for continuous improvement based on data. Or you thought it would be a great way for your team to quickly get on top of things. But, more often than not, these dashboards are quickly neglected. You might find yourself being the only one visiting them, and only occasionally at that. The lack of use eventually leads to decay, making them less accurate or even misleading.

Perhaps you created the dashboard yourself. This approach has its drawbacks, as the design will be heavily influenced by your needs. Different dashboards are needed for different personas. You might have even asked your team to build it themselves, thinking that this would surely increase their buy-in. Yet, little-to-no engagement is common.

This lack of engagement becomes more painful the bigger the investment in the dashboard. Regardless of whether the dashboard was built in-house or purchased as a turn-key solution like CodeClimate, LinearB, Jellyfish, Athenian, etc., these tools are expensive. They can cost a few hundred dollars per developer per year. This makes it painful to admit defeat and give up on them.

I've seen this happen many times. The most common reason for this is that the team is simply too busy. And they will drop things they perceive of lesser value. This is  why I advocate starting with why. By starting with a problem or an opportunity to be conquered, the charts will be presented as an aid to their goals, not an additional problem for them to worry about.

Maybe your 'why' is a cultural shift towards a more data-oriented approach. But is that motivating enough for development teams? I've seen it work, but rarely. It is too dependant on the individual. So, focusing on fixing something they genuinely care about and leveraging metrics for that purpose is a great way to promote a data-oriented culture.

But what if we had a problem that was painful for the company, not the team? Can we still succeed at setting goals and tracking progress through metrics? For example, it's very common in software development teams that, as they grow, they need to be able to track changes in code to the corresponding issues that originated them. Like adding Jira issue IDs to every commit. For teams used to committing freely, this is generally perceived as of very little value while still being annoying. It forces them to spend time and mental effort ensuring everything is correctly labelled.

On the other hand, this is frequently necessary for compliance purposes. All ISO certifications I've seen introduced this in one way or another. In this case, developers are not intrinsically motivated, but leadership is. So, what do we do here? Well, this is one of the few cases in which I've seen setting top-down metrics and reporting working well. As annoying as it is, it's easy to understand the need for compliance with the certification. The secret ingredient to ensure execution is using follow-ups as a reinforcement.

At a past company, we went through a similar change. We built charts and reminders that informed each engineering manager of their level of compliance periodically. We set a goal and reviewed it in our monthly business reviews. As you might imagine, teams quickly complied. And in case of avoidance, it would eventually surface.

This lack of intrinsic desire to comply from the developers and top-down goals still caused developers to try to game the metric. When in lack of a Jira issue, rather than going through the effort of creating it, some devs resorted to using a fake one with id zero. In this case, it was easy to catch. But we were genuinely surprised to see this kind of behaviour in engineers we trusted. This should serve as a cautionary example of how imposing metrics won't work when these are easy to game. People will aim to solve their problems in the most efficient way possible for them.

The success of implementing dashboards and metrics in a team relies heavily on the perceived value by the individuals using them. Starting with a clear "why" and aligning the charts with their goals is a great solution to foster engagement and promote a data-oriented culture. And in cases where compliance is necessary but not intrinsically motivating, setting top-down metrics and using follow-ups as reinforcement can be effective. Although it is important to be aware of the potential for gaming the metrics and ensure that they are not easily manipulated. By starting with why and the right reinforcements in place, we can increase the chances of success in utilising dashboards and metrics for continuous improvement.

‍