Blog | Engineering Insights best practices

How to become a data-driven organization with Pluralsight Flow

At Pluralsight, we believe that becoming a data-driven organization is beneficial for all levels of your company. Using data to make decisions on workflows and processes will help increase productivity and efficiency. But more importantly it helps team leads advocate for their employees and improves the overall developer experience.

Recently, we shared how our own engineers use Pluralsight Flow, our engineering insights platform, to drastically reduce queue times while also improving communication. Our teams understand that all of the metrics within Flow work together holistically, but it can feel overwhelming to approach an insights platform from day one and use every aspect instantly.

With that in mind, we asked our engineering leadership which metrics they found most helpful from the word, “Go.” Focusing on these data points can not only help transform your software development team into a data-driven model of efficiency; they also are easy to understand and work with while you grow accustomed to some of the finer points of Flow and overall team health.

Coding metrics 

Coding Days

Flow proposes the idea of Coding Days as any day where an engineer contributes code to the project. There are many different forms of engineering work: writing code, reviewing others’ work, discussing specs and architecture.

Coding Days gives an overall view of “do people have time to create solutions in the code base, and are they following best practices around small/frequent commits?” This is also tied to the health of continuous integration and continuous delivery practices where technologists focus on small and frequent commits.

It’s important to note that if a team has a low week of coding days, it’s not necessarily a bad thing; there are nuances to what impacts coding days. The point is to use Flow to alert you to that status, and then talk with the team to figure out those nuances.

Collaboration metrics 

Unreviewed PRs

In an ideal world, PRs should always be reviewed before they’re merged. Even if they’re small or made by senior developers, unreviewed PRs can be a huge source of bugs. That’s why every time a PR is merged without review, a manager should know about it.

Simply put, this data point is an indicator of risk. You don’t want large numbers of unreviewed PRs merged, as that’s more likely to cause a higher change failure rate or poor performing customer-facing code.

Reaction Time

This data point looks at the time it takes for the reviewer to respond to a comment addressed to them. Are team members unblocking each other, and quickly, to get code into production? 

Reaction Time is tied closely with two metrics we’ll discuss next: cycle time and queue time. When you work toward driving this number down, it will have positive implications on your overall ticket metrics. Speaking of…

Ticket metrics

Cycle time

Cycle time is the time between when a ticket enters an Active status, to the final Done status in its life cycle. Any tickets that are currently in a status marked as Not started or Active, will not have a cycle time calculated for them. Cycle time updates when tickets move backward from a done state. 

This metric should be used to determine how long a ticket took to complete. Cycle time only captures the time engineers worked on the ticket. It does not include lead time where product managers, designers, or stakeholders provided requirements before the ticket entered an Active state.

Queue time

Queue Time is the total time a ticket is in a waiting state. The engineer working on the ticket may need to wait for feedback, QA, or review from team members. Queue time captures these moments in the ticket life cycle to help improve efficiency and remove barriers for engineers. 

In general, you can think of these two delivery metrics as, “How long is it taking us from the time we start a piece of work to when it gets to production?” They help determine where process inefficiencies can be found and where code is sitting with teams for longer periods of time, which allows teams to adjust when appropriate.