STAR method example: disagreeing with a senior colleague

Situation: A senior engineer wanted to use technology A, but I thought technology B was better for our project.

Task: I needed to share my opinion respectfully and find the best solution.

Action: I wrote a comparison document with advantages and disadvantages of both options. I asked the senior engineer to review it together. We discussed each point calmly.

Result: We agreed on a mixed approach. The senior engineer thanked me for the analysis, and the project was successful.

Situation: During the design phase of our new authentication service, our principal engineer advocated for building a custom JWT implementation, while I believed we should use an established identity provider.

Task: I needed to express my technical disagreement constructively without damaging our working relationship or appearing to challenge their authority.

Action: I framed the discussion around risk rather than preferences. I prepared a comparison matrix covering security implications, maintenance burden, and time-to-market. I acknowledged the valid points of the custom approach and suggested we evaluate both options against our specific requirements in a time-boxed spike.

Result: The spike revealed that the custom implementation would require 3x the ongoing maintenance. We adopted the identity provider, and my principal engineer appreciated the evidence-based approach. This established a pattern of data-driven architecture decisions in our team.

Situation: Our VP of Engineering championed a complete rewrite of our data pipeline from Python to Go for performance reasons. My analysis suggested the bottleneck was architectural — specifically, our synchronous batch processing model — not language-related, and a rewrite would consume six months without addressing the fundamental issue.

Task: I needed to redirect a decision that had significant organizational momentum behind it without appearing insubordinate or dismissive of legitimate performance concerns.

Action: I validated the performance concern first, then reframed the conversation from "which language" to "which architecture." I built two prototypes: the existing Python pipeline refactored to use async stream processing, and a simplified Go version maintaining the current architecture. The benchmarks showed the architectural change delivered 15x throughput improvement regardless of language, while the Go rewrite alone only achieved 2x.

Result: We refactored the architecture in Python, achieving 18x throughput improvement in eight weeks versus the projected six months for the rewrite. The VP became an advocate for "benchmark before rewrite" as a team principle, and I was asked to present the case study at our engineering all-hands.