Influencing Without Authority Questions

This topic covers the behavioral competency of persuading teams, peers, and leaders when you do not have formal decision making power. Candidates should be prepared to describe concrete examples from their experience where they influenced engineering teams, product teams, business leaders, or cross functional stakeholders to change priorities, adopt approaches, improve deliverables, or reach a decision. Assessors will look for how the candidate built credibility, mapped stakeholders, understood constraints and motivations, used data and evidence, framed proposals in terms of business and technical trade offs, created psychological safety for dissent, and found win win outcomes. Good answers show specific actions such as gathering and presenting data, prototyping or providing examples, facilitating consensus building sessions, negotiating trade offs, escalating appropriately when needed, and following through to measure impact. Candidates should also explain how they handled disagreement, preserved relationships, and adapted their approach for engineers, product managers, or executives.

HardTechnical

79 practiced

You suspect a reliability improvement failed because other deployments confounded the results. Design an analysis plan to isolate the effect of your change: specify experiment design or controls, statistical techniques, logging/telemetry requirements, and how you'd communicate uncertainty to stakeholders.

Sample Answer

Goal: determine whether my reliability change caused the observed improvement (or failure) while other deployments confounded results.

Experiment design / controls- Prefer a randomized controlled rollout (canary A/B): randomly route a percentage of traffic to the new change (treatment) and remaining to baseline (control) for the same time windows and regions.- If randomization impossible, use quasi-experimental designs: staggered rollouts (difference-in-differences), or synthetic control using similar services/regions not receiving the change.- Ensure deployment isolation: freeze unrelated deploys for a short guarded analysis window or tag concurrent deploys so they’re controlled for in models.

Telemetry & logging requirements- High-cardinality event tags: deployment_id, build_id, instance_id, region, node_pool, timestamp, request_id, trace_id, customer_tier.- Capture pre/post metric series at fine granularity: error rates, latency p50/p95/p99, CPU/mem, queue lengths, retry counts, SLO burn rate.- Instrument feature flag exposure and rollout percentage; export deployment timelines to the telemetry store.

Statistical techniques- Primary: difference-in-differences comparing treated vs control over pre/post windows, with fixed effects for region/time-of-day.- Robustness: interrupted time series with ARIMA/Gamma regression to model autocorrelation; use clustered standard errors by instance/region.- Causal: propensity-score weighting if assignment non-random; regression adjustment controlling for concurrent deploys and traffic volume.- Hypothesis testing: predefine metrics and direction, use Benjamini-Hochberg to control false discovery when testing multiple metrics; report effect sizes with 95% CIs and minimum detectable effect.- Check assumptions: parallel trends test for DiD, examine residuals, run placebo tests on pre-period.

Practical steps- Freeze other nonessential deploys for 1–2 maintenance windows if business allows; otherwise tag everything and include as covariates.- Run the canary for sufficiently long to reach statistical power; compute power up-front.- Run subgroup analyses (regions, customer tiers) and sensitivity analyses (vary pre/post windows).

Communicating uncertainty- Report point estimates, 95% CIs, and minimum detectable effect; translate to SLO impact and user-visible outcomes (minutes of downtime avoided).- Explain assumptions (randomization, parallel trends) and how violations affect conclusions.- Present alternative explanations uncovered (concurrent deploy X correlates with metric change) and recommended next steps: revert, expand canary, or run controlled AB-test.- Provide decision recommendation with risk assessment (probability that effect ≠ 0 and cost of wrong decision) so stakeholders can weigh trade-offs.

HardTechnical

88 practiced

A long-standing lack of trust between SRE and development teams has led to low collaboration. Propose a 6-month program to rebuild trust, including measurable milestones, rituals (for example, shared oncall rotations), and how you'd measure and report trust improvements.

Sample Answer

Situation: Long-standing mistrust between SRE and dev teams is reducing collaboration, slowing incident response, and increasing toil.

Goal (6 months): Rebuild trust so teams operate as one reliability-focused org: shared ownership of incidents, measurable improvement in collaboration metrics, and reduced mean time to resolution (MTTR).

