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

93 practiced

When introducing a controversial technical standard, you want dissent to be constructive rather than disruptive. What rules, rituals, and lightweight governance would you set up (for example: dissent protocol, structured pre-mortems, acceptance criteria, and regular review), and how would you enforce them without formal authority?

Sample Answer

Situation: I proposed a new binary-compatibility standard for our microservices to reduce runtime failures, and I anticipated strong, emotionally charged pushback because it required extra work up-front.

Rules & lightweight governance I’d set up:- Dissent Protocol: “Raise, Reason, Propose” — when you disagree, file a short dissent note in the RFC with (1) specific concern, (2) evidence or scenarios, (3) at least one alternative or mitigation. No anonymous complaints; focus is on action.- Structured Pre-mortems: Before adoption, run a 60–90 minute pre-mortem: list ways this standard could fail, quantify impact, assign mitigations and owners.- Acceptance Criteria: Concrete, testable gates (e.g., compatibility tests, performance delta ≤5%, migration checklist) required for rollout.- Timeboxed Experiment Window: Allow feature-flagged rollouts for 2 sprints with clear rollback criteria and telemetry.- Regular Review & Sunset: Schedule 90-day reviews; if adoption <X% or incidents >Y, revert or iterate.- Lightweight Roles: RFC author (owner), two reviewers (peer + safety reviewer), and an integration champion to coordinate migration.- Decision Rules: Consensus-with-override — seek consensus; if not achieved by deadline, chair (rotating engineer) makes a documented decision that includes how to re-open.

Rituals:- RFC + Dissent Board: All RFCs and dissents visible in a shared board; dissent items tracked to resolution.- Red-team session: Invite skeptical engineers to attack the proposal in a 45-minute session.- Post-rollout blameless retro: Measure outcomes and publish learnings.

How I’d enforce without formal authority:- Social incentives: Give visible credit to dissenters who surface real issues (publicly acknowledge and tag in release notes).- Make it easy to comply: Provide migration scripts, tests, and pairing time so cost of adoption is low.- Data-first persuasion: Require concrete evidence for strong objections; use experiments/telemetry to settle disputes.- Reciprocity & soft pressure: I’d adopt others’ proposals when they’re hard; build goodwill. Use a rotating small group (“standards guild”) whose recommendations carry cultural weight.- Timeboxing & transparency: Deadlines prevent endless blocking. Public tracking of decisions and outcomes builds accountability.- Escalation for unresolved, safety-critical issues: involve architect or product for tie-break with documented rationale.

Example result: In a past project I introduced an internal linting standard. Using an RFC, pre-mortem, 2-week experiment, and migration scripts, early dissenters proposed performance concerns. We ran an A/B test, fixed hotspots, and credited the dissenters in the changelog; adoption reached 85% in 6 weeks and incidence of style-related bugs dropped 60%. The combination of structured channels, clear acceptance criteria, and practical support turned potentially disruptive dissent into constructive improvement.

MediumTechnical

75 practiced

When trying to convince others of a technical decision, what types of evidence would you gather (for example: metrics, experiments, prototypes, cost estimates, competitor analysis)? For each evidence type, give a short example of how you'd present it differently to engineers, product managers, and executives so it is persuasive to that audience.

Sample Answer

When persuading others about a technical decision I gather multiple evidence types and tailor the presentation to the audience. Examples below show what I collect and how I present it to engineers, product managers, and executives.

1) Metrics (performance, error rates, latency)- Engineers: charts of request-percentiles, flamegraphs, raw logs and regression tests; highlight root-cause.- PMs: trend graphs tied to user impact (e.g., conversion vs. 95th latency); call out user journeys affected.- Execs: single KPI change (e.g., uptime ↑ 2%, churn ↓ 1%) and projected revenue/ops impact.

