Idea-to-production lead time
How long does a change take from decision to release — and how much of that is waiting rather than work?
~/appetizer-labs/delivery-bottleneck-assessment
Delivery Bottleneck Assessment
Find what constrains delivery, and remove it in order
Find out where your delivery actually stalls, what that waiting costs in lead time, release risk and tied-up capacity — and in what order to remove the constraints over the next 30, 60 and 90 days.
30 minutes, free, no sales conversation.
The work is finished. That is not the same as shipped.
In most organizations development is not the slow part — the path afterwards is. A change is written in hours and takes days or weeks to reach production: it waits for a review, for an environment, for a build that fails for the third time with nothing wrong in the code, for an approval whose actual criterion nobody can still name. None of that waiting appears in an estimate or on a ticket. It becomes visible when a date slips, and the answer then usually lands on capacity: hire more engineers. But adding people does not raise the throughput of a system constrained somewhere else. It raises the amount of work started in front of the same constraint.
When this assessment is the right call
- A committed delivery date slipped and nobody can show why.
- The roadmap is agreed, delivery is not keeping pace, and it is already a leadership topic.
- You hired, and output did not follow.
- A major customer rollout, an audit or a certification is coming, and release capability is the risk.
- An incident showed how long it actually takes you to get a fix into production.
- A platform or modernization programme has been running for months and lead time has not moved.
- The board is asking whether more engineers solve this, and you want to answer with evidence.
- The cloud bill grows faster than what reaches production.
Who it is for
For the person accountable for delivery speed — and for the technical leadership who will remove the constraints afterwards.
- CTOs and VPs of Engineering accountable for a delivery speed they cannot explain.
- Heads of Engineering running several teams that share one delivery path.
- Heads of Platform who need evidence for where the internal platform helps and where it is in the way.
- Technical programme owners ahead of a rollout whose date depends on release capability.
- Executives who want to know, before a hiring wave, whether capacity is the constraint at all.
Who it is not for
An assessment that helps nobody mostly costs you time. In these cases we say no ourselves:
- You already know where the constraint is and need it removed. Start with the removal.
- There is nobody at leadership level who may approve the actions afterwards.
- What is wanted is a rationale for a tooling or platform decision already taken.
- The goal is evaluating individual teams or people. We examine how work flows, not how people perform.
- One team, one repository, several deployments a day: your problem is elsewhere, and an assessment will find nothing you do not already know.
What this explicitly is not
The scope is fixed, and this list is why it stays that way. What is here is not included — and can be scoped separately if the analysis shows it is warranted.
- no predetermined root cause
- not a penetration test or a security audit
- not a line-by-line code audit
- not a tool selection or a migration
- no implementation while the analysis runs
- not a performance review of teams or individuals
- not a promise of a specific productivity gain
How this differs
Classic consulting delivers the analysis and leaves. We write recommendations we could implement ourselves — and often do afterwards. The assessment is run by the founder, not by a junior team with a slide deck: whoever walks the delivery path and runs the interviews writes the report and sits in the readout.
And it is not a Kubernetes, CI/CD or cloud audit under a new name. Those three are candidates, not a diagnosis. Just as often the constraint sits in an approval nobody can justify any more, in a team boundary drawn across the middle of a delivery path, in a decision nobody has been allowed to make for weeks, or simply in far too much work started at once. What we bring is a method, not an answer.
Not to be confused with the Engineering Growth Assessment. That one asks whether the organization and the technical system can carry the next stage of growth, and plans across six to twelve months. This one asks what constrains flow today, where work waits, and what you remove next. The methods and the interview partners overlap; the question, the report and the horizon do not.
Questions it answers
Each one gets an answer with its evidence attached — not a collection of observations.
- 01What is actually slowing your delivery down?
- 02Which constraint has the greatest business impact?
- 03Are the constraints technical, organizational, procedural or a matter of ownership?
- 04Where does work wait, where does it fail, and where does it need a human to intervene by hand?
- 05Which improvements produce measurable impact within the next 90 days?
- 06Are you treating symptoms while the actual constraint stays untouched?
- 07Do you need more engineers — or less friction for the ones you have?
Signals of a delivery bottleneck
The triggers above are what the board sees. These are what the teams see. If more than a handful apply, waiting time is larger than working time — and then capacity is not your problem.
- Between “development done” and “in production” sit days or weeks nobody plans for.
- A release is a date, not a routine. Nobody deploys on a Friday.
- Pull requests wait longer for review than they took to write.
- The pipeline fails regularly with nothing wrong in the code. Re-running it is routine.
- Getting a test environment means raising a ticket with another team.
- Approvals sit in front of production whose actual criterion nobody can name.
- The same manual work comes back every week and appears in no backlog.
- Work stands still because a decision is missing that nobody is allowed to make.
- New engineers need weeks to get their first deployment out.
- A lot is always started and little is finished.
- After a failure in production, the way back takes longer than the way there.
None of these is a diagnosis on its own. They are the reason to look properly — which of them is the limiting factor and which are merely its side effects is decided by the analysis, not by the list.
What we look at
Fifteen dimensions, each with a guiding question. Not all of them are relevant to you; what does not apply is ruled out in the fit check. The scope stays fixed, and the depth goes where the waiting is.
Deployment frequency and release risk
How often does something ship, how large has a release become, and how much does risk grow with batch size?
Change failure and recovery behaviour
How often does a change go wrong, how quickly do you notice, and how long is the way back?
CI/CD reliability and waiting time
How often does a build fail for reasons unrelated to the code, and how long does a team wait for a usable result?
Environments and developer self-service
How does a team get a test environment — by ticket, by negotiation, or on its own in minutes?
Architecture and dependency constraints
Which changes force coordination across system boundaries because those boundaries are not where the work is?
Platform usability and platform-team operating model
Is the internal platform a product with users — or a queue with tickets?
Manual approvals and handoffs
Which manual approvals and handoffs sit between finished code and production, and what does each of them actually verify?
Operational toil and incident load
How much engineering capacity goes into on-call, repeat manual work and rework — and is the trend rising?
Ownership and decision bottlenecks
Where does work stop because it is unclear who may decide, or who owns the part being touched?
Security and compliance friction
Which controls slow delivery, which of them are genuinely required, and which are habit?
Cloud and infrastructure constraints
Where do infrastructure, quotas or cost cap throughput — and where is infrastructure only the visible part of a different constraint?
Team topology and cross-team coordination
How many teams have to coordinate for an average change to reach production?
Onboarding and local-development friction
How long from day one to a new engineer's first own deployment, and what makes it that long?
Work in progress and prioritization overload
How much runs at the same time, how often does priority change, and how much of it never finishes?
How it runs
Nine steps, fixed scope. You know in advance whose time is needed and when.
- 01
Fit check and scoping
One conversation: the symptom, the delivery path involved, the deadline, the boundaries of the scope. If an assessment is the wrong instrument, you hear it here — not after the order.
- 02
Kickoff
Which delivery path is examined, what evidence exists, and who we speak to. The clock starts here.
- 03
Mapping the delivery path
We walk the route of a real change with you — from decision to production, through every handoff, every approval and every queue in between.
- 04
Evidence review
Pipeline runs, ticket history, deployment history, incident and on-call records, approval routes — against whatever exists today.
- 05
Interviews
Engineering, platform and operations, QA, security, product and leadership. Confidential, individual, no minutes sent upstairs.
- 06
Constraint analysis
We separate symptom from cause and test whether the suspected bottleneck is the one that actually limits throughput. Frequently it is not.
- 07
Impact and sequence
Every constraint gets a business impact, an effort range and a place in the order — including the dependencies that force that order.
- 08
Executive readout
One session with the executive level: the limiting constraints, what they cost, the recommended sequence and the trade-offs behind it.
- 09
Technical handover
One session with the teams involved: actions, owners, dependencies, and the metrics worth collecting from now on.
What you bring
Without access to the traces your work leaves behind, the analysis is opinion. These we need, and nothing beyond them:
- one executive sponsor
- the delivery path in question — a product, a system landscape or a group of teams
- an overview of the teams involved and where their ownership starts and stops
- read access to ticket history, pipeline runs and deployment history, or exports of them
- whatever lead-time, incident, on-call and cloud-cost figures exist
- access to the people we interview
- the approval and sign-off routes as they are actually practised
Missing metrics do not block the engagement; they are frequently the first finding. If you do not measure lead time or waiting time, that goes in the report along with the baseline you start collecting from then on. The fit check needs no access, no architecture documents and nothing from production.
What you get
One report, a map of your delivery system, two sessions. All of it is yours afterwards.
- Executive summary
- The situation in two pages: the few constraints that matter, and what they cost.
- Delivery-system map
- The real route of a change from idea to production, with every step, every handoff and every queue.
- Bottleneck and constraint analysis
- Which points actually limit throughput — and which are merely loud.
- Evidence-backed root causes
- For each constraint, the observation or measurement the finding rests on. No evidence, no finding.
- Business impact
- What each constraint costs in waiting time, delivery risk and tied-up capacity, in the language the board uses.
- Ranked bottleneck backlog
- Every constraint in a justified order rather than in a list — each with the same structure.
- Quick wins versus structural changes
- Listed separately, so the quick win does not quietly replace the structural fix.
- Action plan across 30, 60 and 90 days
- Three horizons with actions, owners and dependencies — what comes first, what follows, and what is only possible once the earlier work stands.
- Recommended metrics and baseline gaps
- The few metrics worth collecting from now on, and where no baseline exists today against which improvement could even show.
- Ownership and dependency recommendations
- Which role removes which constraint, and what has to be in place before they can.
- Executive readout and technical handover
- One session to decide the order, one for the teams who will work through it.
- Optional implementation proposal
- If you want support — an option in the report, never a condition of it being useful.
Every constraint in the backlog carries eight attributes: location in the delivery path, evidence, constraint type, business impact, effort range, horizon, accountable role, and how confident we are. A finding without evidence does not enter the report.
Duration
10 to 15 business days from kickoff to readout. Effort on our side is typically 6 to 9 consultant days — the rest is your calendar.
- 10 to 15 business days end to end, depending on how many teams are involved and how quickly sessions can be scheduled.
- 6 to 10 interviews of 45 to 60 minutes, from engineers to the executive level.
- A facilitated mapping of the delivery path with the teams involved, usually across two sessions.
- Two sessions with you at the end: readout and technical handover.
- The fit check comes first: 30 minutes, no charge, and afterwards you know whether the rest is worth it.
Price
A fixed fee, not a day-rate negotiation. It starts at 9,500 to 14,500 euro plus VAT and travel. What you buy is not consultant days but an evidenced answer to what constrains your delivery, and an order in which to remove it.
- Where you land in the range follows the number of teams and systems involved, not the number of meetings.
- Several independent delivery paths get their own scope after the fit check — a different offer, not an inflated one.
- The price is fixed before the order. It does not move when the analysis finds more than expected either.
- Implementation afterwards is an option in the report and not a condition of it.
If the fit check shows you already know the constraint and only the removal is missing, we say so and do not sell an assessment. There are other formats for that.
What the output looks like
Two artefacts, both always in the same form: the map of your delivery system, and one entry from the ranked bottleneck backlog. Both are set out below in exactly the structure you receive them in.
Example bottleneck map
Every station on the delivery path is recorded twice: the time work is actually being done, and the time it spends waiting. The bottleneck is almost never where the most work happens.
Idea and decision
When the decision was made, how long it then sat untouched, and who had to make it.
working timewaiting time
Ready for work
How long shaped work waits before it starts, and how often it is re-prioritized before it does.
working timewaiting time
Development
The actual working time — and how often it is interrupted for something else.
working timewaiting time
Review
Waiting time for a review, the number of rounds, and whether reviewers are even allowed to be the ones to approve.
working timewaiting time
Integration and build
Pipeline runtime, failures unrelated to the code, and the time until a usable result.
working timewaiting time
Test environment
How an environment comes into being, how long that takes, and whether it resembles production.
working timewaiting time
Approval
Which approvals are required, who grants them, how long they sit, and what criterion is actually checked.
working timewaiting time
Production
The route live, what happens when something fails, and how long until the previous state is restored.
working timewaiting time
What is deliberately absent here are the numbers: in a real map every station carries measured working and waiting times. Those numbers belong to the client they came from, and we publish none that has not been approved. So what you see is the structure, not the contents of somebody else's project.
One entry from the bottleneck backlog
Sample entry — structure, not content
- Location in the path
- The station on the map where work actually stops.
- Evidenceexample pending
- The measurement or observation the finding rests on, with its source and period.
- Constraint type
- Technical, procedural, organizational or a question of ownership — because that decides who can remove it.
- Business impactexample pending
- What the constraint costs in waiting time, delivery risk and tied-up capacity — as a direction and an order of magnitude, never as a promised number.
- Effort range
- What removing it costs — as a range, with the assumptions under which it holds.
- Horizon
- Whether the action belongs in the first 30 days, by day 60 or by day 90 — and what forces that position.
- Accountable role
- Who is able to remove it — named as a role, not as a person.
- Confidence
- How solid the finding is, and what is missing for it to be solider.
Two fields are marked as pending. In a real report they carry a concrete finding with a measured number, and they stay empty here until a client approves publication of an anonymized example. We do not fill them with invented values — that would be exactly the kind of evidence this assessment exists to challenge.
Why us
The assessment is run by Matthias Bruns, founder of Appetizer Labs: 15+ years in software engineering and technical leadership, the most recent of them in cloud-native and platform engineering. The basis is projects where these questions were answered in practice — technical leadership of distributed teams, building and cleaning up delivery systems, platform and architecture work in enterprise settings.
What is deliberately absent are before-and-after numbers. An assessment advertising its own effect with unevidenced metrics would have broken the first rule it sets itself. What is checkable instead: the project patterns in the references, and public code.
Frequently asked questions
Isn't this just a DORA assessment?
No. DORA metrics are an instrument, not a finding: they tell you that you ship rarely, not why. Where the numbers exist we use them; where they are missing, that is itself a result. The report explains the cause and names the station on the delivery path where it sits.
We do not measure lead time. Does this still work?
Yes, and it is the most common starting point. We work with what exists — ticket history, pipeline runs, deployment history, incident records — and above all with walking the delivery path together. The report then names the few metrics worth collecting from that point on, and where no baseline exists today at all.
Will the answer turn out to be Kubernetes or a new pipeline?
Only if the evidence leads there. We start with no predetermined root cause, and in practice the limiting factor sits at least as often in an approval nobody can justify, a team boundary, a decision nobody is allowed to make, or simply far too much work started at once. An assessment that already knows the answer is not worth buying.
How does this differ from the Engineering Growth Assessment?
This one looks at current flow: where work waits, what that costs, what you remove next. The Engineering Growth Assessment looks at whether the organization and the technical system can carry the next stage of growth, over a considerably longer horizon. If you are unsure which fits, the fit check settles it — that is one of the reasons it exists.
How much of our time does it cost?
45 to 60 minutes per interview partner, plus the facilitated mapping of the delivery path with the teams involved and two shared sessions for readout and handover. Pulling the evidence together usually takes half a day. We ask for nothing beyond that.
Do you evaluate individual teams or people?
No, and we do not supply material for it either. What is examined is how work flows through your system. Interviews are confidential; the report names stations, roles and systems, not people. If a finding would only make sense with a name attached, we rewrite it or leave it out.
What if the constraint is not technical at all?
Then that is what the report says. A constraint in prioritization, approval or ownership is as legitimate a result as a technical one — and frequently the more uncomfortable. We write it down anyway, because a report that names only the things we could implement ourselves is not worth its fee.
Do we have to keep working with you afterwards?
No. The report is written so your own team can act on it: actions, owners, dependencies and sequence are in it. If you want support, there are paths for that — an option in the report, not a condition of it.
What happens after we get in touch?
A reply arrives within two business days with two proposed slots for the 30-minute fit check. In it we establish which delivery path is examined and whether this format is the right one at all. Then you get a fixed-price offer with scope and schedule — or a recommendation to leave it.
~/appetizer-labs/fit-check
Discuss your delivery bottleneck
Describe briefly where it is stuck. You get an assessment of whether this fits your situation — including when the answer is that you do not need it.
Not sure yet whether this is the right engagement? Settle it in a quarter of an hour, with the engineer who does the work. Book a fit check