What specific conversations did you have and with whom?
How did you balance being supportive of your teammate while addressing team dynamics?
What concrete steps did you take to help bridge the gap?
How did you approach sensitive conversations with other team members or leadership?
How did the teammate's experience improve?
What was the impact on team dynamics and productivity?
What feedback did you receive from the teammate or others?
What did you learn about advocacy and team inclusion?
Sample Answer (Junior / New Grad) Situation: During my internship at a fintech startup, we had a new engineer join our six-person team who had just moved from another country. I noticed over the first few weeks that he was very quiet in stand-ups and would often eat lunch alone. His code reviews were getting slower responses than usual, and I could tell he seemed uncertain about asking questions in our team Slack channel.
Task: While I was just an intern myself, I felt someone needed to help him connect with the team since we all benefit from having everyone engaged and comfortable. I realized that if he continued feeling isolated, it would affect both his work quality and his experience, and as someone who had been new just a few months earlier, I remembered how important it was to have allies.
Action: I started by inviting him to join me and another junior engineer for lunch, making it a casual invitation so he wouldn't feel pressured. During lunch, I learned he was hesitant to speak up because he wasn't sure if his English was clear enough and worried about asking "obvious" questions. I shared my own early struggles and normalized asking questions by being more vocal about my own uncertainties in team meetings. I also mentioned to our team lead in a one-on-one that it might help to explicitly encourage questions during stand-ups since some people were hesitant to interrupt. Finally, I made a point to respond quickly and encouragingly to his pull requests and Slack questions to show support.
Result: Within a month, I noticed he was participating more actively in meetings and had even started suggesting improvements to our testing process. He told me privately that having someone reach out made a huge difference in his confidence. Our team lead thanked me for raising the point about creating space for questions, and the team became more intentional about making time for discussion. I learned that advocacy doesn't require seniority—it just requires noticing when someone needs support and taking small, consistent actions to help them succeed.
Sample Answer (Mid-Level) Situation: I was working on a cross-functional product team when we hired a talented designer who came from a very different work culture—a formal corporate environment versus our fast-paced, casual startup. After about six weeks, I noticed she was being left out of key informal discussions that happened in Slack threads and hallway conversations, and her design proposals were being challenged more aggressively than seemed warranted. In our retrospective, she barely spoke, and I could see she seemed frustrated and withdrawn.
Task: As the engineering lead who partnered closely with the design team, I felt responsible for ensuring our collaboration was effective and that all team members could do their best work. I needed to address both the immediate issue of her feeling excluded and the broader team culture that wasn't making space for different communication styles. The risk was losing a strong hire and perpetuating an environment where only certain personalities thrived.
Action: I first had a private conversation with her over coffee to understand her perspective, where she shared that the constant informal decision-making made her feel like important choices happened without her input, and that the direct challenges to her work felt personal rather than constructive. I then spoke individually with our product manager and two senior engineers about how our informal communication style might be excluding her, providing specific examples without naming names. I proposed we document key decisions in our project wiki and ensure design reviews had clear agendas with time for thoughtful critique. I also advocated in our team meeting for establishing "office hours" where anyone could bring questions or concerns, which created more structured touchpoints. Additionally, I made sure to explicitly pull her into relevant discussions and publicly acknowledged her contributions during team meetings.
Result: The changes we implemented helped significantly—our documentation improved, which benefited everyone, and the structured design reviews led to more thoughtful feedback across the board. She told me three months later that she finally felt like a valued team member and was no longer considering leaving. Our team's design-engineering collaboration scores in the quarterly survey increased by 35%, and the product manager noted that we were making better decisions because we were incorporating more diverse viewpoints. I learned that advocacy often means not just supporting an individual but also helping the team evolve its norms to be more inclusive, which ultimately makes everyone more effective.
Common Mistakes
- Staying silent -- Noticing someone struggling but not taking action, waiting for someone else to step in
- Only raising concerns privately -- Failing to advocate publicly when appropriate, which limits the impact of your support
- Making it about you -- Centering your own discomfort or heroism rather than the teammate's experience and needs
- No specific actions -- Saying you "supported" someone without describing concrete steps you took to advocate for them
- Ignoring systemic issues -- Treating the situation as only an individual problem without recognizing broader team or cultural dynamics
- No follow-through -- Advocating once but not continuing to check in or ensure lasting change occurred
- Missing the outcome -- Not explaining how the teammate's situation improved or what impact your advocacy had
Result: The changes we implemented helped significantly—our documentation improved, which benefited everyone, and the structured design reviews led to more thoughtful feedback across the board. She told me three months later that she finally felt like a valued team member and was no longer considering leaving. Our team's design-engineering collaboration scores in the quarterly survey increased by 35%, and the product manager noted that we were making better decisions because we were incorporating more diverse viewpoints. I learned that advocacy often means not just supporting an individual but also helping the team evolve its norms to be more inclusive, which ultimately makes everyone more effective.
Result: Over the next quarter, perceptions shifted significantly. Her risk assessment framework was adopted and refined by the team, reducing our P1 incidents by 40% while only adding two days to typical project timelines. Team members who had been skeptical began actively seeking her input on complex changes, and her tech lead acknowledged that his initial judgment had been too hasty. She was promoted to staff engineer 18 months later and became a mentor for new senior hires. The incident taught me that effective advocacy means creating concrete opportunities for someone to demonstrate value while also challenging team assumptions—sometimes the person who doesn't fit the mold is exactly what the team needs to level up. It also reinforced that as leaders, we need to actively question whether our "culture" is actually just comfort with homogeneity.
Result: Within one quarter, attendance at architecture forums became 40% more diverse, and the quality of technical decisions improved as more perspectives were included. All three engineers I'd initially noticed successfully leveled up within 12 months, with one becoming a tech lead and another driving a company-wide platform migration. The structural changes we implemented became part of our standard engineering practices and were explicitly called out in our next engagement survey as positive changes, with our inclusion scores increasing by 25 points. The VP asked me to scale this work across product and data organizations, which influenced over 200 engineers. Most importantly, I learned that staff-level advocacy means changing systems, not just supporting individuals—true inclusion requires deliberately designing processes that counteract natural biases and network effects, and leaders must use their privilege and platform to make those changes even when it's uncomfortable.
I started by having an in-depth conversation with her about how decision-making autonomy worked on our team and what "senior" meant in our context, while also validating that her thoroughness was a strength we needed. I worked with her to identify two upcoming projects where her detailed approach would be particularly valuable, positioning her as the technical lead. Simultaneously, I had candid conversations with her tech lead and peer senior engineers about unconscious bias—were we dismissing her ideas because they challenged our assumptions, or because they genuinely weren't strong? I shared data showing that our incident rate had increased as we'd grown faster, suggesting we actually needed more rigorous review. I facilitated a team discussion about balancing speed with thoughtfulness, where I had her present a lightweight proposal for risk assessment on major changes. I also publicly recognized her contributions in team forums, specifically calling out how her careful analysis had prevented a major production issue.1f