2) Experiments / A/B tests- Engineers: experiment design, sample sizes, statistical significance, instrumentation code snippets.- PMs: experiment hypothesis, primary/secondary metrics, rollout plan and risk mitigation.- Execs: clear winner/loser, confidence interval, timeline to scale and expected business lift.

3) Prototypes / PoCs- Engineers: prototype repo, benchmarks, trade-off doc comparing APIs and complexity.- PMs: demo of user flow, speed/quality gains, estimated dev effort to productionize.- Execs: short demo video + cost/benefit summary and time-to-value.

4) Cost estimates (engineering, infra, maintenance)- Engineers: breakdown of implementation tasks, dependencies, technical debt cost.- PMs: resource calendar, sprint-cost estimate, opportunity cost vs features.- Execs: budget ask, ROI, and TCO over 1–3 years.

5) Competitor / market analysis- Engineers: technical write-ups of competitor architecture or public posts showing feasibility.- PMs: feature parity map and differentiators for roadmap prioritization.- Execs: market positioning, risks of falling behind, revenue/retention implications.

6) Risk analysis & rollback plan- Engineers: detailed failure modes, monitoring alerts, automated rollback scripts.- PMs: user-facing risk matrix and communication plan.- Execs: high-level mitigation, contingency cost, and go/no-go criteria.

I pick 2–3 of these most relevant, present the same data at different fidelity levels, and always end with a clear recommendation and next actions.

MediumTechnical

101 practiced

In a code review culture that favors quick merges, you want to introduce stricter quality checks and automated testing. How would you persuade both senior engineers and time-pressured managers to adopt these checks incrementally? Provide a 3-month rollout plan including pilots, metrics, and decision gates.

Sample Answer

Situation: Our team’s fast-merge culture increases risk of regressions and technical debt. Goal: introduce stricter quality checks and automated tests incrementally so senior engineers see low friction and managers see measurable ROI.

3-month rollout plan (high-level milestones, pilots, metrics, decision gates)

Month 0 — Preparation (week 0)- Align stakeholders: short 30-min demos to senior engineers + managers showing one real regression and how tests/linters catch it.- Identify pilot repo(s): pick 1 greenfield or low-risk service + one core service with active owners.- Define “checks”: pre-commit linters, CI unit tests, lightweight integration tests, PR-size guideline, and flaky-test detector.

Month 1 — Pilot & gentle enforcement- Week 1–2: Implement tools in pilot repos: add pre-commit hooks, run linters in CI (status only), add test coverage reporting, and a test for a known regression.- Week 3: Run training sessions + pairing for senior engineers; create PR templates explaining benefits.- Metrics to track (baseline + weekly): PR throughput (time-to-merge), CI pass rate, test coverage %, number of post-release bugs, developer feedback score.- Decision gate end of month 1: If CI failure rate due to tooling false-positives <10% and PR throughput impact <20% (or recoverable), proceed; else iterate config.

Month 2 — Broaden & enforce incrementally- Enforce linters and style as CI “required” for pilots (fail CI). Keep heavier checks as warnings.- Introduce automated regression tests into CI and block merges if regression test fails.- Run A/B comparison: pilot teams vs control teams for bug escape rate and cycle time.- Metrics: reduction in bug escapes, CI build time, flakiness rate, PR review time.- Decision gate end of month 2: If bug escapes down ≥30% for pilots and PR review time not increased >15%, expand to 50% of services; otherwise tune tests and address blockers.

Month 3 — Scale + optimize- Expand required checks to additional repos, automate flaky test quarantine, implement merge queues to keep CI stable.- Add business metrics for managers: mean time to production incidents, support tickets, customer-visible bugs prevented, and developer time saved on rework.- Final decision gate: If pilots show sustained lower production defects and acceptable developer velocity, adopt org-wide with rollout schedule; if not, retain partial adoption and run a focused remediation plan.

