Lead time
Lead time is the elapsed time from the initiation, request, or availability of work until its completion or delivery.
Automating API Delivery
Lead time is the elapsed time from when work becomes available to a process step until the completed work becomes available to the next step, including waiting and interruptions.
- How it is used
- Measures delay across API design-review steps so process improvements can be judged against observed conditions.
- How deep it goes
- Defines step-level elapsed time and shows how to record and total it on a process map, without specifying a timing tool.
- Examples
- Uses an API-review queue counted in Jira tickets and a goal to reduce total LT from 16 to 12.8 days.
- What you can do after
- Practice/perform it by mapping step lead times, recording waiting work, and checking results against a measurable A3 target.
Effective Platform Engineering
Lead time for change is the elapsed time between initiating a software change and deploying it to production.
- How it is used
- Measures delivery friction and platform value from change initiation through production deployment.
- How deep it goes
- Breaks lead time into planning, dependency, build, test, approval, and deployment intervals, stopping short of prescribing one measurement system.
- Examples
- Uses Epetech’s pipeline-stage analysis, software-delivery value-stream maps, and scripts that extract deployment data from engineering tools.
- What you can do after
- Diagnose lead-time bottlenecks, quantify planning waste, and evaluate whether platform changes accelerate production delivery.
Read how Effective Platform Engineering explains lead time →
Platform Engineering on Kubernetes
Lead time for change is the elapsed time from producing a software change to making it available to live customers.
- How it is used
- Measures software delivery velocity from change production to customer availability.
- How deep it goes
- Defines the interval and outlines event collection, transformation, calculation, storage, and presentation without detailing the formula.
- Examples
- Uses version-control events, deployment events, CDEvents mappings, PostgreSQL storage, and graphical dashboards.
- What you can do after
- Build it from CloudEvents and CDEvents by collecting, standardizing, calculating, storing, and displaying delivery data.
Read how Platform Engineering on Kubernetes explains lead time →
"Looks Good to Me"
The elapsed time from committing a code change until it successfully runs in production.
- How it is used
- Uses elapsed delivery time to assess team performance and identify review or deployment bottlenecks.
- How deep it goes
- Defines the production boundary and gives performance ranges, but defers detailed measurement procedures.
- Examples
- Uses one-to-six-month and one-week-to-one-month ranges, plus single-approver and distributed-team review scenarios.
- What you can do after
- Diagnose delivery delays by comparing lead time with review phases and other deployment-pipeline bottlenecks.
Shipping Go: Develop, deliver, discuss, design, and go again
Lead time is the elapsed time from the initiation or request of work until its delivery to the customer.
- How it is used
- Measures the wait from a raised issue or feature to customer delivery when assessing pipeline choices.
- How deep it goes
- Defines the interval, relates it to step-level cycle times, and discusses parallel-check trade-offs without prescribing a calculation method.
- Examples
- Uses linting, vetting, testing, and a pipeline configuration with test dependencies to illustrate scheduling choices.
- What you can do after
- Evaluate/understand it by identifying pipeline steps whose cycle times may delay delivery while weighing faster feedback against compute cost.
Read how Shipping Go: Develop, deliver, discuss, design, and go again explains lead time →
Architecture Modernization: Socio-technical alignment of software, strategy, and structure
Lead time is the elapsed time between the start of a work process and the completion or delivery of its result.
- How it is used
- Uses elapsed duration to reveal process bottlenecks affecting customers, revenue, operating costs, and delivery performance.
- How deep it goes
- Defines measurement boundaries and encourages comparing duration ranges, but does not develop statistical analysis or implementation details.
- Examples
- Illustrates customer orders, restaurant onboarding, code deployment, and case processing through internal tools.
- What you can do after
- Diagnose/debug with it by locating slow processes, measuring duration ranges, and prioritizing workflow or tooling improvements.
Related concepts
- DORApart of · DORA is a research and measurement framework for software delivery performance, commonly using deployment frequency, lead time for changes, change failure rate, and time to restore service.
- cycle timecontrasts with · Cycle time is the elapsed time required for a work item, process, or production cycle to move from a defined start point to completion.
- queue timeused by · Queue time is the duration an entity or work item waits before receiving service or beginning processing.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.