§ WHAT WE FIX

Engineering Velocity and Delivery Consulting

The team is the same size it was two quarters ago and ships noticeably less. We find where the time actually goes — measured from the repository, not from a retro — and rebuild the parts that leak it.

Who
Founder holds the engineering leadership seat; the delivery team executes underneath it.
Request a call What this covers

What you're seeing

Headcount grew and throughput did not.
Usually means The coordination cost of the extra people has absorbed their output. It is a structural result rather than a motivation one, and hiring more engineers makes it worse.
Roadmap commitments are slipping and every explanation is different.
Usually means Nobody has measured where the time goes, so each explanation is a recollection. Recollections converge on whatever was most annoying recently rather than on what was most expensive.
Deploys have quietly become an event.
Usually means Somewhere the deployment path got risky enough that people batch changes to avoid it. Batching makes each deploy riskier, which is why this one compounds without anybody deciding anything.
The test suite takes long enough that engineers do something else while it runs.
Usually means Past roughly ten minutes the suite stops being a feedback loop and becomes a checkpoint. The cost is not the minutes; it is the context switch and the batching that follows it.
Code review is queued behind the same two people.
Usually means Review capacity is concentrated, usually because only two people are trusted to approve certain paths. It shows up as review latency and it is really an ownership problem.
A board is asking why engineering spend rose and output did not.
Usually means There is no delivery measurement anyone outside engineering can read. That is a reporting gap first, and the answer is only credible if it comes from data that existed before the question.

The pattern

Headcount grows, throughput does not, and everyone in the room has a different explanation.

Usually more than one is true at once. A test suite that takes long enough to discourage running it. Code review queued behind two people who are also the two busiest. A deployment path risky enough that any reasonable engineer batches their changes, which makes the next deploy riskier still. None of these is anyone’s fault and none of them appears on a roadmap, which is exactly why they persist through several quarters of people trying harder.

The compounding is the part that surprises people. A slow build does not cost you the build minutes — it costs the context switch, then the batching, then the larger change sets, then the longer reviews, then the riskier deploys. By the time it is visible at the board level, four separate things are wrong and they are wrong because of each other.

Measured before it is discussed

Cycle time, review latency, deploy frequency and change failure rate are already in your Git and CI history. We reconstruct them for the past year before anyone is interviewed.

There are two reasons for that order. The first is accuracy — a retro produces theories, and theories name whoever is absent. The second is political: a conversation that starts from a measurement of the system is a different conversation from one that starts by asking people what is going wrong, and the second one produces answers shaped by what is safe to say.

The interviews still happen, and they are where the why comes from. But by then everyone is looking at the same numbers, and the useful part of the discussion is the gap between what the history shows and what the team believes — which is frequently the single most valuable finding.

Ranked by cost, split by horizon

The output is a ranked account of where the time goes, with a number against each item and a rebuild sequence.

Two rankings, not one. Findings that move in weeks are tooling: build time, cache configuration, review routing, environment provisioning, the CI steps that run on every commit and only matter on some. Findings that move over quarters are structural: service boundaries that force three teams into every change, an architecture that makes the test suite slow by construction, ownership that concentrates review in two people.

Presenting these as one list is how this work loses credibility in month two. The tooling fixes land, the numbers move, and then everything stalls because the remaining items were never a quarter’s work. Naming the horizon up front is what makes the second half survivable.

Where it goes next

If the cause is unclear and you want an independent read before committing to anything, the Engineering Audit is the five-day version of the diagnosis half of this work.

If the diagnosis is already done and one specific problem needs a fixed scope and a date, that is CTO Consulting — a four-to-eight-week engagement against exactly one of velocity, compliance or hiring.

And where the finding is that reliability rather than process is taking the time — deploys that fail, an on-call rotation that consumes the senior engineers, no instrumentation to reason from — that work sits under Platform Engineering, which shares four of the capabilities on this page.

What this covers

Each of these is a capability with its own page, its own order of work and its own outputs.

Capability What it means
Delivery Metrics Delivery measured from the systems that already record it. Cycle time, deployment frequency, change failure rate and recovery time, reconstructed from your history rather than estimated.
Technical Debt Assessment Debt named, priced and ranked. Which parts are costing you delivery speed right now, which are dormant, and what it takes to bring the expensive ones back inside tolerance.
Architecture Review An independent read on how the system is put together, where it will bend under the growth you are planning for, and what preventing that bend costs.
Process Rebuild Rituals, review flow and deployment cadence rebuilt around how the team actually works. The output is a shorter path from decision to production, not a longer set of meetings.
CI/CD Pipeline A pipeline fast enough that people wait for it. Build time is a delivery constraint, and a twenty-minute pipeline changes how a team batches work whether anyone intends it to or not.
Observability Stack Enough signal to answer a question you did not anticipate. Metrics, logs and traces joined by a common identifier, with the cost of collection under deliberate control.
Developer Experience The friction between an engineer having an idea and the change being live. Local setup, build times, environment access — measured, then removed in the order that costs the most.
Team Topology & Org Design Team boundaries drawn around the system rather than around history. Who owns what, what each team can ship without waiting, and where the handoffs that cost you weeks are.
Board Delivery Reporting A monthly engineering report a board can act on. What shipped, what it cost, what is at risk, and what decision is being asked for — in the language the rest of the pack is written in.
Delivery Management Someone accountable for the date. Scope held, dependencies tracked, risks raised while there is still time to act on them — without adding a layer between the team and the work.
PMO Setup The smallest amount of governance that makes multi-team delivery legible — intake, prioritisation, a shared definition of done, and one view of what is actually in flight.

