Platform
The half of engineering performance your systems cannot see.
Delivery data tells you what happened. It will never tell you that the build has been flaky for six weeks, that on-call is grinding people down, or that three people are quietly interviewing. Developer NPS and pulse surveys will — and in Pacia they render beside the delivery metrics rather than in a separate tool nobody opens.
250 ready-made questions across six categories. Responding never needs a paid seat.
- dNPS
- +35, up 8 on last month
- Response rate
- 31 of 38 (82%)
- Lowest-scoring topic
- Local build reliability
- Biggest mover
- Deployment confidence, +1.4
- Falling two periods running
- Release process confidence
Reported on a rolling three-period basis so direction is visible, not just position.
What developer NPS is, and why engineering orgs run it
Developer NPS — dNPS, and its close relative eNPS — adapts the Net Promoter Score to the people who build your software. One question does the scoring work: *how likely are you to recommend this organisation as a place to work?*, answered 0 to 10. Everything else in the survey explains the movement.
It matters because engineering attrition is both the most expensive and the most predictable problem an engineering leader has. Replacing a mid-level engineer costs somewhere between six months and a year of their salary once you count recruitment, ramp-up and the delivery that did not happen. And it is predictable: dNPS falls, and free-text answers turn specific, well before anyone resigns. A quarterly score gives you roughly one warning; a monthly one gives you three.
The second reason is that it is the only measure of the Satisfaction dimension that exists. You can instrument throughput, cycle time, review load and failure rate from your systems. There is no telemetry for morale. If you do not ask, you do not have it — and every serious engineering-performance framework, SPACE and DX included, treats that as a first-class dimension rather than a soft extra.
How the score actually works
The arithmetic is simple and almost universally got slightly wrong. Passives are counted in the denominator and then discarded, which is what makes the score move so much more sharply than an average would.
How a developer NPS score is calculated
- 0
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
dNPS = % promoters − % detractors Range −100 to +100. Passives count in the denominator, never in the result.
Worked example — 40 responses
- 22 promoters55%
- 10 passives25%
- 8 detractors20%
- dNPS55 − 20 = +35
Scoring it the way modern engineering teams do
These are the conventions that make a dNPS programme survive its first year. Pacia is built around them rather than leaving you to discover them.
One true NPS question, many rated questions
Only "would you recommend this organisation as a place to work" is scored as a real NPS. Every other 0–10 question is tracked as a **mean** and its trend. Scoring twenty questions as NPS produces twenty violently unstable numbers and no signal.
Track direction, never position
An isolated dNPS is close to meaningless — there is no credible cross-industry benchmark for engineering orgs, and team size alone swings it wildly. Six identical runs give you the only thing worth reporting: whether it is rising.
Never reword a live question
A reworded question is a new question and it breaks the trend line. Pacia links answers across periods by the library question they came from, so an ad-hoc question typed into the builder can never be trended. Retire and replace rather than edit.
Same questions, same cadence, same day
Build the survey once, then duplicate it unchanged each period. Six identical runs give six comparable points per question; six edited runs give you nothing. An inconsistent gap between runs makes the trend unreadable.
Watch the small-sample effect
On a team of eight, one person moving from 6 to 9 swings dNPS by 25 points. Report the response count beside the score always, and treat single-period movement on a small team as noise until a second period agrees with it.
Aggregate, and keep it that way
Survey results are reported in aggregate and at question level. This is the one part of Pacia deliberately not attributed to a person — sentiment stops being truthful the moment it can be traced back, and a single breach of that ends your response rate permanently.
Why the first run always disappoints
Why one run tells you nothing and six tell you everything
Month one produced −5, which on its own is a number nobody can act on — too small a sample, no baseline, and no way to tell noise from signal. The same question asked unchanged for six months produced the only thing worth reporting: a direction.
dNPS is not only an internal number any more
Most teams start running dNPS as an internal health check and are then surprised by how often it gets asked for externally. It has quietly become a piece of evidence that people outside engineering — and outside the company — expect you to have.
Recruitment and employer brand. Senior engineers research employers properly now. A named, current developer-satisfaction figure and a credible account of what you changed because of it is a far stronger signal than any careers-page copy, and it is increasingly used that way in offer conversations.
Investor and acquirer due diligence. Technical due diligence has moved well past architecture review. Engineering attrition risk, team stability and key-person dependency are standard questions in a Series B or an acquisition, and "we measure it monthly and here is the eighteen-month trend" is a materially different answer from an estimate.
Enterprise customers and partners. Large procurement processes increasingly probe supplier stability, because your attrition becomes their delivery risk. This turns up in vendor questionnaires alongside security and continuity questions.
Board and people reporting. Engineering is usually the largest cost line and the least legible one. A dNPS trend beside the delivery metrics gives a board something to interrogate that is not a headcount table, and it pairs naturally with the wider people and culture reporting most boards already receive.
The practical consequence is worth planning for: if the number is going to be quoted outside the team, it has to be collected honestly and reported with its response rate and sample size attached. A flattering figure nobody believes is worse than a middling one everybody does.
Every question maps to SPACE
SPACE — Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow — is the framework this question library is organised around. It exists because single-metric productivity measurement reliably fails, and it is the vocabulary your questions should already be speaking.
The SPACE framework — what is asked, and what is measured
Satisfaction & well-being
SurveyWorkload, morale, wellbeing, recognition, eNPS
SystemNothing. This dimension can only be asked.
Performance
SurveyPredictability, quality confidence, outcomes
SystemChange failure rate, escaped defects, sprint hit rate
Activity
SurveyFocus time, interruption, meeting load
SystemPR throughput, deployment frequency, contributor boards
Communication & collaboration
SurveyKnowledge sharing, code review culture, cross-team friction
SystemReview load, reviewer concentration, pickup time
Efficiency & flow
SurveyProcess fit, blockers, tooling friction
SystemCycle time by stage, lead time, work in progress
Three of the five dimensions have a system-data counterpart in Pacia, so a survey answer and a delivery metric can be read side by side. Satisfaction has none — there is no telemetry for how people feel, which is precisely why the survey is not optional.
The question catalogue — 250 questions, ready to use
Every question is written, categorised and version-tracked in a global library that seeds itself when the platform starts. You compose a survey by picking from it rather than by writing questions, which is also what makes answers comparable across periods — only library-sourced questions carry the identity that links April’s answers to October’s.
| Category | Questions | What it covers |
|---|---|---|
| Developer experience | 70 | Direction, collaboration, culture, user needs, focus, planning, development, architecture, systems, quality, security, deployments, CI, incidents, observability, maintenance, pull requests, developer platform, AI tools, engineering effectiveness, eNPS |
| Workplace & wellbeing | 53 | Morale, workload, wellbeing, recognition, trust, psychological safety, inclusion, growth, leadership, communication, retention and advocacy |
| AI adoption | 45 | Adoption, access, trust, code quality, review, verification, security, privacy, policy, enablement, attribution, workload and measured impact |
| Engineering practice | 38 | Autonomy, tooling, friction, focus, standards, ownership, priorities, requirements, meetings, trade-offs, visibility and improvement |
| Monthly pulse | 22 | The fixed 22-question run: about you, your skills, processes, knowledge, the team, eNPS and three free-text prompts |
| Onboarding | 22 | Welcome, access, environment, codebase, role clarity, manager support, connections, confidence, belonging and first delivery |
Categories are combinable — a monthly pulse and a one-off AI-adoption survey draw from the same library, so a question asked in both trends across both.
Or start with the survey we already run
Dev Pulse is a fixed 22-question monthly run — 19 rated, 3 free text, about three minutes to complete. It is opinionated on purpose: the hardest part of a survey programme is not writing questions, it is not changing them.
About you (3)
Capability growth month on month, whether there was time to learn rather than only deliver, and whether the workload was sustainable.
Your skills (4)
A 0–10 confidence grid across the languages, frameworks, testing and AI tooling your codebase actually uses. Renders as a topic-by-month heatmap.
Processes (6)
How well people understand issue tracking, branching, deployment, pipelines and infrastructure — plus one agreement question on whether the process helps or obstructs.
Knowledge (2)
Whether knowledge is shared rather than held by individuals, and whether the team would keep moving if any one person were away for a fortnight.
The team (3)
Efficiency month on month, predictability against commitments, and whether work flows without long waits and handoffs.
eNPS + free text (4)
The one true NPS question, then: what would you change today, what is your biggest blocker, and what worked that we should keep.
Running it each period
Roughly ten minutes of work per month once the first survey exists.
Build it once first time only
Compose from the library in the survey builder, picking questions rather than typing them. Only library-sourced questions can be trended, so this step decides whether you have a programme or a series of one-offs.
Duplicate last period’s run 1 min
Duplicate, rename, and change nothing else. The duplicate deliberately arrives with its date window cleared, so a copy can never launch already closed.
Send and chase 5 min
Respondents answer through a tokenised link — no Pacia seat required, and no licence conversation about who is allowed to have an opinion. Chase to a response rate you would be willing to quote.
Close, then publish to the team first 3 min
Publish the results to the people who answered before you take them to stakeholders. Surveys whose results are never shown back stop being answered, usually by month four.
Report in three-period blocks
Section means over the last three periods, the dNPS trend, the confidence heatmaps, and the top three blocker themes from free text — with what was done about last period’s top three.
What the published results actually give you
Collection is the easy half. Almost every abandoned survey programme died at the reporting step, so this is where the product does the most work.
A shareable published results view
Close a survey and publish it, and the results become a link you can send to everyone who answered — no seat, no login negotiation. Closing the loop visibly is the single strongest predictor of next period’s response rate.
Question-level drill-down
Open any individual question rather than only a composite. A section mean that dropped four points is not actionable; the one question inside it that dropped fifteen almost always is.
Rolling three-period trends
Every question and every section carries the current period plus the previous two, so movement reads as movement. This is the default because a single score has almost no information in it.
Confidence heatmaps
The skills and process grids render as topic-by-period heatmaps — the clearest "capability is increasing" evidence most engineering leaders have. They are self-ratings, so they measure confidence rather than competence; pair them with the knowledge-coverage question, which is harder to flatter yourself on.
Response rate on every figure
Shown beside the score, always. A +40 from nine of forty people is a different fact from a +40 from thirty-four, and separating them is what keeps the number credible when it is quoted outside the team.
Free-text themes
The three open questions sit at the end and are never scored. In practice they are where the actionable material is — the rated questions tell you which area moved, the free text tells you why.
Read beside the delivery data
Results render in the same platform as DORA, cycle time and the contributor boards. Throughput falling while sentiment holds is a capacity problem; both falling together is usually process or tooling. Neither reading is available if the survey lives in a separate tool.
Questions about running developer surveys
What is a good developer NPS score?
There is no credible cross-industry benchmark for engineering organisations, and anyone quoting one should be asked for the sample. As orientation, engineering teams commonly report somewhere between −10 and +40, and team size alone moves it enormously. The useful target is your own trend over six periods, not a number to hit.
What is the difference between dNPS and eNPS?
The arithmetic is identical. eNPS is employee NPS across a whole company; dNPS is the same question asked specifically of engineers, usually alongside questions about tooling, process and codebase that a company-wide survey would never include. Engineering-specific results are the ones that lead to engineering-specific action.
How often should we run it?
Monthly for a pulse of around twenty questions, or quarterly for something longer. Monthly is generally better: it gives you three warnings before a resignation rather than one, and a short survey run often gets a better response rate than a long one run rarely.
Are responses anonymous?
Results are reported in aggregate and at question level, and this is the one area of the platform deliberately not attributed to individuals. Say so explicitly when you send it — people answer for the audience rather than the truth if they are unsure, and one breach of that ends your response rate permanently.
Do respondents need a Pacia licence?
No. Surveys are answered through a tokenised link and responding never requires a seat. Billing counts only people who authored or reviewed code, so a survey programme adds nothing to your bill.
Is this a separate module we pay extra for?
No. Surveys, the full 250-question library and the published results views are included in the standard price. Several platforms in this category license developer-experience surveys separately.
How do surveys relate to the SPACE framework?
The library is organised around it. Satisfaction and well-being can only ever be asked; Performance, Activity, Communication and Efficiency each have both a survey side and a system-data side, and in Pacia both live in the same platform so they can be read together.
What if the results are bad?
Then you have found something, which is the point, and you have found it while it is still fixable. The failure mode to avoid is collecting results and not publishing them — a low score that visibly produced a change recovers response rates, while a hidden score ends the programme.
Ask the questions your delivery data cannot answer
Start from the 250-question library or run Dev Pulse unchanged. Responding never needs a seat, and results land beside the delivery metrics rather than in another tool.