I learned this lesson during a heated debate about our next-generation technology platform when everyone wanted me to pick a side immediately.
Our company was planning a major technology modernization, and two competing approaches had emerged. The development team strongly advocated for a cloud-native microservices architecture that would provide maximum flexibility and scalability. The operations team pushed for a hybrid approach that would minimize disruption to existing systems while gradually introducing modern components.
Both sides had compelling arguments. The cloud-native approach promised better performance, easier maintenance, and future-proofing against technology changes. The hybrid approach offered lower risk, faster initial implementation, and preservation of stable system components that were working well.
During a crucial architecture review meeting, the CTO asked me directly: “Eric, you’ve analyzed both approaches thoroughly. Which direction should we go?” The room went quiet. The development lead, operations manager, and several other stakeholders were all looking at me. The pressure to take a decisive position was intense.
My instinct was to give a clear answer. To demonstrate leadership by taking a strong stance based on my technical analysis. But something made me pause. I realized that committing immediately would close more doors than it would open.
“I want to understand the full business context before making a recommendation,” I said. “Both approaches have significant technical merit. Let me gather more information about implementation timelines, resource availability, and business priorities before weighing in definitively.”
Some people seemed frustrated by my non-commitment. But over the next two weeks, interesting information emerged. The development team revealed concerns about the operations team’s capacity to manage a complex hybrid architecture. The operations team admitted they were worried about supporting unfamiliar cloud-native technologies. The finance department shared budget constraints that hadn’t been discussed in the technical meetings.
Because I hadn’t committed early, both sides continued sharing information with me. They tried to win me over by revealing their real priorities, concerns, and backup plans. I learned about political dynamics, resource constraints, and timeline pressures that weren’t visible during the initial technical presentations.
When I finally made my recommendation, a phased approach that started with hybrid implementation but built toward cloud-native architecture, it was based on far more complete information than I’d had during the original meeting. More importantly, I was able to position it as a synthesis that addressed both teams’ core concerns rather than choosing one side over the other.
That experience taught me: smart people keep optionality. The most powerful position is often the one that preserves the most possibilities for creating the outcomes you actually want.