Next step

Describe the situation and we'll tell you whether this is the right shape.

Request a call

How we decide

  • Measured from the repository before anyone is interviewed

    Costs It needs read access to Git and CI, and the numbers sometimes contradict a story the team believes about itself.

    Retros produce theories, and theories tend to name whoever is not in the room. Cycle time, review latency, deploy frequency and change failure rate are already in the history. Starting from them means the conversation begins with what happened rather than with who is at fault, which also makes the interviews more useful when they come.

  • No individual's numbers go upward

    Costs It removes the analysis a founder most often asks for.

    Per-engineer metrics are unreliable — they measure ticket shape more than contribution — and the moment a team believes they are being collected, the metrics stop describing reality. Every number we report is about the system. A team that trusts the measurement is worth more than one uncomfortable answer about a person.

  • Findings are separated by how long they take to move

    Costs It means saying that some of the ranked list will not improve this quarter.

    Build time and review latency are tooling problems with tooling fixes and they move in weeks. Anything rooted in architecture or team boundaries moves over quarters. Presenting one list with one timeline sets an expectation that fails in month two and discredits the parts that worked.

  • Architecture and process are examined before either is blamed

    Costs It is slower than starting the process rebuild everyone expects.

    A monolith with a fifteen-minute build and a slow test suite produces exactly the symptoms people attribute to process discipline, and rituals installed on top of it will not move anything. The reverse is also true. Concluding either without looking at both is the most expensive mistake available here.

Four ways to measure delivery

The instrument decides what you can see. These get used interchangeably and they answer different questions.

Instrument What it measures Can it be gamed? What it misses
Delivery metrics from version control Commit-to-production time, deploy frequency, change failure rate, recovery time Not easily — it is history, and re-pointing tickets does nothing to it Whether the work being shipped was worth shipping
Story points and velocity charts Estimate throughput against estimates the same team produced Trivially, and usually without anyone intending to Everything outside the tracker, including all unplanned work
Developer surveys Friction as experienced, and where people believe the time goes Not gamed so much as shaped by who answers and when Magnitude — it ranks annoyance, not cost
The retro Whatever was most memorable in the last two weeks It is a conversation; whoever speaks first sets the frame Anything slow and constant, which is most of the real cost

Rows three and four are worth running and are not measurement. The gap between what the survey says and what the history shows is often the most useful single finding in this work.

Is this you?

  • Roadmap commitments are slipping and nobody can name the cause
  • A board is asking why headcount grew and output did not
  • Deploys have quietly become an event rather than a routine

How we run it

Measured from the repository first

Retros produce theories, and the theories tend to name whoever is not in the room. Cycle time, review latency, deployment frequency and change failure rate are already in your Git and CI history. We reconstruct them before anyone is interviewed, so the conversation starts from what happened.

Frequently Asked Questions

The rate at which a team converts decisions into working software in production, measured end to end rather than by activity. In practice it is four numbers: how long a change takes from first commit to running in production, how often you deploy, how often a deploy needs remediation, and how long recovery takes. It is deliberately not a measure of effort or of output volume.
From version control and CI history, which already contain everything needed. None of the four metrics requires estimation, none can be improved by re-pointing tickets, and all four can be reconstructed for the past year before anyone changes anything — which is what makes a before-and-after comparison possible.
The metrics are the instrument, not the work. They tell you where the time goes; they do not tell you why, and they never tell you what to change. The diagnosis is what sits between the measurement and the rebuild, and it is the part that requires having seen the failure modes before.
Then that is the finding, and it changes the timeline rather than the engagement. A monolith with a slow test suite and a long build produces exactly the symptoms usually attributed to process discipline. We look at both before concluding either, because installing rituals on top of an architectural constraint moves nothing and costs a quarter.
Build time and review latency usually move first — they are tooling problems with tooling fixes, and weeks is realistic. Anything rooted in architecture or team boundaries moves over quarters. We say which category each finding is in rather than offering one timeline for both, because the second kind is where credibility gets lost.
That depends entirely on how it is introduced, and we would rather get that right than be quick about it. The measurement is of the system. Findings are shared with the engineers before anyone above them, and no individual's numbers are reported upward at any point.
A small number of delivery metrics with history, in a form that does not need engineering context to read, plus what changed and what it cost. The value is that the same numbers were there before the intervention, so the comparison is not a claim.
Both are available and the honest default is hands-on. Advice about delivery process is cheap and abundant; what is scarce is somebody running the change while the team keeps shipping. Where your own leadership wants to own the rebuild, we measure, diagnose and hand over.

Sources

Page reviewed