If you aren't tracking software cycle time, you're not doing your f**king job

Now that I have your attention, welcome to Engineering Intelligence, a new newsletter from LinearB. In a world dominated by AI-assisted drivel, we want this newsletter to be original, entertaining, and informative. We’ll cover the latest trends, news, and research about developer productivity, Developer Experience (DevEx), and software engineering leadership; we’ll also try to make it fun along the way. If this sounds up your alley, click the subscribe button.

Now, back to the headline.

Cycle time is the single most important metric for quality and efficiency

It’s almost 2025, and cycle time is one of the most straightforward metrics you can possibly track. It only requires you to connect data from your git repos and project management tool (AKA JIRA) to a visibility platform, and boom; it’s done. Yet, I still meet engineering teams that have failed even to reach this basic level of metrics capabilities.

We have published extensive content on cycle time, and at this point, anything else we write is likely to feel like an exercise in massaging GPT outputs; there simply isn’t much more to say. There’s really only one thing you need to know about cycle time: there is a clear correlation between cycle time and software quality and efficiency. To say otherwise is akin to putting your head in the sand.

Here are the facts about what occurs on teams that focus on shortening their cycle time:

• They prioritize practices that optimize software delivery efficiency, like minimizing PR size, responding to code reviews quickly, and improving CI/CD systems.
• It highlights parts of their codebase that may have complexity issues. For example, libraries or tools that frequently cause long cycle times are a prime target for reducing tech debt.
• Downstream failures become less disruptive to upstream processes; faster cycles mean they can respond more quickly to dynamic situations.
• They normalize a practice of data-driven behaviors and habits to maximize their impact on the organization.

Cycle time isn’t a panacea for organizational woes, but it is the best metric to start with when you must resist the endless requests from the rest of the business for engineering to do more with less.

Your devs are probably suffering

I dislike using harsh language, but I care a lot about DevEx. If you don’t see the friction your developers experience on a typical day, you’re operating blind. The victims of your lack of visibility are the rank-and-file developers that keep the meat grinder churning. They are the people who get covered in grime when things fall apart, and you might not even know it's happening.

Things might seem fine today because you aren’t hearing a lot of complaints, but this can change fast. Six months down the road, you might find yourself reacting to one of these scenarios.

• A sudden retention problem as your senior devs start leaving for other companies with less red tape and more focus on improving DevEx.
• Inability to efficiently ramp large volumes of new developers as you scale the organization to meet market demands.
• Unpredictable delivery timelines because unexpected challenges constantly disrupt innovation.
• An executive team that believes there is more productivity to squeeze out of an engineering organization that has already been cut to the bone.

Simply put, tracking cycle time is the best thing you can do right now to ensure your investments into DevEx are measured in productivity gains that the business cares about.

It’s even worse for your engineering managers

Engineering managers are caught between executive demands and individual pressures. They’re the frontline for ensuring developers stay happy and productive. How can they do that without visibility or a frame of reference for what’s good? Their counterparts in product, sales, marketing, and customer success have all normalized data-driven practices and goal-setting, and engineering managers want to be capable of achieving the same.

Nobody is born a great manager; it takes experience, direction, and support. As an engineering leader, it’s your responsibility to ensure that your team is armed with all the tools it needs to succeed. Cycle time must be a part of that picture.

Stop the excuses

We’ve heard all the excuses, so before you clog up our inboxes with a bunch of “well actually…” let me try to get ahead of you. These excuses aren’t going to cut it anymore.

Cycle time doesn’t give us a complete picture of productivity or DevEx.

Duh, no metric is capable of this, but cycle time should be your first step. Step two is augmenting cycle time with other metrics for engineering predictability and profitability so you can measure the impact of your initiatives on the broader business strategy.

We can’t decide on a standard definition of “done.”

Then don’t. Measure cycle time at the team level. Each team needs the autonomy to define the process according to its needs.

The rest of the business doesn’t care about cycle time.

That’s not their job. The rest of the business needs to plan major initiatives around engineering timelines. It’s your job as an engineering leader to articulate engineering needs to everyone else and balance operational excellence with business priorities. Yeah, we know it’s hard; it’s probably one of the hardest challenges at your company.

Our developers don’t want to be spied on.

That’s a cultural issue, not a technical problem. Your developers need to feel personally invested in bettering your engineering practices. Give them clear goals and the autonomy to define how they will achieve them. Cycle time should be used to encourage data-driven conversations about bottlenecks and disruptions, not as a weapon to compare individual performance.

Our tech stack isn’t compatible with tools to track cycle time.

Fix your tech stack and bring it up to modern standards. I recently met an engineering team migrating a 40-year-old COBOL system to Google Cloud microservices. If they can do that, you can move from SVN to git. All it takes is focus.

We don’t have the resources to implement cycle time monitoring.

You can get it for free right now from LinearB. Why are you still waiting?

A newsletter written by humans, for humans

Thanks for following my rant to the end; despite the sharpness of this article’s headline, we don’t wish you any ill will, even if you aren’t tracking cycle time today. This newsletter will deliver thought-provoking insights that stand out from the endless feed of AI-generated content clogging the airwaves. We’ll bring you original research, a unique perspective, and more knowledge than you know what to do with. If you want to be the first person to get all the latest news, subscribe to this newsletter to get alerts when new content is published.

We love reading new research on developer productivity, DevEx, and software engineering leadership. If you’re a researcher cooking up something extraordinary, let us know by sending a DM. We often publish executive summaries of excellent research to share with our community

Speaking of which, here are some of our recent research articles:

• The Role of Cumulative Culture in Developer Productivity - Developer productivity is not an individual challenge. Cultural practices also play a significant role, and this article will help you navigate the softer side of developer productivity.
• 14 Insights Into What Drives Software Quality at Okta - DORA and SPACE are remarkable frameworks for measuring productivity and DevEx, but what if you want to measure your organization’s ability to maintain software quality?
• Do Software Developers Like Using Gen AI? - Spoiler alert: yes, but more so if they are exposed to it through a coordinated adoption process. This article has some great insights on ensuring success in the early stages of Gen AI adoption for software development.

Reddit is a treasure trove of insight on engineering leadership; here are some threads we’re following.

• What does the typical day look like for a Principal Engineer?
• What’s the most annoying thing about working with product teams?
• The best dev you’ve ever worked with - what made them so great?

If you’re ready to be the smartest engineering leader you know, join us on this journey as we explore the future of developer productivity. Subscribe now.

Author: Ben Lloyd Pearson , Director of Developer Experience @ LinearB