Do they work more hours?
Have brilliant engineers?
The free cold brew keg in the office?
Nope. It's none of those things.
Rather, it's the speed and quality of their execution. Behind many of the notable teams (Google, Spotify, etc) lies a secret weapon: optimized Cycle Time.
"Cycle time compression may be the most underestimated force in determining winners and losers in tech."
- Marc Andreessen
In its simplest form, Cycle time can be calculated from the time of first commit to pull request merged. In other words, the speed of your development.
"Development" can be broken down into 2 distinct phases:
At Haystack we focus on the delivery phase.
Unlike the design phase, engineering teams have full control over the delivery phase - making it better suited to measure and optimize at the engineering level.
From technical debt to context switching - there are about a thousand things that can affect an engineering team. They all impact Cycle Time. This makes Cycle Time a strong signal for when problems arise - giving teams a feedback loop for improvement.
Teams optimizing Cycle Time typically see:
Cycle Time flags problems and when we can see the impact, it's easier to make improvements (hiring, automation, refactors). In the same way we iterate on our product, we can start iterating on how we deliver.
Teams who optimize Cycle Time end up focusing on smaller, more manageable chunks of work. This makes code review faster and easier. Developers get feedback earlier in the process and - since changes are kept small - they are less likely to make mistakes. All this boils up to less Rework and less bugs in production.
3) Happier Developers
When you can see how much time you're wasting on things like tech debt - all of a sudden that refactor we've been putting off starts to make a lot more sense. As we remove friction in our process we're improving the developer experience as well - leading to higher rates of engineering satisfaction and motivation.
Cycle Time helps dev teams build better code, deliver faster and remove friction in their processes.
That's a win-win-win.
Just about every developer, team, and company wants to ship faster, build better code, and deliver more value to customers. Cycle Time gives us a tool to do that.
By understanding their Cycle Time, dev teams can:
All factors from tech debt to context switching impact Cycle time. This gives us a benchmark to quickly spot outliers and investigate where problems may lie. To get a baseline, average together the cycle time from the past 6 months - giving you an average across a variety of tasks.
Our baseline gives us a reference point to notice when one task is not like the others. This often reveals common, fixable issues in our development process. This examination often reveals one of many common inefficiencies:
The inefficiencies above often go unnoticed, building up in the background. Cycle Time helps us reduce our own bias, replace our gut feelings, and quickly identify the sources of inefficiency. Now we can make changes, experiment, and see if our changes make a positive difference to development.
Cycle Time gives teams a framework to remove friction for engineers and drastically increase their rate of improvement.
Unfortunately, we (as humans) have a tendency to overestimate the uniqueness of our work, misjudge our efficiency, and favor gut feeling over measured metrics.
Let's go over a few (incorrect) assumptions:
Everyone wants to believe that the work they’re doing has never been done before but no matter how novel your product is, your work can still be broken down into simple, uniform tasks. We find that most teams who are skeptical for this reason tend to suffer from complex project scopes and lack of detailed planning. Improving Cycle Times ends up making these 'unique' projects smaller, more manageable, and more consistent.
While our gut is great for deciding what to eat for dinner, it's not so great for judging efficiency. Teams relying solely on 'gut feelings' tend to have higher Cycle Times and are more likely to report recurring, unaddressed problems in their retrospectives. Without Cycle Time, teams are left with endless debates about distracting meetings, context switching, or that refactor they all want - significantly impairing their ability to drive improvement.
Trust is the x-factor to high performing teams - but it's not enough. Trust doesn't help us identify inefficiency, measure if our changes are working, or effectively experiment on process. At the end of the day trust is still based on gut feelings. Of course, building trust is step one but it's not the finish line. In fact teams reporting high levels of trust are able to use Cycle Time more effectively and drive exponentially higher rates of improvement.
Some managers fear that Cycle Time, can be gamed. But, let's imagine what 'gaming' Cycle Time looks like. In fact, I'll teach you how to game it. Smaller pieces of work, reduce work in progress, and make your pull requests as easy as possible for others to review. Congrats, you just gamed Cycle Time and implemented industry best practices in the process. High score!
Cycle Time gives us a view into how our team works and where we get stuck. It's a feedback loop for improvement which allows us to ship quality code faster and improve the lives (and sanity) of developers. If you're interested in empowering your team to improve, getting a baseline to quickly spot problems, and working with your team to remove the friction they all run into - then we would urge you to start using Cycle Time.
Trust us, your team will thank you.
Haystack helps engineering leaders identify burnout and team health patterns. Instead of guessing if you're improving, or constantly bothering your team for updates, simply use Haystack to get alerts in your inbox every morning. Plus a dashboard to track improvements over time.
Discover our latest articles, feature releases, and more!