Pushing Back on a Decision That Hurt Your Team: Process, Review and Delivery Impact

Tell me about a time when you pushed back against a decision that negatively impacted your team. What was the issue? How did it turn out? This was one of three behavioral questions in an onsite round, and the interviewer did not move on after the first answer. Five follow-ups came in a row, all about the process the decision changed: how it worked before, whether problems appeared after the team adopted the change, whether a human code review step remained, whether feature delivery got faster or slower, and what you would do differently today. Choose a story whose before-and-after process you can describe step by step. ```hint Choose a decision with a visible cost Pick a decision whose harm to the team you can state concretely, such as slower delivery, more incidents or wasted effort, so that your pushback rests on evidence rather than preference. ``` ```hint Rehearse the process, not the headline Expect to be asked exactly how the work flowed before and after the change, who reviewed what, and what you measured. Have those details ready. ``` ### Clarifying Questions - Does the decision need to come from someone above me, or does a decision by a peer team count? - Does a story count if my pushback did not change the decision, as long as I explain how I committed afterward? - How much detail do you want about the process itself, compared with how I handled the disagreement? ### What a Strong Answer Covers - A specific decision, who owned it, and a concrete or measured cost to the team - Understanding the goal behind the decision before arguing against it - Pushback raised with the owner directly, backed by data, and paired with an alternative that still met the owner's goal - A precise description of the process before and after the change that stays consistent under repeated follow-ups - A measured outcome including side effects, commitment to the final decision, and an honest account of what you would change ### Follow-up Questions - What did the process actually look like before the change? - After the team adopted the change, did anything go wrong, and was there still a human code review? - Did the change speed up or slow down feature delivery, and how do you know? - If you did it again today, what would you do differently?