Use repeat questions to prioritize what to fix next
When leaders ask, “What should we fix next?”, the usual answers are vague.
You get:
- “onboarding”
- “developer experience”
- “reduce toil”
But your engineers are already telling you what to fix. They tell you every time they ask the same question again.
Repeat questions are a backlog.
Prioritization axis: frequency vs cost
Use this to pick the next fix:
Cost of failure ↑
High | Strategic fix next. | Do now. Highest leverage.
Low | Tidy when convenient. | Quick win this week.
Low frequency ---------> High frequency
Most repeats fall into four buckets
1) Missing owner
Symptoms:
- “who owns this?”
- “who do I page?”
Fix:
- define an owner and escalation path where the question happens
2) Missing link
Symptoms:
- “where’s the runbook?”
- “which dashboard is the truth?”
- “where do I check deploy history?”
Fix:
- add source links and pin them to the workflow
3) Missing first checks
Symptoms:
- new engineers escalate at step zero
- seniors answer with a list of 5 checks every time
Fix:
- capture first checks and keep them verifiable
4) Missing guardrail
Symptoms:
- the “right answer” is “be careful”
- repeat incidents come from the same sharp edge
Fix:
- ship a small guardrail (alert tuning, safe rollback, safer defaults)
A simple way to score what matters
Don’t over-instrument. Just track, per workflow:
- how often the question repeats
- how often it escalates
- how expensive it’s when it goes wrong
Then pick the smallest fix that makes the next week easier.
The trick: measure the workflow, not people
If this turns into performance management, engineers will hide.
Keep it team-level:
- repeat questions by workflow
- escalations by workflow
- runbook and ownership fixes shipped
If you do this consistently, “onboarding” stops being a vague initiative and becomes a set of fixes you can ship.