Everything feels…slow. You have an idea, or a critical feature, or an urgent bug fix, but it takes forever to send it through the process. Half the time it feels like it’s not even going through the process, it just dies on someone’s desk. Vanishing into the black box for weeks or months is a silent killer, and it’s both frustrating and disrespectful for anyone who’s making requests/demands on an engineering team.

Conversely, an engineering team will often feel like they are crushing it. They see their personal or team velocity is high, or their cycle time is low, and they feel BUSY—maybe too busy. There’s a mountain of bugs to fix and features to implement, plenty of tech debt to resolve, lots of refactoring to do, and calendars full of meetings and planning. But where are the results?

The truth is that it’s rarely a silver bullet fix. It’s probably not just a coding problem, not just a people problem, and not just a process problem. If you’re sailing your “ship” around, it likely has lots of little leaks.

Good news though, there is a single metric you can use that will expose every crack, bottleneck, and wasteful activity in your entire product development system.

Lead Time.

Lead Time is the total time from the moment an idea is requested to the moment it is live and in the hands of your customer.

That’s it. From “Hey, we should…” to “It’s live.”

It includes everything. The time it sits in a backlog. The time it’s “waiting for design.” The time it’s debated in a “prioritization” meeting. The time it’s being coded. The time it’s waiting for review. The time it’s waiting for a “QA” team. The time it’s waiting for the “next deployment.”

This number is your company’s true speed. And if your Lead Time is measured in weeks or months for bite-sized tasks, it’s a blaring-red alarm. It’s not just a sign of a problem; it’s a map to the problem.

Lead Time vs Cycle Time vs Troglodyte Cycle Time

Unfortunately, people in the so-called agile world love to jumble around terms and not actually know what anything means, so nowadays there is confusion because the geniuses over at Scrum used Cycle Time instead of Lead Time. They also decided to redefine Cycle Time to not include dead time, waste, handoffs, etc. This is Troglodyte Cycle Time because idiots use it to show how great they are by completely ignoring all of the broken and slow parts of their process.

Have you ever wanted to be a professional hater? Well then look no further than the horrible people who redefine words. Even the Wikipedia article on Cycle Time is confused, because they quote non-authoritative sources. They even have opposing definitions in consecutive sentences! Ridiculous.

Lead Time is supposed to be for pretty much everything, soup to nuts, from the time of ideation to delivery. There are some refining adjectives you can use on the fringes, like whether to include the time period from ideation to commitment, or from software deploy to release (like if you have feature flags, canary releases, etc). You can decide whether to include those fringes, depending on your business.

Cycle Time is a measure of the actual production process, and is a subset of Lead Time, which also includes pre- and post-process time. Cycle Time is also important! But it doesn’t get you the entire picture, and often isolates a software team who thinks they are doing great, because within their purview everything seems great—but they are ignoring how long it takes something to go from a dream to code, and from code to production. And guess what? There’s usually a lot of waste in those gutters.

Importantly, Cycle Time should include all the little handoffs. If code review is a required part of your software engineering process, and you have a 3 day delay between asking for code review and receiving code review, you should not ignore that—it’s baked in.

What Your Long Lead Time Is Really Telling You

When your Lead Time is 60 days, here’s the pain you’re actually feeling.

1. Your Best Ideas Are Rotting in a “Good Idea” Cemetery

This is the “waste” you were right to point out. It’s your backlog. It’s the list of “urgent” requests and “must-have” features that are sitting there, depreciating in value every single day.

You paid for that market research. You paid for that customer feedback. And now it’s just… waiting. Waiting for a meeting, waiting for a designer, waiting for a “sprint.” By the time you finally build it, the market has moved on, your customer has churned, and your “brilliant” idea is irrelevant. This is a list of broken promises to your customers and your own company.

2. You Are Paying Your Team to Play “Priority Hot Potato”

A long Lead Time is a classic symptom of leadership chaos.

Your team starts on Feature A. But then you run from a sales call and declare Feature B is the new “top priority.” Then a support ticket for Bug C lights up.

Your team is constantly stopping, starting, and context-switching. Every time you do this, you’re not just delaying one feature; you’re delaying all of them. You’ve created a system where nothing can get finished. Everyone is “busy,” but no one is delivering. You’re paying for a factory, but you’re running it like a “whack-a-mole” game.

Side note, this is super demoralizing to engineers, because the emotional reward of actually being able to completely deliver something is often zapped, and engineers are pulled away to whatever the Next Big Thing™ is.

3. Your Business Is Too Unpredictable to Run

How can you promise a feature to a major client when you have no idea if it will take two weeks or two quarters?

You can’t.

How can you plan a Q4 marketing launch around a new capability?

You can’t.

When your Lead Time is long and erratic, you have zero predictability. You aren’t running a business; you’re running a casino. You’re making bets, pulling the lever, and just hoping the right features come out. You can’t make plans, you can’t make promises, and you can’t build a strategy on a foundation of “maybe.”

Guess what this does to people? It stresses them out, tires them out, and makes them act in very nasty ways. Bad managers will often resort to a death march, or yelling, or cracking the whip. Good managers will quit and find another place to work.

4. Your “Process” Is Strangling Your Product

Let’s say your engineers are actually superstars. They code that new feature in two days flat. (This is their “Cycle Time”).

But if the Lead Time is still 30 days… what’s happening in the other 28?

Handoffs. That’s what. The idea needs approval. Someone has to actually make a decision. Managers have to, you know, decide things. And the Cycle Time is probably not too great either. The code is “waiting for review.” Then it’s “waiting for QA.” Then it’s “waiting for a merge.” Then it’s “waiting for the Friday deployment.”

Your “process” has become a series of bureaucratic tollbooths, and each one is a bottleneck. You’ve created a system so “safe” that you’ve made it impossible to ship.

So, What Do You Do?

This isn’t just a “tech” problem. In fact, it’s rarely just a tech problem. It’s a system problem.

Go to your engineering and product leaders. Don’t ask them to “work faster.” Ask them this one, simple question:

“What is our average Lead Time from request to delivery, and what are the bottlenecks?”

If they don’t know the number… you have your first problem. (You’re flying blind).

If they know the number, but they blame the engineers… you have your second. (They’re only seeing half the picture).

If they don’t know the bottlenecks, that’s your next step.

The answer is almost always in the “waiting.” It’s in the handoffs. It’s in the prioritization. It’s in the system.

Start measuring Lead Time. Include everything. Take a deep look at how something is made along the way, and see how much of it can be removed, improved, or automated.

It’s the true, honest, and often painful measure of your company’s ability to learn, adapt, and win.