Pipeline data tells you what happened, not how it felt. A five question survey, sent quarterly, fills the gap. Ask about trust, clarity, speed, fairness and workarounds, keep it anonymous and short, and pair every answer with a pipeline measure.
Why ask at all
Two teams can show the same failure rate and feel completely different about it. One sees a gate that catches real problems. The other sees an obstacle. Metrics will not show the difference, and the second team's behaviour, such as batching changes to avoid checks, will eventually show up in risk.
The five questions
Use a simple agreement scale, plus one free text box.
- Trust. When a security check fails on my change, I believe the failure is real.
- Clarity. When a check fails, I know what to do next without asking someone.
- Speed. Security feedback arrives in time for me to act on it while I am still working on the change.
- Fairness. The rules apply the same way to everyone, and exceptions are handled in a reasonable time.
- Workarounds. In the past quarter, I have retried, delayed or avoided a security check to get my work done. (Yes or no, with an optional note.)
The free text question: "What is the one change to security checks that would help you most?"
Match each question to data
| Question | Pipeline measure to compare |
|---|---|
| Trust | Flake rate, re-run rate |
| Clarity | Time to unblock, understood stage |
| Speed | Time to first security feedback, queue time |
| Fairness | Override and exception counts, approval time |
| Workarounds | Skipped runs, bypass events, abandoned changes |
If the survey and the data disagree, investigate. A team that reports low trust while the flake rate is low may be reacting to a past problem, or to noise your measure misses.
Running it well
- Keep it to a few minutes, with the same questions every time so you can compare quarters.
- Make it anonymous, and report only for groups large enough to protect individuals.
- Share results and what you will change, within a few weeks. A survey with no visible response is the last one anyone completes.
- Do not tie results to anyone's performance review.
- Invite a few developers to read the free text with you and suggest fixes.
What not to do
Do not use the survey to prove the gate is fine. Do not collect more than you can act on. Do not run it right after a disruptive rollout and treat the result as steady state. If you need to measure a specific change, run a short pulse on that change.
Reading small groups
With few respondents a single strong opinion will move the score. Report the number of responses alongside each result, and give the free text more weight than the scale in small teams.
Quick check
How often should we run it?
Quarterly is enough for most teams. Add a short pulse after a major gate change.
Can the survey replace pipeline metrics?
No. It explains the metrics. Use both.
How Safeguard fits
Safeguard provides policies, gates and guardrails over dependency scanning, so you can adjust what blocks based on what developers tell you. Try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
