# What is Engineering Delivery?

Engineering Delivery is Solidafy's app for seeing how your teams deliver software. It reads the tools your teams already use, such as GitHub, Jira or Linear, and shows the DORA metrics alongside code review, flow of work, quality, incidents, team health, developer experience and AI. Next to every number it explains what the number means and what to try next.

## What does the app do?

The app answers one question for an engineering organisation: how quickly and how safely does our work reach customers, and what is holding it back?

It does that in three steps:

1. **It reads your tools.** You connect your code host (GitHub, GitLab or Bitbucket), your tracker (Jira or Linear), and optionally where your incidents are recorded (PagerDuty, Jira or Linear) and AI billing (Anthropic or OpenAI). The app pulls their data every three hours.
2. **It works out the measures.** From that data it counts deploys, times changes from first commit to production, notices which releases needed a fix, follows tickets through their statuses, and much more.
3. **It explains them.** Every tile says what it measures and how, what good looks like according to published sources, and where to start if the number is not where you want it.

If you have never heard of DORA, the research behind the most important measures, read [What is DORA?](/docs/engineering-delivery/what-is-dora) and [The five DORA metrics](/docs/engineering-delivery/dora-metrics) first. They assume no prior knowledge.

## Who is it for?

The app is for the people who look after how a team works, not for judging the people in it.

- **Engineering managers and team leads** use it to spot where work waits, and to pick one thing to improve.
- **Teams** use it in standups and retrospectives, to see what shipped, what broke and what is stuck.
- **CTOs and heads of engineering** use it to see delivery across teams, and whether AI spend pays back.

