Pacia Intelligence

For Heads of Development

Compare teams fairly, on definitions they agreed to.

Running several teams means every status report arrives in a different dialect. Pacia puts them all on one set of definitions — the same stages, the same bands, the same words for planned, unplanned, delivered and carried out — so a comparison across teams is a real comparison rather than an argument about measurement.

Talk to us
Cycle time by stage — six teams
Coding
median 11.4h
Pickup (PR open → first review)
median 9.8h
Review
median 6.1h
Merge wait
median 2.3h
Agreement compliance
4 of 6 teams meeting pickup target

Pickup is the stage most orgs are slowest at and least aware of.

The bottleneck is almost never where the retro says it is

Teams are reliably good at identifying that delivery feels slow and reliably poor at identifying which part is slow. The instinct is to point at code review or at estimation. The data usually points at pickup — the dead time between a pull request opening and anyone looking at it — and at reviewer concentration, where two people are quietly the queue for everybody.

Pacia splits lead time into coding, pickup, review and merge-wait so the argument becomes evidential. It shows reviewer concentration explicitly, which is the metric that predicts a burnout conversation about six weeks ahead of the conversation happening. And it does all of it per team, on identical definitions, so you can see whether one team has genuinely solved something the others could copy.

The total is not the bottleneck

Breaking lead time into stages turns “delivery is slow” into a specific queue, with the underlying work available when the team asks why.

Where a 29.6-hour lead time actually goes

  • Coding11.4h

    First commit → PR opened · 39% of total

  • Pickup9.8h

    PR opened → first review starts · 33% of total

  • Review6.1h

    First review → approved · 21% of total

  • Merge wait2.3h

    Approved → merged and deployed · 7% of total

Pickup is dead time — nothing is happening, nobody is blocked on a decision, the change is simply waiting. It is the largest stage in most organisations the first time it is measured, and the cheapest one to fix.

What changes week to week

  • The stage that is actually costing you

    Cycle time broken into coding, pickup, review and merge-wait, per team and trended. Most orgs discover pickup is their largest single stage, and it is also the cheapest one to fix.

  • Reviewer concentration before it becomes attrition

    How much of each team’s review load sits with how few people. When two people carry seventy per cent of reviews, that is both a delivery risk and a retention risk, and it is invisible in a throughput chart.

  • Agreement compliance rather than imposed targets

    Each team sets its own thresholds — reviews start within four hours, PRs stay under a size limit, checks pass before merge — and Pacia reports the hit rate with the misses listed and linked. Drill into any failure to the specific pull requests.

  • Stuck work, surfaced rather than searched for

    Filtered views for pull requests waiting on review, stale for 24 hours, or aged past 30 days, across every team you are responsible for. The list you would otherwise assemble by hand every Monday.

  • One vocabulary across sprints, epics and QA

    Planned, unplanned, delivered, carried out and hit rate mean exactly the same thing on every screen, so cross-team reporting stops needing a translation layer.

Where this lives in Pacia

Common questions

Can I compare teams without it becoming a league table?

That depends on how you use it rather than on what is available — both team and contributor comparison are supported. The comparison worth making is diagnostic: one team’s pickup time being half another’s is a question about process, and the drill-down shows you what they actually do differently. The same drill-down is what keeps a contributor board a conversation rather than a verdict.

Do all teams have to use the same working agreement targets?

No, and they should not. Agreements are configured per team by an admin or owner, because a platform team and a customer-facing product team have genuinely different reasonable thresholds. Compliance is always reported against that team’s own target.

What do team members themselves see?

Members are restricted to their own teams’ data. Owners and admins see the whole organisation. That restriction is enforced on every query rather than only hidden in the interface.

See it against your own delivery data

Connect one repository and judge it on your own history rather than a demo dataset. Guided onboarding is included on every paid plan.

Talk to us