Behavioral interview questions on influence without authority

As a senior engineer on the platform team, I wanted two product feature teams to adopt a shared API gateway instead of each building their own service-to-service calls. I had no authority over either team's roadmap. I started by building a small proof-of-concept showing latency and observability improvements on one of their existing endpoints, then I scheduled a 30-minute demo with each team's tech lead, framing the benefit in terms of their own on-call burden and upcoming compliance requirements. One team adopted it within the quarter; the other agreed to a pilot in their next sprint. The outcome was that one service migrated fully and reduced p99 latency by about 15%, and the second team ran a successful pilot that led to broader adoption over the following two quarters. In hindsight, I wish I had involved the resistant team's engineering manager earlier — I focused on peer-level persuasion and lost a month to a priority conflict I didn't see coming. That taught me to map the decision-makers, not just the technical peers, when influencing across teams.

Situation. My team split hard on whether to rewrite a flaky payments service or refactor it incrementally; the debate had stalled two sprints. Task. I had to get a decision the whole team would actually execute, not just tolerate. Action. I ran a 90-minute session where I made each camp argue the other side's strongest case, then we wrote down the three criteria we actually cared about — incident rate, time-to-first-value, and rollback safety. Scored against those, incremental refactor won on two of three. I wrote a one-page decision doc naming the dissent and the conditions under which we'd revisit. Result. We shipped the refactor; incidents fell 60% in two months and the rewrite advocates later told me the criteria made the call feel fair. Reflection. Forcing the criteria before the options was the unlock — I now do that earlier.

Situation. Our onboarding for new hires was painful — everyone complained, but it was no one's job to fix, and I had no mandate to. Task. I wanted to fix it but knew I couldn't do it alone or by decree. Action. I started tiny: I fixed the single worst step (a broken local-setup script) for myself, then wrote up the before/after and shared it. That concrete win got two peers to each adopt one painful step. I made joining easy — a shared doc with claimable items — and I publicly credited every contributor in our team channel and in their own write-ups. When a new hire onboarded smoothly using our changes, I had them share the experience, which pulled in more volunteers. Result. Over two months, eight engineers chipped in; new-hire time-to-first-PR dropped from ~9 days to 3. It later became an official, owned process — but it started as a volunteer effort. Reflection. The momentum came from small visible wins and giving everyone credit; people opt in when contributing is easy and they're seen for it.

Situation. I recommended we migrate off a deprecated payment SDK before it lost vendor support in four months; our PM pushed back because it was a full sprint with zero visible customer feature. Task. I needed her to fund it without being able to point to anything she could demo. Action. I gave her enough technical grounding to trust the risk was real, not hypothetical: the vendor's own deprecation notice, and a two-line explanation of why a hotfix wouldn't be possible once support ended (no patched builds, so any bug becomes permanent). Then I translated that into her terms: hitting a payment bug after the deadline with no fix path is an unplanned, unbounded incident during a quarter she couldn't predict, versus one scheduled sprint now. Her specific objection was 'why now and not next quarter' — I addressed that directly by showing the vendor's exact support cutoff date landed inside next quarter's roadmap window, so waiting wasn't actually free. I offered to shrink the ask to half a sprint by migrating only the two payment flows actually at risk, deferring the rest. Result. She approved the half-sprint scoped version, we hit the vendor's cutoff with two weeks to spare, and no payment incident occurred. Reflection. Giving her just enough of the technical 'why' to make the risk feel concrete, then answering her actual timing objection instead of re-pitching, is what moved her — a pure business pitch with no mechanism would have felt like I was hiding something.

Situation. Five product teams each hand-rolled auth against our gateway, causing three security incidents in a quarter; I had no authority over any of them. Task. I wanted all five on a shared auth SDK without a mandate. Action. I built the SDK plus a one-command migration script, then met each team lead 1:1 and framed it against their roadmap — for the team drowning in on-call, I led with the incident reduction; for the team shipping a launch, I offered to do the migration PR myself. I published a live adoption dashboard so progress was visible to their directors. Result. Four of five teams migrated in six weeks, the fifth within the quarter; auth incidents dropped to zero over the next two quarters and the SDK became the default for new services. Reflection. I under-weighted the team mid-launch — next time I'd sequence around release calendars from day one.

