I learned this lesson during a critical system redesign when staying quiet would have been disastrous.
My director had decided to migrate our entire platform to a microservices architecture within six months. The decision came down from senior leadership, and he was enthusiastic about the modern approach and the performance benefits it would deliver. He’d already communicated the timeline to stakeholders and begun planning resource allocation.
But I could see problems he couldn’t. I’d spent three years working intimately with our current system architecture. I knew where the coupling was tight, where the data flows were complex, and which services couldn’t be easily separated. I understood the technical debt we’d accumulated and the integration challenges we’d face.
From my technical perspective, a six-month timeline was impossible. We’d need at least twelve months to untangle the dependencies safely, and even then, we’d need to phase the migration carefully to avoid downtime. Rushing would likely result in system instability, data inconsistency, and potentially catastrophic failures.
But he was my director. He had more experience in management, more visibility into organizational priorities, and more pressure from above to deliver results quickly. Who was I to question his technical judgment?
So I stayed quiet. I complained to my peers about the unrealistic timeline and worked around the obvious problems. I hoped someone else would speak up or that he’d realize the issues himself as we got deeper into planning.
Three weeks into the project, we hit our first major roadblock. The customer database couldn’t be easily separated from the inventory system without rewriting significant portions of both. What should have been a two-week separation task became a month-long refactoring project.
Feedback
Finally, I requested a private meeting. “I have some concerns about our migration timeline based on what I’m seeing in the technical analysis. Would you be open to hearing my perspective?”
That conversation changed everything. I walked him through the specific technical dependencies I’d discovered, the integration challenges we were facing, and the realistic timeline based on the actual architecture complexity. He listened, asked clarifying questions, and ultimately revised the project timeline and approach.
Later, he told me he wished I’d spoken up earlier. “I was working with assumptions about our system architecture that weren’t accurate,” he said. “You had information I needed to make better decisions.”
That experience taught me: providing upward feedback isn’t about challenging authority. It’s about contributing valuable information that leads to better outcomes for everyone.