Describe a time when you had to sell a technical idea to skeptical stakeholders.

Situation: I proposed migrating our main application to a new cloud region to reduce latency for our APAC customers. The product and finance teams were skeptical—they saw cost, risk, and disruption with no guaranteed revenue lift. I was the engineering manager making the case.

Task: I had to sell a technical initiative to stakeholders who didn't see the value and were worried about the downside.

Action: I started by understanding their concerns. In 1:1s, I heard: "What if something breaks?" "How much will this cost?" "Can't we just optimize the current setup?" I tailored my pitch to each. For product, I framed it as customer experience—we had support tickets and NPS data showing APAC users experienced 2–3x higher latency. For finance, I built a cost model: the migration would cost X one-time and Y ongoing, but we'd avoid Z in potential churn (I used conservative estimates from our data team). For risk, I proposed a phased rollout: read replicas first, then gradual traffic shift, with rollback plans. I also ran a two-week pilot in a non-critical service to prove we could do it safely. I brought proof: latency metrics from the pilot, a case study from a similar company. When they pushed back on timeline, I offered a compromise: we could do it in 12 weeks instead of 8 if we deferred a lower-priority project.

Result: We got approval. We executed the migration with zero incidents. APAC latency dropped by 60%, and we saw a 4% improvement in APAC retention over the next quarter. I learned that selling technical ideas requires listening first, addressing each stakeholder's concerns specifically, and backing claims with evidence—and that pilots and phased approaches reduce perceived risk.