The Importance of Cycle Time

It took me a long while to understand why my boss pushed on various things, and what I used to find annoying, I have come to appreciate. It’s rather like how I once joked about static typed languages, saying making a string in Java is as easy as “string String equals new string dot create string” to which a much more Senior engineer replied “Some day you will come to love static languages” - a prophecy which indeed came true. In the same vein, as an Engineering Manager I now have a deep respect and fondness for Technical Design Documents, Product Requirements Documents, and as this article will illustrate: the importance of cycle time.

To a junior engineer (or at least myself back in the day), cycle time is an arbitrary statistic used to track developer productivity that serves no inherent purpose. The push to move faster and deploy changes often is nothing more than the push to get more work done like any company, and is meant to see that someone is being productive.

Balderdash!

Cycle time is a core statistic for a team, and can be an indicator of a handful of ills plaguing one. While not perfect, as no stat is, it serves as a barometer of health and the reasons for maintaining a low cycle time are manifold:

One of the main advantages a startup has over large companies is the ability to pivot1. A startup may be just a tiny boat in a large ocean, but it has considerable edge over the tankers nearby when it comes to quick decision making. As a start-up, priorities can shift without much notice. If an urgent client request comes in, and you’re in the middle of a 8 point beast of a story: you’ll either need to wrap that up under pressure, or worse: Leave the work to the side for the duration of the new project, leaving you with a severe productivity hit when you return to pick the work up (which now likely has unwieldy merge conflicts that need to be resolved as well).

Shipping early and shipping often is a signal to your stakeholders that you care both about the product as a whole and their own requests. Even if the overall project they’re waiting on isn’t completed yet, there’s an indication that things are moving - that reduces the odds of having to provide constant updates on where the project stands because they can spot the momentum. If someone is waiting on the sidelines for their request to even be started, a low cycle time (resulting in plush changelogs) can illustrate why their work has yet to start and indicate that there’s movement being made towards their own needs.

Even when a feature is hidden behind a feature flag or the stakeholder is the engineering team itself, getting feedback early helps the process. Feedback doesn’t have to be from the end user, you can learn from PR reviews and keep that feedback in mind for the rest of the work being completed or even more crucially: spot large implementation issues or systematic bugs before they become baked in with more code.

As an example on why even non-user facing work benefits from low cycle time: if you’re adding in a new database column and part of the feedback is the type of field or even just the name, you can easily refactor a branch that only added in the column much more easily than you can with a PR that combined adding the column itself along with a bunch of code referencing the column. The more changes there are, the more likely it is that any feedback on that column goes unaddressed because of the lift required to change direction at that point. Over time, you’re left with a codebase where the quality of life development hits linger around, unaddressed because making the change was considered too minor to hold up a larger time-critical piece of work.

By breaking down tasks into smaller, manageable pieces, you reduce the risk of encountering major issues late in the development process. If there are any problems, they can be identified and addressed early on before they have a chance to derail the whole project.

Bugs are going to happen at some point no matter how thorough a review process there is. Plan A should be avoiding shipping bugs, but after that the priority should be quickly addressing the impact. This is much easier of a task when the work itself is smaller in scope: identifying which change caused the problem is easier when a release contains fewer large scale changes. Most likely the commits shipped will be touching different areas of the codebase, making a suspect more clear upfront. After identifying the culprit, reverting the change is easier when it’s clear what the impact of a revert would have on the new current state of the product, an easier task with a bite-sized change.

Looking back at early feedback, it also means the bug gets resolved before more code is written that might have potentially used the same troublesome pattern or had more code referencing the bug itself.

This may not seem like the most important on this list, but if you’re like most people: checking off a box from your to-do list just feels good. Working on the same chunk of work for a week or two straight feels like nothing is being achieved and the sense of momentum goes down - even if it’s the same work being done. A consistent cadence of delivery can help you feel more impactful on the team.

In summary, keeping cycle time low is crucial for agility, motivation, stakeholder confidence, and efficient debugging. Breaking tasks into smaller, manageable pieces ensures smoother development and quicker pivot times, keeping your team and product healthy.