Measuring Cycle Time with Dr. Cat Hicks

About Dr. Cat Hicks

Cat is a research architect and psychologist for software teams. She leads high-velocity research agendas that provide new empirical evidence to answer pressing questions about tech innovation and developer thriving. She's the Principal at Catharsis Consulting and the author of a forthcoming book on the Psychology of Software Teams.

How To Measure Cycle Time and What To Do With That Number

Not many psychologist study software teams so in this episode of Hangar DX we host one of them, Dr. Cat Hicks, to discuss why cycle time is harder to study than it looks, why it means different things to different people, and how metrics can be both illuminating and damaging depending on how they’re used.

Researching Software Metrics is Hard

I avoided doing a software metrics project for a long time. It felt really hard, and I wanted to think about it long enough and listen to people in the community long enough to feel like I had something to say. Maybe I'll voice some of the frustrations software engineers have, which is that people make huge sweeping generalizations about their work.

What finally drew me to research cycle time was seeing how many organizations were already using it, even if they weren’t approaching it with the complexity it deserves.

I wanted to take a scientific, rigorous look at what cycle time is actually telling us. Not to say “this is the perfect measure,” but to ask: What are people doing with this metric, and what can it actually show us when used well?

How to Measure Cycle Time

Collecting data to research cycle time was a huge amount of hard work, and I take great pride in it.

I was the director of the Developer Success Lab for the last three years. And in that project, I built from the ground up our recruiting processes, our promise to the developer community that we wanted to create science. And that in order to do that, we needed them to opt in and join us in our projects and trust us with some of their experiences. In return, we gave back open science: papers, workbooks, and manager guidance based on real-world data.

Software engineering research is a mix of asking questions and analyzing data. I recruit people to answer questions that I think cannot be answered otherwise. In our project on cycle time, we also had access to a large amount of software engineering data across companies because the organizations had opted into a software metrics tool.

Who is Cycle Time For: Leaders, Developers, Customers?

That's the big question. I'm not sure who it's for right now.

It’s marketed as a way for leaders to feel like they're doing a good job of understanding their engineering organizations. But that assumes a level of uniformity in how people work that just doesn’t exist.

‍Developers also have their own relationships to these measurements, which I take really seriously as a psychologist. It's not just that you're measured, but how you feel about it and what you think it's doing. I can imagine a cycle time measurement that is just for one developer who measures their own cycle time and starts to realize that sleep or meetings are impacting their flow.

We often assume customers don’t care about how our engineering organization is doing, and that’s not always true. Sometimes, it’s smart to involve them in the journey of the engineering process, of overcoming hard problems. Metrics like cycle time could be part of that narrative if used well.

To Measure or Not to Measure

There is a very practical reason to stay away from metrics: it’s so easy to use them the wrong way. No matter how much work I put into it, people could use it the wrong way. Who could fault you for not trusting or believing in the metric?

On the other hand, not measuring anything has its own problems.

Developers in our research reported that their technical work often feels invisible. That’s a burden. So while cycle time won’t solve that on its own, some kind of measurement, done thoughtfully, can help.

The key is psychological safety. If a metric is used to support growth and learning, people can embrace it. But if it’s weaponized, even a great measure won’t be trusted.

Measure Cycle Time Long-Term

One big insight from the research is that cycle time is massively variable. It spikes and dips in ways that aren’t always predictable. If you look at it over just one month or one quarter, you might completely misinterpret what’s happening.

We saw clear seasonality patterns across 216 organizations, like dips around major planning cycles or end-of-year slowdowns. So, one of our recommendations is to measure over a longer timeframe. A year of data tells a very different story from a quarter.

The actual data in the world does not care about your OKR schedule or when you need to report to your VP. In our paper, we suggest measuring this data for a long time to even be able to tell if something is a weird event or a seasonal dip. Cycle time is at times really low and sometimes really high, and you can not know if something is an anomaly if you only have data for a month or a quarter.

How to Lower Cycle Time

We also did hierarchical modeling and looked at things like developer network centrality, how central to the network is a particular developer within their team and within their organization? 

Developers who were more connected and collaborated more with others tended to have lower cycle times. But so did developers who had more solo focus time. These are slightly opposing strategies, and as a leader, you need to balance them. There is no one right answer.

You Have a Number, Now What

First, acknowledge what cycle time doesn’t capture. Planning meetings, informal conversations, and pre-work often aren’t in the ticket system. Senior engineers told us, “I’m helping unblock others, but none of that shows up in my own metrics.” Infrastructure teams often feel like they don’t fit into the developer mold at all, even though their changes affect thousands of people. So, the first step is clarity: What’s inside the metric and what’s outside?

Second, don’t fall into benchmarking traps. Your org is probably very different from others. We saw incredible heterogeneity in our data. So don’t assume your cycle time should match some industry average. Set your own benchmarks based on the outcomes that matter to you.

And third, connect cycle time to other outcomes. People usually want to know, “If we reduce our cycle time, will it help?” That’s a causal inference question—and it’s doable! In our research, we focused on identifying what predicts shorter cycle times. But for your org, you might want to ask the reverse: does shorter cycle time correlate with better customer satisfaction, reduced burnout, or faster delivery?

Good Measurement is About Clarity, not Punishing

If organizations were brave about sharing their data, which I'm not sure they are, we’d have the opportunity to apply the scientific method to software engineering, almost like the epidemiology of software engineering. That needs to be big and across organizations, because then you start to understand what is generalizable and what is specific to an organization.

Ultimately, good measurement is about clarity. It’s not about punishing people or creating a leaderboard. It’s about understanding where your org is, what outcomes matter, and how to move toward them in a thoughtful, human way.