Program (month-by-month milestones & rituals):- Month 0 — Align & baseline: run joint kickoff, anonymous trust survey, capture current MTTR, number of cross-team PRs, and incident handoff friction points.- Months 1–2 — Visibility & empathy: - Rituals: weekly 60-min “Reliability Café” where teams demo recent incidents & root causes; monthly shadowing (engineer shadows SRE and vice versa). - Milestone: 100% participation in at least one shadow session per team; survey trust +10% from baseline.- Months 3–4 — Shared responsibility: - Rituals: pilot shared on-call rotations (opt-in initially), joint runbooks, paired runbook drills every sprint. - Milestone: 25% services on shared on-call; runbook coverage 80%; observable reduction in escalation time by 20%.- Months 5–6 — Institutionalize & scale: - Rituals: quarterly joint retros with blameless postmortems and action-item tracking; SLOs and error budgets co-owned. - Milestone: shared on-call at goal level (e.g., 50%), MTTR reduced by 30%, cross-team PRs increased by 40%, trust survey +30%.

Measurement & reporting:- Quantitative: MTTR, time-to-ack, number of joint PRs, runbook coverage, % services with shared on-call, incident reopen rate.- Qualitative: regular pulse surveys (Net Promoter-like trust score), sentiment analysis on blameless postmortems, and structured interviews.- Reporting cadence: biweekly dashboard updates to leadership; monthly all-hands summary with progress vs. milestones; highlight wins and remaining pain points.

Risk mitigation & success factors:- Start opt-in to build early advocates; appoint reliability ambassadors in each team; enforce psychological safety with blameless language; tie part of performance goals to collaboration metrics.

This program creates predictable rituals, measurable milestones, and transparent reporting to restore trust and sustainable collaboration.

MediumTechnical

108 practiced

Product wants a risky global configuration change deployed in two days. You cannot block the release but worry about maintaining 99.99% availability. How would you influence the rollout plan to reduce risk (e.g., staged rollout, feature flags, observability), and how would you present trade-offs and guardrails to executives and product managers?

Sample Answer

Situation: Product wants a risky global configuration change deployed in two days. The business needs speed, but we must protect our 99.99% availability SLO.

Recommendation (high-level):- Don’t do a single global flip. Use feature flags + staged rollout + strong observability and automated guardrails.

Concrete rollout plan I’d influence and implement:1. Feature flagging: implement a server-side flag with targeting (by region, account tier, or percentage). Include an instantaneous kill-switch.2. Canary phase (0–3 hours): 0.5–1% of traffic to a small set of healthy instances/regions. Validate core metrics.3. Ramp phase (24–48 hours): 1% → 5% → 25% → 100%, waiting for stability window (e.g., 30–60m) at each step.4. Automated rollback: define deterministic rollback triggers (error rate > x%, p95 latency increase > y ms, CPU saturation delta > z%) and wire into CI/CD so the flag can be turned off automatically.5. Observability: pre-built dashboards for key signals (error rate, latency histograms, saturation, downstream errors, user-facing KPIs), and synthetic tests + detailed tracing for new code paths.6. Runbooks & staffing: on-call SRE + dev owner during canary and ramps; 2-hour escalation window and post-mortem if any auto-rollback occurs.7. Verification: post-rollout smoke tests and stakeholder sign-off.

Trade-offs I’d present to execs/PMs:- Fast global release: lowest delivery time but highest blast radius; greater chance of SLO breach, larger incident cost.- Staged rollout (recommended): adds 1–2 days and operational overhead but reduces risk dramatically and preserves customer trust. Enables safe rollback with minimal user impact.- Extra engineering (feature flags, dashboards): upfront effort and temporary complexity, but reusable for future releases and reduces long-term risk.

Guardrails and measurable commitments I’d propose:- Keep within existing error budget; if breached, pause all risky releases.- Concrete rollback thresholds (quantified) and SLA impact estimates for each option.- A go/no-go checklist: monitoring green, rollback tested, smoke tests pass, on-call scheduled.

How I’d present it:- One-slide summary: options, expected time to completion, probability of SLO impact, proposed plan (staged + flags), required actions and owners.- Two supporting slides: 1) rollout timeline + decision gates, 2) precise metrics/thresholds and runbook snippets.- Ask for decision: approve staged plan (recommended) or accept increased incident risk for global immediate deploy.

This balances product urgency with our responsibility to protect 99.99% availability, giving leadership clear visibility into trade-offs, operational costs, and recovery guarantees.

HardTechnical

73 practiced

A product team repeatedly ignores SRE advisories and SLOs, causing breaches. You do not have authority to block releases. Describe a principled escalation path, ready-made communication templates, and governance changes you would propose to prevent future recurrences while minimizing political damage.

Sample Answer

Situation: A product team repeatedly disregards SRE advisories and SLOs, resulting in repeated breaches. I cannot block releases but must stop recurrence with minimal political fallout.

