Snapshots Overview

Snapshots

Snapshots measure developer experience by surveying your engineers directly, then scoring the results, comparing them against industry benchmarks, and breaking them down by team. Where the rest of Waydev measures what your systems record, Snapshots measure what your engineers experience. Running them on a regular cadence gives you a trend line for the parts of engineering work that never appear in a Git history: waiting, context switching, unclear direction, and tooling friction.

Each survey round produces one snapshot, identified by its date. Every score, comparison, and chart in the product is anchored to a specific snapshot, and switching snapshots in the date selector moves the entire view to that point in time.

How a snapshot works

A snapshot moves through four stages:

Collection - A short survey is sent to the engineers in scope. It mixes perception questions, time-based questions, time allocation questions, and free-text comments.
Scoring - Responses are converted into scores and averages. Perception questions become a score from 0 to 100, time-based questions become an average value in their native unit, and driver scores are averaged into a single index.
Benchmarking - Every score is compared against an industry percentile so you can tell the difference between a number that looks low and a number that is actually behind your peers.
Breakdown and action - Results are split by team, ranked by how many people voted for each area, and paired with the comments that explain them.

What a snapshot measures

Drivers

Drivers are perception questions about the conditions engineers work in, such as code maintainability, review turnaround, deep work, and documentation. Each driver maps to a single survey statement, and respondents answer on a five-point frequency scale from Always to Never.

Driver scores use the Percent favorable scoring method, which means the score is the percentage of respondents who chose one of the two most positive options. A driver scoring 60 means 60 percent of respondents answered Always or Very often. This is why driver scores move in visible steps on small teams and why a team of four can score 25 on the same item where the organization scores 60.

Because drivers are scored as percentages rather than averages, a score of 0 means every response was unfavorable. It does not mean the question went unanswered.

Workflows

Workflows are quantitative questions about how much time an activity consumes, or how often it happens. Respondents pick a bucket rather than typing a number, for example 2-4 hours per week or 6-8 hours per week, and the reported values are averaged into a single figure with its native unit.

Each workflow carries a Recommended target, such as Less than one hour per week for review wait time. The % in target range figure is the share of respondents whose answer falls inside that target. In the AI time savings example, the target is more than two hours per week, and the 65 percent in-range figure is the sum of everyone answering 2-4, 4-6, 6-8, and 8+.

Two things are worth calling out when reading workflow deltas. First, the comparison is expressed as a percentage difference rather than a point difference, because workflows are measured in hours and counts rather than on a fixed scale. Second, for most workflows lower is better, so a positive percentage against the benchmark indicates worse performance, not better. Workflows where more is better, such as AI time savings and PR merge frequency, invert that reading.

Allocation

Allocation questions ask respondents to divide their time across categories as percentages, for example new capabilities, KTLO and maintenance, and other. Answers are shown as stacked bars next to the same split for the benchmark, which makes it easy to see whether your engineers are spending a materially different share of their time on maintenance than comparable organizations.

Allocation questions can nest, so a follow-up question can break down a single category from a previous answer into finer detail.

Votes

Alongside rating each driver, respondents select the areas they most want improved. Votes are independent of scores, and the gap between the two is often the most useful signal in a snapshot. A driver can score reasonably well and still attract the most votes, which usually means it is not broken but it is the thing standing between your engineers and getting work done.

Vote rank is tracked across snapshots, so you can see priorities reorder over time as fixes land and new friction appears.

Comments

Comments are free-text responses tagged to the driver they relate to. They carry the author, their team, and the driver tag, and they support likes and threaded replies so managers can acknowledge feedback and follow up in place rather than exporting it elsewhere.

Comments are the layer that makes a score actionable. A code maintainability score of 60 tells you there is a problem; the comments tell you it is stale architecture documentation and multi-thousand-line pull requests.

Developer Experience Index (DXI)

The DXI is the overall average of the individual driver scores in a snapshot, expressed as a single number out of 100. It exists so that developer experience has one figure that can be tracked quarter over quarter, compared against the industry, and reported upward without requiring the audience to read sixteen separate driver scores.

The DXI is a summary, not a diagnosis. It tells you whether things are improving. The driver scores, votes, and comments tell you what to do about it.

Benchmarks

Every score in a snapshot is shown next to its difference from an industry benchmark, selected using the Compare to control. Industry P50 compares you against the median organization and answers the question of whether you are behind or ahead of typical. Industry P90 compares you against the top decile and answers the question of how far you are from best in class.

Switching the benchmark changes every delta on screen but never changes the underlying score. A driver that sits at +9 against the median can sit well below zero against the top decile, and both readings are correct.

Team breakdowns

Every driver and workflow can be broken down by team, following your team hierarchy. Parent teams show an aggregate and expand to reveal their child teams, so a director sees the rolled-up picture and a team lead sees their own.

Sample size is displayed as responses received out of people surveyed, and it should be read alongside every team-level number. A team of one scoring 100 and a team of eight scoring 63 are not comparable results, and small teams will always produce more extreme scores than the organization-wide figure.

Trends over time

Because snapshots repeat, every driver and workflow carries two trend charts:

Average trend - The score or average value across previous snapshots, showing direction of travel.
Distribution trend - How the shape of responses has changed, shown as a stacked area chart. This is often more informative than the average, because it shows whether an improving score reflects everyone getting slightly better or a small group moving a long way while the rest stay put.

Annualized cost

Workflow results are translated into a cost estimate so that friction can be discussed in the same terms as everything else that competes for budget.

The calculation takes the gap between the reported average and a benchmark value, multiplies it by 48 working weeks, and produces a figure in hours per engineer per year. Entering an average annual salary converts that into money, using an assumption of 2,080 working hours per year to derive an hourly rate.

The output is an estimate for framing a conversation, not an accounting figure. Its value is in making the comparison concrete: a workflow costing 127 hours per engineer per year is easier to prioritize against a tooling purchase than a survey score of 2.64 hrs/wk.

Not every workflow has a cost model. Those measuring rates and frequencies rather than time, such as change fail percentage and PR merge frequency, display a dash in the cost column.

Connecting drivers and workflows

Drivers and workflows measure the same problems from two directions, and they are linked to each other in the product. Each driver lists its related workflows, and each workflow lists its related driver, with a link to move between them.

This pairing is what turns a perception score into a diagnosis. A code maintainability score of 60 is a judgement; the related code comprehension workflow showing 2.64 hours per week lost to understanding existing code is the measurement underneath it. When the two agree, you have a well-evidenced problem. When they disagree, that gap is worth investigating on its own.

Finding where to focus

The Heatmap is built for the question of where a problem is concentrated. It grids every team against every metric and colors each cell by its distance from the benchmark, so an issue affecting one team shows up as a band of amber in a single row rather than being averaged into the organization-wide score.

The heatmap can be switched between driver scores, votes, workflow target ranges, and workflow average values, which lets you check whether a low score, a high vote count, and a poor workflow measurement all land on the same team.

Triage

Driver breakdowns include a Triage status per team, which lets managers record what they intend to do about a result. Triage closes the loop on a snapshot: it converts survey output into an owned decision, and it gives the next snapshot something to be measured against.