No leaderboards: measure onboarding without breaking trust
Leaderboards feel like a shortcut: “make it visible, reward the top, and the rest will follow.”
For onboarding and upleveling, they usually do the opposite. They create fear, encourage gaming, and teach new engineers to stop asking questions.
If you want faster ramp and stronger teams, measure the system — not the people.
The rule: questions are a signal, not a failure
New engineers asking questions is healthy. It means they’re trying to move.
When questions are punished (explicitly or implicitly), the team gets:
- quiet confusion
- production mistakes
- “I didn’t want to bother you” incidents
- slow ramp hidden behind polite status updates
You can’t improve what people are afraid to reveal.
What to measure instead (team-level)
These signals improve onboarding without turning it into judgment:
1) Repeat questions (by workflow)
Track the repeat questions that keep coming up in the same workflow: deploys, triage, migrations, etc.
If repeats are high, it’s not a people problem. It’s a missing-owner / missing-link / missing-runbook problem.
2) “Who owns this?” pings
Count how often questions start with ownership confusion.
Ownership clarity is one of the highest-leverage onboarding fixes you can make.
3) Time-to-unblock (rough and directional)
You don’t need perfect instrumentation. Pick a consistent proxy:
- time from first question → confirmed next step
- time from “stuck” → first useful link/owner
You’re looking for trendlines, not courtroom evidence.
4) Fixes shipped
This is the most important one: what did you actually improve?
- runbook updates
- dashboard links added
- ownership clarified
- “first checks” written down
Measure the outputs. That’s what changes outcomes.
What not to measure
Avoid metrics that turn onboarding into a rank:
- questions per person
- “time spent stuck” per person
- tickets closed per person “to help onboarding”
Those metrics can be weaponized, and people will react accordingly.
How to talk about it (so engineers trust it)
When you introduce an onboarding program, say this out loud:
- This isn’t performance management.
- We’re measuring the workflow, not individuals.
- The aim is better answers, not fewer questions.
- If something is confusing, we fix the system.
That’s how you get staff/principal engineers to lean in and new engineers to feel safe.
Where DawnOps fits
DawnOps is designed around this exact boundary: team-level by default, no leaderboards, and answers that point to owners and source links so engineers can verify quickly.
If you’re deciding what to build next, start by picking one workflow and tracking repeat questions. It will tell you exactly where to invest.