All roads eventually lead to Cycle Time.

Tons of tech debt?

Too much context switching?

Team is burnt out?

Tests take forever to run?

Cycle Time is the ultimate north star metric because it helps connect all these dots.

But.. How does that work?

Anything that impacts the engineering team in a meaningful way will present itself in your cycle time - as long as you know where to look.

Cycle Time measures the delivery process. When anything starts to effect our delivery (tech debt, context switching, etc) - Cycle Time will inevitably be effected.

Changes to Cycle Time give us an early indicator that something may be wrong.

Okay so.. How can I use Cycle Time?

Step 1: Get a Baseline

Establish a baseline Cycle Time by looking at the team's 6 month average. This tells us how long the average pull request takes us to complete.

This allows us to perform the next step.

Step 2: Look for Outliers

Using the baseline we calculated above, we can now quickly identify pull requests that do not fit the norm. Pull requests with higher than usual Cycle Time give us an excellent starting point for conversation.

We use these outliers to identify problems as they arise.

Step 3: Gather Feedback / Understand Root Cause

Once we've identified the root cause for higher Cycle Time, we need to collect more data. This usually comes from conversations with our team. By talking with your team, you'll quickly be able to spot patterns and determine if this is a wide spread issue.

Collecting feedback helps us understand the root problem

Step 4: Repeat Frequently

Once we've learned more about our root problem(s), we want to check in frequently. Whenever we see deviations in Cycle Time, we should be logging these events and starting to pull together patterns.

Checking frequently allows us to understand how often the team is affected.

Any examples?

Here are a common problems that often present themselves in Cycle Time.

  • Technical Debt
  • Context Switching
  • Team Burnout
  • Poor Communication
  • Poorly Written Tickets
  • Inefficient Code Review
  • Poor Quality Code
  • Long Compilation Times
  • Stuck Engineers

Again, anything that affects your engineering team will present itself in Cycle Time. This is not an exhaustive list.

By keeping an eye on your Cycle Time (and more importantly deviations) then you'll be able to quickly identify problems as they arise and work with your team to resolve them.

Great. Now what's next?

Cycle Time is is a key north star metric fo successful engineering teams but it's not the only metric worth keeping an eye on.

Next Step: What other metrics does Haystack provide?

Did this answer your question?