One common mistake when passing information to C-level executives is overwhelming them with details that they don’t understand or that they just don’t care. The lack of alignment on what to send them may give you a hard time when adopting new techniques, such as process metrics analysis. In this blog post, I’ll explain how we usually present that kind of information in a way that doesn’t confuse the reader and, at the same time, contains all essential information.

*As a disclaimer, when I mention “CTO”, I want to talk about whoever is in charge of technology, “CPO” as the head of products and “CEO” as the strategy person. Depending on the size and culture of your company, one person might have more than one of those roles.

CEO and the burnup-chart

The CEO will probably not have time to read all of your metrics and understand them. However, they need enough information to plan for the future.

We usually present the burn-up chart. It contains a good summary of the team’s progress and, more important than that, it displays forecasts for each planned release.

CTO and failure demand

To your CTO, I believe that, other than clear information on how many stories the team is delivering, the most critical metric is the percentage of time/throughput spent with bugs and chores. With it, he/she can evaluate the codebase quality and act upon it.

CPO and lead time

Another relevant piece of information that you may need to share is lead time statistics, not with the CEO/CTO, but with the CPO. That person needs to know how long it takes to implement and deploy a new feature. Otherwise, the company might live under constant pressure and with the familiar feeling that the technology department never meets the product goals.

General reports

Sometimes, we’ll find ourselves having to report what we’ve done. Maybe stakeholders haven’t seen many changes in the last weeks, or perhaps that’s just how things work in your company. It may happen due to many backend tasks, because you had to refactor something, etc. Either way, what I always try to do in those cases is to explain the task goals business-wise. Here are some examples:

Update rails ~> We had to update our rails version to improve the security of our app and guarantee that our customers’ information is not threatened.

Refactor bad_code.rb ~> We had to use some time rewriting and dividing this file because it was common to have to change things in it, and each time we had to do so, we spent days trying to understand it and being careful not to break anything. Therefore, doing this, we expect to improve our development efficiency and deploy future features faster.

Conclusion

Different roles need different information to accomplish their goals. Don’t overwhelm people with data they don’t need. In the end, even though it may seem counter-intuitive, you can increase the visibility by decreasing the amount of information you give.

What do you think? Do you agree with us? Leave your comments below!