Tell Me About a Time You Convinced Others to Support Your Idea

Purpose of the Question

Tech companies are competitive, disruptive, and fast-moving. It can be difficult to keep everyone on board, and disagreements happen. Communication skills are essential to working effectively with co-workers, higher-ups, and external stakeholders.

Interviewers want to see:

• Strong listening skills. Can you identify the right information, seek it out, and listen without bias?
• Adaptive communication. Do you “know your audience”? Do you tailor your message as needed?
• Logic, clarity, honesty, and respect. Can you construct a logical argument and communicate it clearly? Are you honest, and respectful to all of those around you? Even those who disagree?

Preparing Your Answer

FAANG companies value innovation, experimentation, and the ability to fail fast.

If you believe everyone on your team is striving towards the team's and the organization's goals (as I do), any initiative that has merit should be welcomed. However, there may be resistance due to misaligned priorities or uncertainty.

In order to overcome resistance and to convince others to support your initiative, I’ve found that writing down a proposal helps clarify my thoughts, and produces something shareable and concrete. Once shared, you can gather feedback.

Try to include these points in your proposal:

• An “executive summary”, giving an overview of the initiative (what are we trying to achieve?)
• The current state (how are things done now?)
• Clearly defined customer (who is the customer? What is the problem / opportunity?)
• Customer benefit (how will this serve my customer?)
• Validation / evidence for the need to solve this particular problem. (sometimes known as “voice of the customer.”)

Tip: for any customer-centric company, VOCs are highly important - they serve as a foundation for decisions on what must change or be improved.

• Clearly defined vision for success and the entire customer journey (what will things look like if the initiative is a success?)
• Example solutions (multiple possibilities are ideal in the early stages; you can decide after gathering feedback.)
• Data points planning / justifying each stage of the proposal.
• Success metrics (how will we know we’re on track?)
• Associated cost and timelines.

Once your proposal is complete, share it with some trusted colleagues or your boss for feedback. Once done, present it to relevant stakeholders, address any feedback they may have, and request their endorsement.

Let’s look at an example of this process in action.

Example Answer

In my previous position as a technical account manager (TAM) for the open API business for a FAANG company, we exposed APIs for third-party developers, including tool providers and agencies from all over the world. These developers were creating applications with APIs to address customer requirements. External developers communicated with the open API business team via support tickets about any bugs, suggestions, and recommendations.

One day, an external developer went on LinkedIn to share his issue with an API and seek advice on what fellow developers thought about it. This wasn’t unusual; in the world of APIs, where the API specification defines all standards, developers want to know how their peers are using it, what sort of problems others are experiencing, and whether or not their understanding of the API is correct overall.

I took a step back after seeing this query on LinkedIn and did some research to find out why this external developer had posted there of all places. I discovered that for questions like theirs, developers prefer not to file tickets and wait for a response from a support team. They want to communicate with one another to share knowledge and get deep answers to technical questions.

After doing research, I had drawn the conclusion that we had two problems:

• Traditional support systems are not scalable and have slow response times. We’d accepted this as a reality.
• We don't have a platform that enables external developers to collaborate; therefore developers have to work harder to learn about the API and answer technical questions.

In order to address these two problems, I came up with the notion of a developer community and wrote a proposal outlining the community.

I included the customer's voice and data points that clearly show the API support team's slow response time, and I explained the benefits of the developer community. For example:

• An obvious benefit of a thriving developer community is a wider reach for your API. We could easily improve brand image and awareness.
• By leveraging the expertise of the community, developers can share tips and tricks in forums and even add code samples to make it easy for others to get started quickly with your API. Community leaders can share general best practices, write thought leadership articles, and share information on product releases and release notes.
• Internally, we can reduce developer support costs by offsetting workload via the community. This leads to faster/easier improvements to existing products by quickly identifying errors, and also helps shape the development of new products.
• Finally, a valuable benefit of the community that is sometimes overlooked is that the greater the number of developers using your API, the faster bugs and issues will be identified and communicated so that you can continue to improve the value of your API.

I included a storyline that demonstrates how participants will use this community, and I ended the document by outlining how I will evaluate the developer community's success.

• Developer Support: % reduction in support tickets.
• Ideas exchanged: Number of discussions created, number of new ideas from the community.
• Product feedback: Number of positive reactions, number of ideas that have been used for product/ service development.
• User-generated content: Number of articles created by developers, amount of traffic driven by articles created by developers, total unique visitors to the community, total community page views.

I discussed this proposal with the leadership, answered their concerns, convinced them, and implemented the developer community.

Interviewer: Sorry to interrupt - would you take a moment to tell me more about leadership’s concerns, and how you addressed those?

Of course. The merit of the idea was fairly well agreed upon, but there were questions as to which platform to use to implement a developer community.

To persuade the leadership, I conducted a comparison study of available options (such as reddit) vs. a stand-alone platform for this purpose, vs.GitHub. I compared these options based on a few factors such as cost, time to build, and accessibility. On these criteria, GitHub was an obvious choice.

Another question that came up was how to handle moderation. I pitched a “community moderator” role to leadership with the goal of moderating the API Community, and I listed some of their responsibilities. For example:

• Keep an eye on new posts and make sure to welcome new members.
• Be active in the community and help answer questions.
• Encourage members to be respectful and helpful to each other.
• Promote helpful and popular content.
• Keep the community organized and tidy.

Have I answered your questions?

Interviewer: Yes, thank you.

Great. We saw great results from this project. We've had a thriving developer community running on GitHub for the last three months. Here are a few details I can share:

• More than 1000 threads have been created in 3 months; 75% of the interaction was led by external developers!
• We've seen than 100 articles shared including blogs, problems, and new ideas and implementations of the API.
• We also saw a 30% reduction in support team tickets.

Bonus: Follow-up Questions

Question 1: What feedback did you receive on your proposal?

Although it was well received, some folks questioned where and how I would introduce the developer community. In response, I reiterated the goals, mapped alternative platforms to goals, discussed tradeoffs associated with each, and got everybody's OK to build a developer community on GitHub.

Question 2: Did you learn anything from this decision? How will you overcome resistance to ideas in the future?

Yes, certainly. One way I’ve found to overcome resistance is to focus on the benefits of the idea, specifically as to how it helps the team achieve its goals. Another important piece is to get input from the team members early and often and make sure that their concerns are addressed. Finally, it is important to be flexible and willing to make changes based on feedback from the team.