Quietly Fearless Leadership for 4 Golden Signals
Italic sub-headline: Practical moves to lead without megaphones or mayhem.
Start By Deleting Work, Not Adding It
Most leadership mistakes start with a good intention and a calendar invite. We’ve learned to lead by subtraction. It’s disarmingly simple: before we introduce a new ritual, tool, or acronym, we delete something that’s already eating cycles. If we can’t name what gets removed, we hold the idea until we can. The reason’s pragmatic: teams don’t fail because they lack initiatives; they fail because they’re full. Capacity isn’t an inspirational poster; it’s math.
Here’s a baseline play. Identify the top three recurring status artifacts across teams. Consolidate them into one source of truth that auto-updates from the tools of record—builds, incidents, deployments. Then make a rule we actually follow: if data exists in the system, we never retype it into a deck. Next, cut meeting load by 20% within two weeks. How? Shorten weekly status meetings to 15 minutes, delete anything older than six months, and require pre-reads sent 24 hours in advance. If there’s no pre-read, we reschedule, no apologies needed.
As leaders, we also protect deep work. We move approvals to asynchronous channels and time-box them. Our job is to reduce decision queue time, not to write longer memos. Subtraction leadership signals trust. It says, “We believe you can do the job without us narrating it.” We still set clear constraints—budgets, reliability targets, security boundaries—but within those, we make space. The result is quieter Slack, shorter queues, and oddly, better surprises.
Make Leadership Observable With Real Metrics
We monitor services with the four golden signals; why not apply the same to leadership? If you’re curious, the canonical version lives in Google’s SRE text on monitoring distributed systems: SRE Golden Signals. Let’s create human versions:
- Decision latency: time from request to decision.
- Error rate: percent of decisions reversed or reworked within 30 days.
- Traffic: interrupts to senior engineers per workday.
- Saturation: team calendar load during core hours.
We don’t need a consulting engagement to begin. We add a few lightweight counters from the tools we already have. We track PR approval times for “decision latency.” We measure re-opened tickets or rolled-back changes for “error rate.” Interrupts are pings tagged “@here” in support channels. Calendar saturation is just a percentage of core hours booked.
If you’re feeling spicy, wire a quick exporter. A homegrown metric name never hurt anyone:
# HELP leader_decision_latency_seconds 99th percentile time to decision
# TYPE leader_decision_latency_seconds gauge
leader_decision_latency_seconds{team="payments"} 28800
leader_decision_latency_seconds{team="search"} 14400
# HELP interrupts_per_engineer_total Daily interrupts tagged @here
# TYPE interrupts_per_engineer_total counter
interrupts_per_engineer_total{team="platform"} 7
Add an alert when we’re the bottleneck:
groups:
- name: leadership
rules:
- alert: LeadershipDecisionBottleneck
expr: leader_decision_latency_seconds > 28800
for: 2h
labels:
severity: page
annotations:
summary: "Decision latency > 8h for {{ $labels.team }}"
description: "Hold office hours or delegate temporarily."
We’re not chasing vanity metrics. We’re publishing our own SLOs. If our decision latency spikes, we say so publicly and adjust how we work. That’s a signal teams understand.
Decide Fast With Defaults, Not Decrees
Big memos don’t scale; defaults do. Decrees create side-channels; defaults create momentum. We steal a trick from standards folks and use normative language from RFC 2119: MUST, SHOULD, MAY. We reserve MUST for security and compliance. Everything else is a strong SHOULD with a default implementation that’s one command or one copy-paste away.
For code and infra, the most practical default is ownership. We add a CODEOWNERS file in every repo with names, not committees. This isn’t bureaucracy; it’s a map. When someone wants to change the map, they can, but they know who to talk to. GitHub even does the nudging for us: About CODEOWNERS.
# CODEOWNERS
# Default owners
* @team-platform
# Critical paths
infra/** @team-infra
api/** @team-backend @oncall-backend
ui/** @team-frontend
We pair it with branch protections and clean defaults. Whether through Terraform, org policy, or a simple YAML, the message is the same: we made the safe path the easy path.
# .github/settings.yml
branches:
- name: main
protection:
required_status_checks:
strict: true
contexts:
- ci/build
- ci/test
enforce_admins: true
required_pull_request_reviews:
required_approving_review_count: 1
dismiss_stale_reviews: true
restrictions: null
Now we don’t argue about process in DMs. The repo nudges us toward good behavior, and leaders only intervene when defaults fail. That scales better than any all-hands speech.
Shrink Feedback Loops To 48 Hours
We love quarterly plans, but the real magic happens in 48-hour cycles. It’s long enough to do non-trivial work, short enough to adjust without hand-wringing. Here’s the leadership twist: we commit to return decisions, unblockers, or feedback in two business days. We publish that SLA and let teams hold us to it. It’s remarkable how much faster an organization feels with just that promise.
Why 48 hours? It lines up with the spirit of the DORA metrics—low lead time for changes, high deployment frequency, low change failure rate, short time to restore. If you want a deeper dive, the Google Cloud overview is crisp: DORA and DevOps research. We treat our leadership inputs like code: small, frequent, reversible. If we can’t reverse it, we write it down and sleep on it once. If it still holds in the morning, ship it.
To support the 48-hour loop, we add two habits. First, visible backlog of leadership asks, not just engineering tasks. We keep it in the same issue tracker and label it “decision-request.” Second, we host weekly open office hours. People bring context, we bring authority, and we leave with recorded outcomes. If we can’t decide in the room, we schedule a follow-up with a named owner and due time, not a fuzzy “later.”
Two-day leadership doesn’t mean chaos. It means we slice decisions to fit the timeframe, defer what needs real thinking, and never let the queue rot.
Promote Maintainers, Not Martyrs
Let’s say it quietly but clearly: heroics are evidence that something upstream failed. We need steady, scalable outcomes, not 2 a.m. legends. That means our promotions and praise must spotlight systems and maintainers. We reward the boring work that keeps services fast, releases smooth, and teams healthy. We also write it down, or we’ll drift back to applauding the loudest incident.
A practical approach is a public rubric that prioritizes maintainability, mentoring, and operational reliability. We ask candidates to bring not just “what I shipped,” but “what stayed healthy after I shipped it.” Did they simplify a deployment pipeline? Reduce alert fatigue? Teach others to be on-call without dread? We measure long half-life impact.
We use a rubric snippet like this when calibrating:
impact_rubric:
maintainability:
L3: "Improves readability/tests in owned components"
L4: "Systematically reduces toil (scripts, runbooks, bots)"
L5: "Redesigns subsystem to cut ops load by >30%"
reliability:
L3: "Triages incidents calmly; writes clear postmortems"
L4: "Eliminates recurring class of incidents"
L5: "Shapes org SLOs; drives error budget policy"
mentorship:
L3: "Guides PRs; shares context proactively"
L4: "Onboards new hires quickly; builds templates"
L5: "Builds a learning program that others reuse"
We still celebrate tough saves. We just celebrate the follow-up more: the small refactor that made the next save unnecessary, the alert we deleted, the handoff that didn’t squeak. People repeat what gets rewarded. Let’s reward stewards.
Ritualize Calm Incidents In 6 Steps
Incident leadership isn’t a special hat; it’s a practiced ritual. We use the same six steps every time so people can stay calm and useful: declare, assign, annotate, stabilize, learn, thank. One sentence each: we declare loudly with a unique ID; we assign an incident commander who doesn’t touch keyboards; we annotate a live timeline; we stabilize by reducing blast radius; we learn with a blameless writeup; we thank the humans who did the work. Yes, every time.
We script away friction. A tiny helper creates the channel, pins the template, and tags the right folks, so no one rifles through docs when cortisol’s high.
#!/usr/bin/env bash
id="INC-$(date +%y%m%d-%H%M)"
slack_channel="#${id}"
gh issue create --title "$id: Service degradation" --label incident
slack chat channel create "$slack_channel"
slack chat post-message "$slack_channel" ":rotating_light: $id declared. Commander: @oncall. Scribe: @help."
slack files upload incident_template.md --channels "$slack_channel"
Our template keeps roles, commands, and comms in one place:
# incident_template.md
Severity: SEV2 Start: 2025-08-24 14:05Z
Commander: @oncall Scribe: @help Liaison: @support
- Status cadence: every 15 minutes in-channel
- External comms: statuspage after 30 minutes if user-facing
- Mitigations tried: ...
- Next update: ...
We also invest in training. One hour a quarter, we run a no-stakes game day and rotate the commander role. If you want a solid open reference for this style, PagerDuty’s guide is a keeper: Incident Response. Calm rituals beat heroic improvisation. People can do their best thinking when the checklist does the heavy lifting.
Build Decision Logs, Not Autobiographies
We don’t need a thousand-page wiki that nobody reads. We need a decision log that’s easy to search, light to write, and quick to consume. It’s leadership’s job to make the “why” behind choices discoverable. That prevents dead debates, keeps new folks on the same page, and helps us undo things when reality changes.
Here’s what works for us. Keep an ADR (Architecture Decision Record) folder in each repo for tech choices. Each ADR is one page: context, decision, status, and consequences. Use a single index issue in the repo that links to ADRs by number and tag. For cross-cutting choices—like on-call policy or SLOs—keep them in a central “decisions” repo with the same format and a README index by topic. Tie decisions to incidents and postmortems: “This change supersedes ADR-012” is a small sentence that saves hours.
We don’t chase perfection. We accept that 20% of decisions won’t get ADRs, and that’s ok. Our bar is “useful next month.” The trick is to write while context is fresh. We add time-boxed writing to the definition of done for big changes. We also surface the latest three decisions in team meetings. People don’t need all the history; they need the latest default and where to argue if they disagree.
When we do this consistently, onboarding time shrinks, architectural drift slows, and debates get shorter. That’s leadership paying compound interest.
Protect On-Call With Boundaries And Budgets
Reliability starts as math and ends as feelings. We can hit five nines and still burn people out. We aim for reliability that humans can sustain. That means we set explicit error budgets, put them where everyone can see, and protect downtime for the people doing the work. We also watch meeting load and after-hours pages the way we watch CPU.
Leadership ensures that on-call is a contract, not a surprise. We publish the rotation three months ahead, cap the number of nights a person can carry in a month, and avoid single points of human failure. We encourage swaps without drama, and we build load-shedding into both systems and calendars. If a team is saturated by interrupts, we throttle by adjusting support tiers or adding a temporary triage role. It’s not glamorous, but it keeps folks whole.
We also make the “no” safe. If error budgets are gone, features wait. If pages cross a threshold two sprints in a row, we plan reliability work on purpose. We ask managers to watch PTO versus on-call—nobody should burn vacation to recover from being up all week. And we celebrate deletes: every retired feature, every removed cron-job, every buried flake. The best page is the one that never rings. Reliability is an outcome, but it’s also a culture tell. Healthy teams fix the source and then go home on time.
What We’ll Try Monday Morning
Let’s wrap with a tiny, testable plan. First, we’ll publish our own golden signals and show them at the staff meeting. We’ll pick two that we can measure in a week—decision latency and interrupts per engineer—and leave alert descriptions in plain language. Second, we’ll install one default that nudges behavior. A CODEOWNERS file or branch protection is enough to start. We’ll announce the default as a reversible experiment and set a date to review it. Third, we’ll delete two meetings and add one office hour. The office hour is the safety net and the decision accelerator; the deleted meetings are the gift.
Then we’ll script one friction reducer. Maybe it’s the incident channel helper, maybe it’s a one-liner that collects approvals from a label. It should take less than an hour to ship, less than a minute to use, and save at least five minutes a week for someone other than us. We’ll also write down a small promotion story we want to tell six months from now—one that features a maintainer, not a martyr—and start collecting the evidence today.
If we can do those few things consistently, we’ll lead a quieter, faster, kinder organization. We won’t need megaphones. The metrics, defaults, and calm rituals will do the talking while we get out of the way and let the teams do their best work.
