Operations | Monitoring | ITSM | DevOps | Cloud

You might be excited about tracking DORA metrics, but have you ever thought about the ways in which you track them, and how important accuracy is in your methods?

Productivity is a big topic. We all want to be more productive — and software developers in particular get put under the microscope. Interestingly, their work is also particularly difficult to measure and assess what “productive” even is. But we need to do it because we want developers to be more productive — and happier — because we want to achieve business goals together, better.

How do you treat software development failure? Do you take time to measure and learn from software failure? Or do you try to fix it quickly only after your customers complain about it? Failure can be an opportunity to learn and get better. So how can you measure and learn from software failure, and turn failure into at least a partially positive experience? Failure happens all the time, but if you're not measuring it, how do you know what you’re missing?

DORA metrics are becoming the industry standard for measuring engineering efficiency, but where did they come from? ‍ We talk a lot about DORA metrics here at Sleuth — what they are and how to measure them. But we haven’t shared much about the context of DORA metrics — their history and why we use them. So let’s do that. This article provides a summary.

Has this ever happened in your weekly stand-up? ‍