Escalation path (principled, predictable):1. Advisory + Data (T+0): Issue formal advisory including evidence (SLO metrics, error budget remaining, risk assessment) and recommended mitigations; copy product PM and engineering manager. Set a 48-hour remediation window.2. Risk Notice (T+48h): If unaddressed, send an elevated risk notice to product director and release manager summarizing unresolved risks and potential customer impact; request explicit acceptance of risk.3. Reliability Review (T+72h): Convene a short Reliability Review with SRE lead, product director, engineering manager, and release owner to decide: delay, mitigate, or accept. Capture decision and owner.4. Exec Escalation (if breaches recur): Provide a 1-page exec summary to CTO/VP Eng with quantifiable impacts and recommended governance change requests.5. Post-Incident: Mandatory blameless postmortem and required remediation plan tracked to completion.

Ready-made templates- Advisory (short):Subject: [Advisory] SLO risk for <service> — <metric> approaching thresholdBody: We observe <metric> = X (SLO target Y). Error budget remaining Z%. Risk: <impact>. Recommend: [1] hold release; [2] feature flag; [3] rollback. Please respond within 48h with plan. — SRE

- Risk Notice:Subject: [Risk Notice] Unresolved SLO risk for <service>Body: Advisory sent <date> unresolved. If release proceeds, expected customer impact: <est>. Please confirm who accepts this risk within 24h or we will escalate to Reliability Review.

- Reliability Review minutes: Decision, owner, deadline, mitigation, acceptance signature.

Governance changes to prevent recurrence- Make SLOs and error budgets a required input in release checklist and CD pipeline (automated SLO gating & pre-deploy dashboard).- Require documented risk acceptance (signed by product director/eng manager) if proceeding with breached SLOs; log in change calendar.- Create weekly Reliability Review (SRE + product leads) for early risk detection.- Introduce reliability KPIs into product manager goals and performance reviews.- Mandate training and a “reliability champion” in each product team.- Audit quarterly compliance and publish a short transparency report to leadership.

Minimizing political damage- Use data, not blame; offer mitigation help and clear options.- Keep communications concise, factual, and offer to pair with engineers to implement fixes.- Require explicit risk acceptance so responsibility is visible—this protects teams and prevents hidden decisions.

This approach balances technical enforcement, clear accountability, automation, and collaborative culture to reduce future breaches without unilateral blocking.

MediumTechnical

103 practiced

You led a post-incident review where initial conversation blamed an on-call engineer and product miscommunication. As an SRE without authority, how would you steer the postmortem to be blameless, extract root causes, and secure cross-team, time-bound follow-ups? Provide your agenda, facilitation tactics, and follow-through plan.

Sample Answer

Situation: I led a post-incident review after an outage where early conversation blamed an on-call engineer and product miscommunication. As an SRE without formal authority, I needed to keep the review blameless, surface true root causes, and get concrete cross-team, time-bound actions.

Agenda (60–75 min)- 0–5m: Purpose & rules — blameless, facts-first, time-boxed outcomes- 5–15m: Timeline of events — read-only timeline prepared in advance- 15–30m: Technical root-cause analysis — data, logs, metrics- 30–45m: Contributing factors — people/process/tools (not individuals)- 45–60m: Action items — owner, due date, verification metric- 60–75m: Wrap-up & next steps

Facilitation tactics- Start with a clear blameless statement and shared intent (learning, prevention)- Use prepared timeline and evidence to focus discussion on facts- Apply “5 Whys” and fishbone prompts, but stop when causes are actionable- Intervene on finger-pointing: redirect to systems/process (“what allowed this?”)- Ensure psychological safety: invite the on-call engineer to describe decisions; acknowledge complexity- Use a neutral template (incident timeline, impact, root causes, contributing factors, action items) visible to all- Ask clarifying questions, call out assumptions, and summarize consensus in real time

Follow-through plan- Capture actions in a shared tracker (Jira/Confluence) with: action, owner, due date, acceptance criteria, verification metric- Require cross-team sign-off within 48 hours on owners and dates- Short weekly sync (10–15m) until actions complete; SRE to chair but not own all tasks- Verify with post-implementation runbook tests and SLO/error-budget checks; close only after validation- Share a one-page readout to stakeholders and include lessons in on-call training- After 30/90 days, audit whether changes reduced similar incidents (metric-based)

This approach turns blame into systems improvement, creates accountability without hierarchy, and ensures measurable follow-through.

Unlock Full Question Bank

Get access to hundreds of Influencing Without Authority interview questions and detailed answers.

Join thousands of developers preparing for their dream job.