# Team health New to DORA? Start with [What is DORA?](/docs/engineering-delivery/what-is-dora), then come back here. Team health is the page in Engineering Delivery that shows how evenly work is spread across your teams and whether any team is working in a way it cannot keep up. You find it under **People**, then **Team health**. It shows how much work each team carries per engineer, how much each team merges per engineer, how review work is shared, how much of each team's work happens after hours, and focus time. Every number is per team, never per person. This guide explains what each part of the page means, what DORA's research says about well-being and burnout, and what to do when a number looks wrong. ## What the Team health page shows The page opens with a short summary, then the team health measures, then the team charts. At the top it reminds you how to read everything below: > "Every number here is per team, for wellbeing only, and never used to rank anyone." The summary names the team where the load is most concentrated, for example: "Work in flight is most concentrated in Payments: 4.5 per engineer, against 3.1 across the 4 teams shown." When the app cannot read work in flight, it uses merged changes instead ("Merged changes are most concentrated in ..."). If no team is read yet, it says so and shows no status: "No team is read yet." It names the teams that are set up but too small to show on their own, and an environment admin gets the one fix: set the smallest team in Settings, or map teams there. On the page you find: - **The team health measures:** after-hours work and focus time. Each has a short guide next to it. See [After-hours work](#after-hours-work) and [Focus time](#focus-time) below. - **Teams side by side:** every headline number for each team on one line. See [Teams side by side](#teams-side-by-side). - **Work in flight per engineer, by team:** how much unfinished work each team carries for the people it has. - **Merged per engineer, by team:** how many changes each team merged for the people it has. It shows only when Teams side by side does not; otherwise Teams side by side carries each team's merged changes instead. - **Reviews given and received, by team:** how review work is shared between teams. See [Reviews given and received](#reviews-given-and-received). - **After hours work, by team:** the share of each team's commits written outside working hours. You can open any team on a chart to see the items behind its number: its tickets in flight, its slowest changes or its days of after-hours work. > **Note:** A team is a group you map in Settings. A team smaller than the smallest team shown on its own (3 engineers by default, set in Settings) is not shown on its own, so that no number can point at one person. Such a team is listed in the team filter as pooled, and named once under the views that list teams. ## What does DORA mean by well-being? Well-being is how happy and satisfied people are with their work. DORA's [well-being capability](https://dora.dev/capabilities/well-being/) puts it like this: "Well-being is a reflection of individuals' happiness and job satisfaction." DORA counts it as a [capability](/docs/engineering-delivery/glossary#capability-dora), one of the practices and conditions its research links to better results, and finds that it predicts both how well an organisation performs and whether people stay. The opposite end is burnout. DORA's capability page defines it as "physical, mental, or emotional exhaustion caused by overwork or stress". The 2024 DORA report (executive summary) gives a fuller description: "a state of emotional, physical, and mental exhaustion caused by prolonged or excessive stress, often characterized by feelings of cynicism, detachment, and a lack of accomplishment." > **Note:** Well-being is not a nice extra on top of delivery. In DORA's model, it is one of the outcomes good delivery practices lead to, next to how well the organisation performs. A team that ships fast while burning out is not doing well. ## What causes burnout? Burnout mostly comes from how work is organised, not from the people doing it. DORA's well-being page draws on the research of psychologist Christina Maslach, who found six risk factors in the workplace that predict burnout: 1. **Work overload:** job demands that exceed human limits. 2. **Lack of control:** not being able to influence decisions that affect your job. 3. **Insufficient rewards:** too little financial, institutional or social reward. 4. **Breakdown of community:** an unsupportive workplace. 5. **Absence of fairness:** decisions made in ways that feel unfair. 6. **Value conflicts:** a mismatch between the organisation's values and your own. The most useful finding is about where to act. As DORA's page summarises Maslach: "most organizations try to fix the person and ignore the work environment, even though data shows that fixing the environment has a higher likelihood of success." Wellness perks do not fix a team that is always on call for a fragile system. ## What does DORA's research say helps? Stable priorities, good leadership, a focus on users and calm releases all help. The research points at specific conditions: - **Stable priorities.** The 2024 DORA report found that unstable organisational priorities lead to meaningful drops in productivity and substantial increases in burnout, "even when organizations have strong leaders, good internal documents, and a user-centric approach to software development." Changing direction every few weeks wears people out, whatever else is going well. - **Transformational leadership.** The same report found that leaders who inspire, support and develop their teams improve productivity, job satisfaction and team performance, while helping decrease burnout. - **A focus on users.** Organisations that put the end user's experience first build better products, and their developers are more productive, more satisfied and less likely to burn out (2024 report, executive summary). - **Painless deployments.** DORA's well-being page notes that continuous delivery practices (keeping software always ready to release, with automated tests and deployments) reduce the pain of deploying and the amount of rework, which lowers the stress that comes with releasing to production. This is one reason the [five DORA metrics](/docs/engineering-delivery/dora-metrics) and well-being tend to move together. The 2024 report also measured flow, which it defines as "how much focus a person tends to achieve during development tasks". Flow is the positive side of the same coin: time to concentrate on meaningful work. What about AI tools? The 2025 DORA report (pages 38 to 39) found that higher AI adoption showed no relationship with burnout or with friction. DORA's reading is that these are properties of the wider system people work in, so a new tool at the keyboard does not change them on its own. See [AI and software delivery](/docs/engineering-delivery/ai) for the rest of that story. ## Teams side by side **Teams side by side** is the first card on the page when you can see more than one team. It puts the same headline numbers for each team on one line: merged changes, median lead time, median wait for a first review, review coverage, [merge rate](/docs/engineering-delivery/review#merge-rate), deploys and change fail rate, for the period you chose. An **All teams** row shows everyone together, and matches the headline tiles. ### How to read it It shows where a team could use help, a reviewer, or a smaller change size. Read each team against its own past and its own goals. Teams do different work, so this is not a ranking. A number is green or red only against a goal set in Settings. ### How to use it Open the number that stands out: every number opens the items behind it. Then ask the team what would help, before comparing anyone. ### How Solidafy measures it Each figure is read exactly as the headline tile reads it, so the all teams row is the headlines. A team smaller than the smallest team shown on its own (3 engineers by default, set in Settings) is not shown on its own; all teams still counts their work. Changes opened by bots, such as Dependabot, are left out. ## Work in flight per engineer, by team This chart shows how much unfinished work each team carries for the number of people in it. In the app's words: "Tickets in progress, review or testing right now, over each team's mapped headcount. Check the load against the people carrying it." ### What it means Work in flight is every ticket that is started but not finished: in progress, in review or in testing. Dividing it by the team's headcount (the number of engineers you mapped to the team in Settings) tells you how many open items each person is juggling on average. The bar label reads, for example, "4.5, 18 for 4": 18 tickets in flight for 4 engineers. It is a snapshot of right now, not an average over the period you picked. ### What to do when one team is high A team with many more items in flight per engineer than the others is usually spread thin. Each item waits while people switch between them, so everything takes longer, and the team is more likely to burn out. DORA's [work in process limits](https://dora.dev/capabilities/wip-limits/) guidance makes the same point. - Open the team on the chart to see its tickets in flight, oldest first. - Ask the team what is blocked and what can be finished or handed over before anything new starts. - Look at where the work comes from. A team that keeps receiving urgent requests from outside its plan needs that fixed at the source, not more effort. - Agree a limit on how much the team works on at once. See [work in progress](/docs/engineering-delivery/flow#work-in-progress). ### What good looks like No published source gives a figure. A spread close to the average across teams, and a team that stays near its own past, is a good sign. ## Merged per engineer, by team This chart shows how many changes each team merged in the period you picked, for the number of people in it. The app describes it as "A spread, not a score." It appears only when [Teams side by side](#teams-side-by-side) does not, since that card already shows each team's merged changes. ### What it means It shows how output is spread across teams, not how productive anyone is. Teams work on very different things: a team that ships many small changes and a team that ships fewer, harder ones can both be doing well. That is why the app never ranks teams by it. ### How to use it Use it to spot a team that is far from the others or far from its own past, then ask why. A sudden drop may mean the team was pulled onto incidents, is stuck on something large, or lost people. A team far above the rest may be carrying load other teams should share. Open a team to see its slowest changes. > **Warning:** Never use merged per engineer to compare or rank people or teams. Splitting work into more changes raises the number without delivering anything more, and pressure on it pushes people to do exactly that. ## Reviews given and received **Reviews given and received, by team** is a table of how review work is shared. The app describes it as "A picture of how review work is shared, not a score." - **Reviews given:** the reviews a team's people wrote in the period, on any team's changes, counted for the reviewer's own team. - **Reviews received:** the reviews written on the team's own changes, by anyone. - **Given per engineer:** reviews given over the team's mapped headcount. ### How to use it Look for a team that receives far more reviews than it gives, or one whose people review for everyone else while their own work waits. Either can explain a long [time to first review](/docs/engineering-delivery/review#time-to-first-review). Talk about how review work is shared, and never use the table to compare people. ## After-hours work After-hours work is the share of a team's work done outside its normal working hours. It is a simple, visible hint that a team may be under more pressure than it can sustain. ### Why it matters One late evening before a launch is normal. A standing pattern of evenings and weekends usually means one of Maslach's risk factors is at play: too much work, priorities that keep shifting, or a system that breaks outside office hours. It is worth noticing early, while it is still a conversation and not a resignation letter. ### How to read it Take our running example: a team of six building an online booking app. Over the last month, 8% of their commits were written in the evening or at the weekend. Over the month before it was 4%. On its own that says little. Put next to the calendar it might explain itself: a big partner launch landed in the middle of the month. If the share stays high the month after the launch, that is the moment to ask the team what is going on. Look for patterns over time, not single weeks. Compare a team with its own past, not with other teams: teams spread across time zones, or with an agreed late shift, will look different for good reasons. ### What does good look like? No published source gives a figure for after-hours work. It is a well-being signal to talk about, not a target to hit. A lower number is not automatically better either: a team can stop committing late and still be working late in meetings or on call. ### How to improve it Treat a rise as a question about the work, not the people: - Ask the team what is pulling them into evenings: deadlines, incidents, meetings that eat the working day? - Check whether priorities have changed recently. Stable priorities are one of the clearest protections DORA has found. - Look at release pain. If fixes and rollbacks happen out of hours, the [change fail rate](/docs/engineering-delivery/change-fail-rate) and [failed deployment recovery time](/docs/engineering-delivery/failed-deployment-recovery-time) pages explain how to make releases calmer. - Look at load. Too much [work in progress](/docs/engineering-delivery/flow#work-in-progress) spread over too few people is a common cause. ### Common mistakes - **Reading it per person.** Someone who prefers to work late is not a problem to fix, and singling people out destroys trust. Read it per team. - **Turning it into a target.** If a number is used to judge people, they stop committing in the evening and keep working anyway. The signal disappears and the problem stays. - **Ignoring time zones.** A commit at 21:00 in Stockholm is mid-afternoon in New York. ### How Solidafy measures it Solidafy shows after-hours work in the Team health part of the Engineering Delivery app. It is the share of a team's commits written outside its working hours on a weekday (09:00 to 18:00), or at any time at the weekend, in the period you choose. - Each commit is read at its author's own local time, from the time zone the commit records, so a distributed team is read correctly. - It is read from GitHub and GitLab. A commit made in the web editor is left out, because its time is the host's, not the author's. - Commits by bots, such as Dependabot, are left out unless bots count in Settings. - It is shown per team only, for teams shown on their own (3 engineers or more by default, set in Settings), and never per person. A smaller team is not shown on its own, so no one can be singled out. The chart "After hours work, by team" shows each team's share next to how many commits it rests on, for example "8% of 240 commits". The app describes it as "a signal to talk about, not a score". Open a team to see the days its after-hours work fell on. ## Focus time Focus time is the working time people have in unbroken blocks, free of meetings, to concentrate on hard problems. Deep work such as designing a feature or tracking down a tricky bug needs long stretches without interruptions. ### Why it matters A day cut into half-hour gaps between meetings leaves little room for real progress. A team whose days are cut into small pieces finishes less, however hard it works, and the frustration of never getting into the work adds to stress. This is the practical side of the "flow" the 2024 DORA report measured. ### How to read it The usual measure is hours of working time free of meetings, counted only in blocks of two hours or more. If our booking team has, on average, six such hours a week each, and that drops to three after a reorganisation added new planning meetings, the change is worth discussing at the next retrospective. ### What does good look like? No published source gives a figure. Compare a team with its own past. ### How to improve it - Agree meeting-free blocks as a team, for example no meetings before lunch. - Batch meetings onto fewer days. - Question recurring meetings: does each one still need everyone? - Make it fine to answer messages later during focus blocks. The [Developer experience (DevEx)](/docs/engineering-delivery/developer-experience) survey asks people directly whether they get enough uninterrupted time, which is a good complement to any calendar measure. ### How Solidafy measures it In Solidafy, focus time means working hours free of meetings, in blocks of two hours or more, read per team and never per person. Only a calendar shows a meeting, and commits cannot show an interruption, so this needs a calendar the app does not read yet. Until then it is shown as not measured, and it is never estimated. ## Questions the app raises ### One team carries far more work in flight per engineer. What should we do? Treat it as a question about how work reaches that team, not about the people in it. Open the team on the chart and look at its oldest tickets in flight first. Ask what each one needs to move, finish or hand over before anything new starts, and check whether the team keeps receiving unplanned work from outside. If the load stays high, agree a limit on work in progress with the team. The [Flow guide](/docs/engineering-delivery/flow#work-in-progress) explains how. ### After-hours work went up. Is that a problem? Not on its own. A busy launch week or an incident explains a short rise. A share that stays high for several periods is worth a conversation with the team: are priorities shifting, are releases painful, is the team on call for something fragile? Fix the cause in how work is organised. Never use the number to judge a person. ### Why is our team not shown? Either the team has fewer engineers mapped to it than the smallest team shown on its own (3 by default, set in Settings), or it is not mapped at all. A team that small is not shown on its own, so no number can point at one person; the team filter lists it as pooled, and the page names it under the views that list teams. An environment admin can lower the size in Settings, down to 1, if your teams are small and that is your call. To see a team, map its people to it in Settings. See [Setting it up](/docs/engineering-delivery/setup). ### Why is focus time not measured? Focus time needs to know when people are in meetings, and only a calendar shows that. Commits cannot show an interruption, and the app does not read calendars yet, so focus time is not measured and never estimated. The [developer experience survey](/docs/engineering-delivery/developer-experience) asks people directly whether they get enough uninterrupted time, which covers the same question in the meantime. ### The chart says it shows only some teams. Why? When more teams worked in the period than one view reads at once, the page says so ("Showing N teams") and shows the ones it read. To read a team that is not shown, pick it in the team choice at the top of the app. ## Learn more Official sources used on this page: - [DORA capability: well-being](https://dora.dev/capabilities/well-being/) - [2024 Accelerate State of DevOps Report](https://dora.dev/research/2024/dora-report/) (executive summary) - [2025 State of AI-assisted Software Development](https://dora.dev/research/2025/dora-report/) (pages 38 to 39) Related Solidafy guides: - [What is DORA?](/docs/engineering-delivery/what-is-dora) - [Developer experience (DevEx)](/docs/engineering-delivery/developer-experience) - [Flow of work](/docs/engineering-delivery/flow) - [Improving software delivery](/docs/engineering-delivery/overview-and-focus) - [AI and software delivery](/docs/engineering-delivery/ai) - [Glossary](/docs/engineering-delivery/glossary)