Delivery flow and lead time
How long does a change take from decision to production — and where exactly does it sit waiting?
~/appetizer-labs/engineering-growth-assessment
Engineering Growth Assessment
Growth without the delivery drag
Find out whether your engineering organization and technical platform can carry the next stage of growth — and where to invest before complexity, operational risk and coordination cost climb further.
30 minutes, free, no sales conversation.
More engineers, same delivery speed
The pattern repeats: the company grows, the engineering budget grows with it, and the time from decision to production gets longer anyway. The reflex is to hire. In most organizations the problem is not capacity but structure and delivery: unclear ownership, a platform that produces tickets instead of self-service, operational work nobody owns, and decisions resting on too few people. Adding engineers does not fix that — it adds coordination, which is the constraint.
When this assessment is the right call
- Engineering headcount has grown; throughput has not.
- A new product, market, acquisition or major customer rollout is coming.
- The CTO or senior engineering leader has left, or responsibilities have blurred.
- Platform and operational complexity are outgrowing product capability.
- A handful of key engineers carry disproportionate load — holidays are already a risk.
- A large decision is pending: a hiring wave, a reorganization, a cloud migration, a platform investment.
- The board wants an independent second opinion before signing off a six- or seven-figure budget.
Who it is for
For the person accountable for the investment decision — and for the technical leadership who will have to make it work.
- CTOs and VPs of Engineering facing the next stage of growth who want to know what breaks first.
- Heads of Engineering running several teams who are losing sight of where the constraints actually are.
- Managing directors and technical programme owners who need an independent read before a major investment.
- Engineering organizations of roughly ten to eighty developers, where growth has already started producing coordination cost.
- Investors and board members assessing whether a portfolio company's engineering can scale — with that company's agreement.
Who it is not for
Better to rule it out now than to disappoint later. This is the wrong instrument when:
- You already know what to do and need delivery rather than analysis. Start with the delivery.
- There is no executive sponsor allowed to act on the findings.
- What is wanted is a report that ratifies a decision already taken.
- The goal is evaluating individual employees. We assess systems, processes and ownership — not people.
- One team, one product, one manageable codebase: an architecture review or a workshop will serve you better.
What this explicitly is not
These boundaries exist so a fixed scope cannot drift into an unlimited audit. Any of them can be scoped separately if the assessment shows it is warranted.
- not a penetration test or a security certification
- not a line-by-line code audit of every service
- not a cloud migration or any implementation work
- not a performance review of individual employees
- not strategy consulting without technical verification
- not a promise of a specific productivity or growth percentage
How this differs
Classic management 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 runs the interviews writes the report and sits in the readout.
Not to be confused with the Delivery Bottleneck Assessment, which looks at one delivery path and its lead time and answers what constrains flow over the coming weeks. This assessment looks at the whole engineering organization — structure, platform, leadership, cost and risk — and answers whether it carries the next stage of growth.
Questions it answers
Each one gets an answer with its reasoning attached — not a list of observations.
- 01Can the engineering organization support the company's next stage of growth?
- 02Where will delivery capacity break first?
- 03Is platform complexity growing faster than engineering output?
- 04How much time do teams lose to coordination, ownership gaps and operational toil?
- 05Do you need more people, better systems, clearer leadership — or a different operating model?
- 06Which investments raise throughput, and which only add complexity?
What we look at
Twelve dimensions, each with a guiding question. Anything irrelevant to you is ruled out in the fit check — the scope stays fixed, the depth goes where the risk is.
Organization and ownership
Who owns which part of the system, and where does ownership stop at a boundary nobody may cross?
Platform maturity and enablement
Can teams ship on their own, or does every step require a ticket with another team?
Architecture and operational complexity
Does the architecture scale with the number of teams, or does it force coordination on every change?
Reliability and incident burden
How much capacity does operations consume — on-call, incidents, rework — and is the trend rising?
Infrastructure cost trajectory
Do cloud and operating costs grow with the business, or faster than the business?
Onboarding and team autonomy
How long until a new engineer ships independently — and what is the actual reason for that number?
Technical leadership and decision-making
Where are technical decisions made, how are they recorded, and who is allowed to disagree?
Knowledge concentration and key-person risk
Which systems are understood by exactly one person, and what happens when that person is away for two weeks?
Governance, security and compliance constraints
Which regulatory and security constraints limit pace, and which of them are self-imposed?
Hiring assumptions versus productivity limits
What additional delivery does the hiring plan assume, and does that assumption survive the current structure?
Readiness for products, markets, teams, acquisitions
What has to be in place so a new product, market or acquired team is not blocked by what already exists?
How it runs
Eight steps, fixed scope. You know in advance whose time is needed and when.
- 01
Fit check and scoping
One conversation: growth trigger, business objective, teams involved, boundaries of the scope. If we are the wrong people, you hear it here — not after the order.
- 02
Kickoff
Hypotheses, available evidence and interview partners are agreed. The clock starts here.
- 03
Evidence review
Architecture, delivery system, reliability, cost, ownership and governance — against whatever exists today.
- 04
Interviews
Executive level, engineering leadership, platform and operations, and engineers from the product teams. Confidential, individual, no minutes sent upstairs.
- 05
Constraint analysis
We separate symptoms from causes and name the assumptions that do not hold.
- 06
Prioritization
Urgent risks, quick wins and structural investments are separated and put in an order.
- 07
Executive readout
One session with the executive level: decisions, trade-offs, and the recommended investment sequence.
- 08
Technical handover
One session with technical leadership: roadmap, owners, dependencies, and the metrics worth collecting from now on.
What you bring
Without these the result is thin. Beyond them we need nothing:
- one executive sponsor
- the company's current growth or change objective
- an overview of the organization and its ownership model
- a high-level view of architecture and platform
- whatever delivery, reliability, incident and cloud-cost figures exist
- access to the people we interview
- existing roadmaps, prior audits or transformation plans
Missing metrics do not block the engagement. If you do not measure lead time or the cost of incidents, that is itself a finding and appears in the report as one. The fit check needs no architecture diagrams, no access and no production data.
What you get
One report, two sessions, a basis for a decision. All of it is yours afterwards.
- Executive summary
- The situation in two pages, in the language the board uses.
- Engineering growth risk map
- Where growth meets its limits, ordered by proximity and business impact.
- Current-state maturity
- A position per dimension, each with the evidence it rests on.
- Primary constraints and root causes
- The limiting factors, separated from their symptoms.
- Ownership and key-person risk
- Which systems hang on individuals, and what an absence costs.
- Prioritized opportunities
- What is worth doing, in a justified order.
- Quick wins versus structural investments
- Listed separately, so the urgent does not crowd out the important.
- 90-day action plan
- What happens in the first 90 days, with owners and dependencies.
- 6 to 12 month capability roadmap
- Which capability has to exist by when for the growth objective to hold.
- Recommended engagement path
- If external support makes sense — as an option, never as a precondition.
- Executive readout and technical handover
- Two sessions: one for the decision, one for the delivery.
Every recommendation in the report carries seven attributes: evidence, expected impact, urgency, effort range, dependency, accountable role, and how confident we are. A recommendation without evidence does not enter the report.
Duration
5 to 8 business days from kickoff to readout. Effort on our side is typically 4 to 6 consultant days — the rest is your calendar.
- 5 to 8 business days end to end, depending on how quickly interviews can be scheduled.
- 3 to 6 interviews of 45 to 60 minutes across leadership, platform and product teams.
- Two sessions with you: readout and technical handover.
- The fit check beforehand takes 30 minutes and costs nothing.
Price
A fixed fee, not a day-rate negotiation. It starts at 6,500 to 9,500 euro plus VAT and travel. What you buy is not consultant days but an independent basis for a decision and a prioritized investment plan.
- Where you land in the range follows the number of teams and product areas, not the number of meetings.
- Larger or heavily distributed organizations get their own scope after the fit check — a different offer, not an inflated one.
- The price is fixed before the order and does not move during delivery.
- A follow-on engagement is not part of the offer and not a condition of it.
If the fit check shows a smaller cut is enough — an architecture review, a facilitated decision workshop — we say so and sell the smaller format.
What the output looks like
The report always follows the same structure. It is set out in full below, together with one recommendation card in exactly the form it takes in the report.
Report structure
- Executive decision summary
- Growth objective and the assumptions behind it
- Current-state capability map
- Top risks and constraints, each with evidence and business consequence
- Ownership and key-person risk map
- Investment options and their trade-offs
- Quick wins
- 90-day action plan
- 6 to 12 month roadmap
- Metrics and measurement gaps
- Recommended owners and sequencing
- Optional implementation paths
One recommendation from the report
Sample recommendation — structure, not content
- Evidenceexample pending
- The measurement or observation the recommendation rests on, with its source.
- Expected impactexample pending
- What changes if it is implemented — as a direction and an order of magnitude, never as a promised number.
- Urgency
- Now, this quarter, or plannable — with the event that sets the deadline.
- Effort range
- A range rather than a point estimate, with the assumptions behind it.
- Dependency
- What has to be in place before the change can have any effect.
- Accountable role
- The role that owns it — named as a role, not as a person.
- Confidence
- High, medium or low, with the reason it is not higher.
Two fields are marked as pending. In a real report they carry a concrete finding, and they stay empty here until a client approves publication of an anonymized example. We do not fill them with invented numbers — that would be exactly the kind of evidence this report 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, platform and architecture work in enterprise settings, modernization of systems that grew organically.
What is deliberately absent: outcome metrics. We publish no number a client has not approved, and this offer is new — so there are none yet. What you can check instead: the project patterns in the references, and public code.
Frequently asked questions
Do we have to keep working with you afterwards?
No. The report is written so your own team can act on it: owners, dependencies and sequence are in it. If you want support, there are paths for that — they are an option in the report, not a condition of it.
We do not measure lead times. Does this still work?
Yes. Missing measurement is itself a finding, and one of the most common. We work with what exists — ticket history, deployment history, incident records — and above all with the interviews. The report then names the three to five metrics worth collecting from that point on.
How much of our time does it cost?
45 to 60 minutes per interview partner, plus two shared sessions for readout and handover. Pulling the material together usually takes half a day. We ask for nothing beyond that.
Do you evaluate individual employees?
No, and we do not supply material for it either. Interviews are confidential; the report names roles and systems, not people. If a statement would only make sense with a name attached, we rewrite it or leave it out.
Is this a security audit or technical due diligence?
Neither, although they overlap. We assess no certification readiness and run no penetration test. Due diligence in an investment context has a different scope — ask us, and the fit check will establish whether this format fits.
Who actually runs it?
The founder, throughout. Whoever runs the interviews writes the report and sits in the readout. There is no junior team feeding in material and no handover to someone who knows your situation only from notes.
What happens after we get in touch?
You get a reply within two business days with two proposed slots for the 30-minute fit check. After it you receive a fixed-price offer with scope, schedule and the interview partners required — or a recommendation to do something else.
~/appetizer-labs/fit-check
Discuss the assessment
Describe your situation briefly. 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