Cycle Time Reduction
Cycle Time is the elapsed time from when work enters a process to when it exits — START to FINISH on a single unit. It is THE metric for operational responsiveness, working capital, and customer experience. Don't confuse it with Takt Time (rate of customer demand) or Lead Time (the broader window including queue time before work starts). Cycle Time is the workhorse number. The math everyone misses: most processes are 95%+ WAIT TIME — value-added work is a tiny slice. A 10-day cycle time for a process with 4 hours of actual work has Process Cycle Efficiency (PCE) of 4/240 = 1.7%. Improving the work itself (shaving 30 min off the 4 hours) yields negligible gains; eliminating the 9.8 days of queue wins 90%. KnowMBA take: every operations problem is a queue problem in disguise. SaaS engineering teams obsessed with making coding faster while ignoring 6-day code review queues are optimizing the wrong 5%.
The Trap
Teams measure cycle time but never decompose it into VALUE-ADDED time vs. WAIT time. Without decomposition, every improvement project tries to make value-added work faster — automating, training, buying tools — when 95% of cycle time is queues nobody is looking at. The other trap: optimizing average cycle time while variance explodes. A team can hit 'average cycle time = 4 days' with half the work taking 1 day and half taking 7 — terrible for customer experience. Track P50, P90, and P99; the tail is what kills you. And measuring cycle time without measuring throughput leads to sub-optimization (you can shorten cycle time by halting new work entirely).
What to Do
Measure cycle time for your current process. Then decompose: walk one unit through and clock VALUE-ADDED time vs. WAIT time at each step. Compute Process Cycle Efficiency (PCE = Value-Added Time ÷ Total Cycle Time). If PCE < 25%, the win is in eliminating queues — apply pull (WIP limits), reduce batch size, eliminate handoffs, co-locate cells. If PCE > 25%, the remaining win is in the work itself — automation, parallelization, standardization. Re-measure monthly. Target a 50% cycle-time reduction in the first 90 days; world-class is PCE > 25%.
Formula
In Practice
Amazon Fulfillment by Amazon (FBA) compressed warehouse cycle time from order-to-shipped from a 24-hour industry standard (in 2005) to under 60 minutes by 2018 in flagship facilities. The trick wasn't faster picking — Amazon's pickers walked at the same pace as everyone else. The wins came from cutting QUEUE time: kiva robots eliminated walking-to-shelf wait by bringing shelves to pickers; pre-staged packing materials eliminated material-fetching wait; algorithmic slotting put high-velocity items closest to pack stations. Value-added time per order rose only modestly; total cycle time collapsed because Amazon attacked the queue, not the work. Same insight, scaled to billions of orders.
Pro Tips
- 01
Decompose cycle time into 4 buckets: (1) Value-added work, (2) Necessary non-value-added work (compliance, setup), (3) Waiting in queue, (4) Rework. Most teams find 5% / 5% / 80% / 10%. The 80% queue time is the real opportunity — and it's almost free to attack via WIP limits.
- 02
Tail latency matters more than average. A P99 cycle time of 30 days with average 4 days means 1% of customers have a horrible experience — and they're the ones who churn loudly. Track P50/P90/P99; an optimization that lowers P99 by 50% beats one that lowers average by 30%.
- 03
For software teams: PR cycle time (open → merged) is the highest-leverage cycle to attack. Industry P50 is 1-2 days; high-performers are 4-12 hours; elite is under 1 hour. Most of the time is review queue. Smaller PRs + WIP-limited reviewers + automated checks routinely cut this 5x.
Myth vs Reality
Myth
“Faster cycle time means working faster (more pressure on people)”
Reality
Almost the opposite. Most cycle-time wins come from removing queues and handoffs — work is calmer, not faster. People feel less pressure because work moves smoothly instead of slamming through bursts of activity separated by waiting. Speed without burnout is a queue problem solved.
Myth
“Long cycle time is fine if average throughput is high”
Reality
Throughput tells you how MUCH gets done; cycle time tells you HOW LONG each unit waits. A team can have great throughput AND terrible cycle time — meaning customers wait days for what could ship in hours. Cycle time correlates directly with customer experience, working capital, and ability to absorb shocks. Both metrics matter.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.
Knowledge Check
Challenge coming soon for this concept.
Industry benchmarks
Is your number good?
Calibrate against real-world tiers. Use these ranges as targets — not absolutes.
Process Cycle Efficiency (PCE)
Cross-industry: manufacturing, software, services, healthcareWorld-Class (Continuous Flow)
≥ 50%
Strong
25-50%
Typical
10-25%
Weak
5-10%
Crisis
< 5% (mostly queue)
Source: Lean Enterprise Institute / Michael George, Lean Six Sigma
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
Amazon (FBA Fulfillment)
2012-2018
Amazon FBA's order-to-shipped cycle time was a 24-hour industry standard when launched. Through Kiva robotics (acquired 2012), algorithmic slotting, pre-staged packing, and parallel fulfillment paths, they compressed the cycle to under 60 minutes in flagship facilities by 2018. Crucially, value-added work per order (actual picking, packing, labeling) only dropped modestly — most of the cycle compression came from eliminating WAIT time: walking to shelves, fetching materials, queueing for ship labels. PCE on a typical FBA order rose from ~5% to ~40%.
Order Cycle Time (2012)
~24 hrs
Order Cycle Time (2018)
< 60 min
PCE Estimate
5% → 40%
Same-Day Eligible Orders
Industry-leading coverage
Cycle-time wins at scale come from attacking queues and waits, not from making humans work faster. Amazon proved this at billions of orders.
Hypothetical: Mid-Market Insurance Claims Processor
Recent
A 400-employee insurance claims operation had a 14-day average cycle time per claim. PCE measurement revealed only 22 minutes of value-added work per claim — PCE of ~0.4%. The team's improvement proposal was 'process automation software' ($1.2M). A consultant pushed instead for queue elimination: WIP limits per adjuster (max 8 open claims), elimination of 3 redundant approval handoffs, co-location of claims and underwriting teams. Cycle time dropped from 14 days to 2.5 days in 6 months. Cost: $80K. Customer satisfaction NPS rose 28 points.
Cycle Time Before
14 days
Cycle Time After
2.5 days
PCE
0.4% → ~6%
Cost
$80K (vs. $1.2M proposed automation)
Before buying automation, measure PCE. If it's under 10%, the queue is the problem and automation will only speed up a small fraction of cycle time. Fix the queue first; automate after.
Related concepts
Keep connecting.
The concepts that orbit this one — each one sharpens the others.
Beyond the concept
Turn Cycle Time Reduction into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h · No retainer required
Turn Cycle Time Reduction into a live operating decision.
Use Cycle Time Reduction as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.