Persuasion tactics for seniors and managers- For senior engineers: emphasize reduced rework, fewer pager incidents, keep new checks configurable, pair on rule tuning, measure and show individual wins (e.g., “this test prevented X regression”).- For managers/time-pressured execs: show short-term ROI metrics (reduced bug triage hours, fewer hotfixes, improved uptime) and a rollback path. Propose incremental SLAs: start with low-friction wins (linters, small unit tests) that deliver quick measurable impact.

Risk mitigation & practical notes- Start with checks that run fast (<2 min) to protect velocity.- Keep a “fail soft” period (warnings) and clear owner for false positives.- Use feature flags and canary releases to reduce blast radius.- Report weekly dashboard to stakeholders with metrics and human stories.

This plan balances rapid wins, measurable outcomes, and incremental enforcement so engineers keep trust while managers see quantifiable business value before wider adoption.

MediumTechnical

76 practiced

As an IC you want to introduce a new shared library across many repositories. Describe a rollout plan that minimizes disruption, handles versioning and backwards compatibility, persuades repository owners to adopt it, and provides fallbacks if adoption stalls. Include sample communication templates and incentive ideas.

Sample Answer

Situation: I need to introduce a shared library used by many repos with minimal disruption and high adoption.

Plan (phased rollout)1. Requirements & design- Define API surface, stability guarantees, semantic versioning policy (SemVer).- Publish README, migration guide, compatibility matrix, test harness and CI job examples.

2. Pilot (2–4 weeks)- Identify 2–3 friendly teams across different stacks to integrate early.- Provide pair-programming support and fix issues; iterate API.

3. Gradual expansion (4–8 weeks)- Open invitation to more teams; publish weekly changelog and migration checklist.- Add automated linters/DepBot PR templates to suggest upgrades.

4. Organization-wide announcement & opt-in window- After stabilization, publish official package, docs, and deprecation schedule for older patterns.

Versioning & backward compatibility- Use SemVer: patch = bug fixes, minor = backward-compatible features, major = breaking changes.- Support a compatibility shim for one minor version or provide adapter functions.- Maintain migration scripts and automated tests (unit + integration) that run in consumer repos via CI templates.

Persuasion & adoption- Provide low-friction onboarding: npm/maven/pypi package, one-line install, example snippets.- Offer 1:1 help, office hours, and a Slack channel; create “migration kit” PR templates to speed adoption.- Show value: benchmark improvements, reduced bundle size, fewer bugs; share concrete metrics.- Enlist influential maintainers as champions; demo at engineering all-hands.

Fallbacks if adoption stalls- Automatic suggestion PRs (DepBot) to repos with outdated deps.- Maintain a compatibility layer and extend opt-in window.- If needed, deprecate incrementally: turn on default in a small subset, use feature flags, or provide dual-support branches.

Communication templates

Announcement (email/Slack)Subject: New shared-library X — pilot available + migration guideBody: Hi all — I’m releasing shared-library X to centralize [capability]. Pilot repos: A,B,C. Docs: <link>. Benefits: smaller code, consistent behavior, security fixes. If you want help, book office hours: <link>. Migration checklist: <link>.

Migration PR offerHi @team, I can open a migration PR that adds X and updates one endpoint. Approve if you want me to proceed; I’ll include tests and CI changes.

Incentives- Time-savings: offer to land the first migration PR for adopters.- Visibility: highlight early adopters in weekly engineering newsletter and reward tokens/recognition.- Metrics: show reduction in duplicate code, fewer bugs, faster feature development tied to library use.

Metrics to track- Adoption rate (# repos using X)- Time to migrate per repo- Bugs fixed attributable to shared code- CI failures prevented

This approach balances technical safeguards (SemVer, shims, tests) with human factors (support, incentives, champions) and fallbacks (automated PRs, feature flags) to minimize disruption and drive adoption.

HardTechnical

98 practiced

What ethical considerations do you weigh when influencing decisions that impact user privacy, security, or data usage? Provide a concrete example where you navigated such trade-offs, who you consulted, and how you convinced stakeholders to follow a compliant, ethical path.

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.