Situation. Our VP wanted to buy a third-party search vendor on a tight deadline; I believed it would lock us into costs that scaled badly with our data growth. Task. I had one meeting to either change the direction or get on board. Action. Rather than argue philosophy, I modeled three-year cost under our actual growth curve, prototyped the in-house option over a weekend to prove feasibility, and presented both as a one-pager with a clear recommendation and the risks of mine. I explicitly said I'd commit either way. Result. The VP paused the purchase, we built in-house, and at our scale 18 months later it was saving roughly $400k/year versus the quoted contract. Reflection. Leading with their frame — cost and risk, not engineering taste — was what got me heard.

Situation. Our flaky CI was costing every team hours a week, but it sat between platform (who owned the runners) and each product team (who owned their tests), so nobody owned the flakiness itself. Task. No one asked me to fix it; as a staff engineer I judged the org-wide drag was worth picking up. Action. I instrumented a week of CI to quantify it — 18% of runs failed on flakes, ~40 engineer-hours/week lost — and turned that into a one-page case. I didn't try to fix it alone: I proposed a rotating 'CI health' owner with a clear charter, recruited one engineer from each of the three worst teams, and defined a flake-quarantine policy so a flaky test got auto-disabled and ticketed rather than blocking everyone. I drove the first month myself, then handed the rotation off. Result. Flake-failure rate dropped from 18% to under 3% in two months, the rotation outlived my involvement, and the quantification became how we now justify platform investment. Reflection. The trap was becoming the permanent owner; building the rotation and charter before I stepped back was what made it stick without me.

Situation. Two teams were independently building notification systems — one for transactional emails, one for in-app alerts — and each was about to build its own templating, scheduling, and delivery-tracking layer. Task. I had authority over neither team but could see we were weeks from maintaining two near-identical platforms. Action. I got both leads in a room and reframed it as one shared capability, not a turf question. We agreed on three neutral criteria — delivery reliability, time-to-add-a-channel, and on-call burden — before discussing whose code to keep. Scored against those, one team's delivery layer was stronger and the other's templating was; so I proposed a merged platform that took the best of each and a clear split of who owned which half going forward. I wrote the joint plan and had both leads co-sign it. Result. We shipped one platform instead of two, saved an estimated quarter of duplicated work, and both teams contributed, so neither felt steamrolled. It became the org's notification backbone. Reflection. Agreeing the criteria before looking at the code is what stopped it from becoming a 'whose baby wins' fight — both teams could see the call was fair.

Situation. Every team rolled their own structured-logging format, so cross-service debugging meant grepping five incompatible log shapes. I wanted one standard but had no power to require it. Task. Make a shared logging library the obvious default without a mandate. Action. I led with friction-removal: the library was a drop-in replacement that also gave teams free trace-correlation and a prebuilt dashboard they'd otherwise have to build. I migrated the two highest-traffic services myself so the dashboard had immediate, visible value, then demoed cross-service tracing in an incident review where it had just saved an hour. I made adoption a 15-minute change and wrote the migration so teams kept their existing log calls. I never asked a manager to push it. Result. Seven of eight teams adopted within a quarter, pulled by the tracing benefit; the eighth, a legacy team, adopted six months later when they rewrote their service. It's now the default for new services. Reflection. Adoption happened because the new way was strictly easier and gave something teams wanted — influence here was really about making the right thing the lazy thing.

Situation. Our monolith's test suite took 40 minutes and was so flaky teams had started skipping it; I believed we needed a serious testing-infrastructure investment, but leadership saw only 'internal plumbing' with no customer feature attached. Task. As a staff engineer I had to get real funding — engineers and time — for something that wouldn't ship a single visible feature. Action. I made the cost of inaction concrete: I tracked that flaky-test reruns and skip-related bugs were costing roughly an engineer-month per quarter and had caused two customer-facing regressions that quarter. I framed it in the VP's terms — delivery predictability and customer-incident rate, the two things she was measured on — not in test-coverage language. Crucially, I de-risked the ask: rather than request a quarter, I asked for two engineers for three weeks to fix the worst third and prove the payoff, with a clear before/after metric. I got the platform lead on side first so it wasn't a lone voice. Result. The three-week pilot cut suite time to 12 minutes and flakiness by 70%, which made the full investment an easy yes; over the next two quarters customer-facing regressions from this class dropped to near zero. Reflection. Leadership wasn't being short-sighted — a pure 'invest in tests' pitch is unfundable. Quantifying inaction in their metrics and asking for a small, provable first bet is what turned a no into a yes.