Every measure is about a team or a service, and no screen ranks people. Names only appear where an admin turns them on: **Names on items** in Settings shows who each item is by on the lists a figure opens, and the Claude Code place has a [By person](/docs/engineering-delivery/claude-code#by-person) view for environment admins.

## How is the app organised?

The rail on the left of the app holds seven places. Each place is a row of tabs, read left to right.

| Place | Tabs | What it answers |
| --- | --- | --- |
| Brief | Overview | How is delivery going, and what should we focus on? |
| Delivery | Speed, Review, Flow, Quality, Incidents | How fast and how safely does work reach customers, and where does it wait? |
| Work | Open work, Initiatives, Meetings | What is stuck right now, when will the epics land, and what do we talk about at standup and retro? |
| People | Team health, Developer experience | How is the load on each team, and how do people experience their work? |
| AI | AI assistance | How much do teams use AI, what does it cost, and does it pay back? |
| Claude Code | Usage, Outcomes, Standards, Security | How do teams use Claude Code, what does it deliver, do they keep the standards you set, and is anything worth a security look? |
| Admin | Setup, Settings, Access | Connecting tools and deciding how the app counts. Only environment admins see this place. |

## What will I see on each page?

Each page of the app has its own guide here, written to answer the questions the page raises.

- **[Overview, focus and working agreements](/docs/engineering-delivery/overview-and-focus):** the headline tiles, the status of each part of delivery, the one constraint your teams are working on, and the habits each team agreed to keep.
- **[Speed](/docs/engineering-delivery/speed):** deploys a week, change lead time, recovery time, and where the time goes in a typical change.
- **[Review](/docs/engineering-delivery/review):** time to first review, time to merge, change size, review coverage and changes merged without review.
- **[Flow](/docs/engineering-delivery/flow):** work in progress, done per week, where the work went, time in each stage, stuck work, ticket to customer and changes with no ticket.
- **[Quality](/docs/engineering-delivery/quality):** change fail rate by service, changes per deploy, deployment rework rate, bugs opened and reopened tickets.
- **[Incidents](/docs/engineering-delivery/incidents):** how fast you recover when a release breaks, and where incidents happen.
- **[Team health](/docs/engineering-delivery/team-health):** teams side by side, work in flight and merged changes per engineer by team, after-hours work and focus time.
- **[Developer experience](/docs/engineering-delivery/developer-experience):** a short anonymous survey on feedback loops, cognitive load and flow state.
- **[AI](/docs/engineering-delivery/ai):** AI-assisted changes, weekly AI users, AI spend, cost per merged change and whether AI is paying back.
- **[Claude Code](/docs/engineering-delivery/claude-code):** Claude Code usage and cost, outcomes, required skills and allow lists, and security flags. [Connecting Claude Code](/docs/engineering-delivery/claude-code-setup) explains how to send its data.
- **[Meetings, open work and initiatives](/docs/engineering-delivery/meetings):** standup and retro views, the work that is not moving, and when epics will likely be done.
- **[Goals, alerts and Scout](/docs/engineering-delivery/goals-alerts-and-scout):** targets and budgets, alerts, what to improve next, the weekly note and Ask Scout.

## How does the app read the numbers?

The app follows a few rules everywhere, so you can trust what a number means.

- **Your own past, never an outside grade.** Every figure is compared with an earlier period for the same team. The rail on each tile shows the period you compare with next to now. No tile labels a team elite, high, medium or low.
- **Quality per service, everything else per team.** Change fail rate is shown per service, so one risky service does not hide inside a team average. The rest is read per team.
- **No one is ranked.** The app reads teams and services. Measures, charts, Scout, alerts and the standup and retro screens stay at team level. A drill into the details lists changes, tickets and releases, and names no one unless an admin turns on **Names on items**, which shows a change's author and reviewers and a ticket's assignee on the lists a figure opens. The Claude Code place's By person view, for environment admins, is the other place people are named.
- **Small teams are not shown on their own.** A team with fewer engineers than **Smallest team shown on its own** in Settings (3 unless you change it) counts only in All teams, with the people in no team. This decides which teams the team filter offers and which teams every team table lists, so no one can be singled out. While Names on items or Claude Code by person is on, people are shown anyway, so every team shows its own numbers.
- **Bots are left out.** Pull requests that Dependabot, Renovate or another bot opened, and Jira issues an app reported, are left out of every measure unless you choose to count bots in Settings. Deploys count whoever merged them.
- **Nothing is estimated.** If a measure needs data you have not connected, the tile says what is missing instead of showing a guess. [Setting it up](/docs/engineering-delivery/setup) explains each of these messages.
- **Medians, not averages.** Times such as lead time and time to merge use the [median](/docs/engineering-delivery/glossary#median), the middle value, so one change that sat for a month does not hide what usually happens.

At the top of the app you choose what the numbers cover:

- **Period:** the last 7, 30, 90, 180 or 365 days, this month, last month, this quarter, year to date, or a custom range.
- **Compared with:** the previous period, the same days last month, the same days last year, or a custom range.
- **Team**, **Repository**, **Work type** and **Service:** each with an All option. Choosing a team resets the filters after it, because their choices depend on the team.

When a filter cannot split part of a page, a chip such as "Partly by team" says so, and that part is read whole.

## What do the guides inside the app say?

Under the tiles of each page there is a row called "How these are measured". Open a measure there and its guide shows:

- **Why it matters:** a sentence or two on why the measure is worth watching.
- **How it is measured:** exactly what the app counts, from which data, and what it leaves out.
- **What good looks like:** a published figure where one exists, such as the DORA report or Google's engineering practices, or a plain note that none exists and the app compares with your own past.
- **Where to start:** a few things to try, in order.
- **Learn more:** a link to the matching guide in these docs, which explains the measure from scratch.

## What is Scout?

Scout is Solidafy's AI assistant. In Engineering Delivery, the app's own rules do most of the explaining, and Scout is there for the questions they cannot answer.

- **What to improve next.** At the top of most pages, when a goal is missed or a measure got worse than the team's own last 90 days, a short recommendation says where to look, why and what to try, with the figures behind it and the published research it rests on. The app writes it from fixed rules, with no AI model. It stays at team level.
- **The weekly note and the retro nudge.** A short note each week on what is worth a look and how goals are doing, and a reminder before the retro about changes that have waited long for a first review. The app writes them from its rules unless an admin chooses Scout to write them in its own words.
- **Ask Scout.** A chat where you can ask questions such as "How is delivery going?". It is off until an environment admin turns it on in Settings. Scout answers only from the app's numbers, for the teams you can see, and names no one.

[Goals, alerts and Scout](/docs/engineering-delivery/goals-alerts-and-scout) covers each in detail.

## Where do I start?

1. **Connect your tools.** An environment admin opens Setup and connects at least a code host. A tracker adds the flow measures, an incident tool makes recovery time and rework rate precise, and AI billing adds spend. See [Setting it up](/docs/engineering-delivery/setup).
2. **Check how the app counts.** In Settings, confirm what counts as a deploy, map your tracker's statuses to stages, and set up your teams.
3. **Open the Overview.** Read the status of each part of delivery, then follow what to improve next.
4. **Pick one thing.** Choose a focus for your teams and, if it helps, a working agreement. The [Overview, focus and working agreements](/docs/engineering-delivery/overview-and-focus) guide explains how.

> **Tip:** You do not need every tool connected on day one. Start with your code host: deploys, lead time, review and change size all come from it.

## Learn more

- [Setting it up](/docs/engineering-delivery/setup)
- [What is DORA?](/docs/engineering-delivery/what-is-dora)
- [The five DORA metrics](/docs/engineering-delivery/dora-metrics)
- [Overview, focus and working agreements](/docs/engineering-delivery/overview-and-focus)
- [Glossary](/docs/engineering-delivery/glossary)
