"My developers aren't giving me feedback. They don't tell me anything unless I ask, and even then, it's sparse. I have an open-door policy, but they don't come to me. What's going on?" (From the video transcript)
We need to talk about this silence.
I remember a time when I felt like my developers were ghosts. They would come into meetings, nod politely, and then vanish without a trace of the insight I desperately needed. I knew they had thoughts—solutions, ideas, and fears—but getting them to share those seemed almost impossible.
I tried open-door policies, gentle encouragement, and even the classic "Feel free to reach out anytime." Yet, I was left with silence. 🤔 I want to share what I learned because maybe you’re feeling that same frustration.
Why the Silence?
"The ticket is defined by someone else. Someone who doesn't understand what the developers are doing."
The first time I truly began to understand the silence, it hit me like a punch to the gut. It wasn’t that my developers were avoiding me or that they just didn’t care. It was that they were afraid. They were scared of crossing deadlines drawn in ink by people who didn't know the complexity of the work.
Imagine this: You're a developer, and your work revolves around a ticket with a few vague acceptance criteria. You stare at it, knowing there’s an arbitrary deadline attached, knowing that, in essence, this is the "law."
No room for debate or negotiation, just the expectation that you must deliver—no matter the cost to quality or sanity. When that deadline is labeled as absolute, speaking up feels almost futile. Why would they risk rocking the boat when everything they’ve been given is designed to box them in?
They were running away from me because they felt I represented the machine pushing them to deliver—instead of the advocate I wanted to be.
Where the Problem Really Lies
"You as a manager need to connect two major worlds: the business world and the tech world."
Here’s the real truth that most of us in leadership positions don’t want to hear. I wasn’t connecting the dots. I was the bridge between two worlds, but I hadn’t built that bridge properly. I was standing between the business expectations and the developer's reality, but I hadn’t connected them in a way that allowed for honest communication.
In too many companies, these two worlds—business and tech—stay painfully separate. The developers feel like they’re working in a vacuum and are asked to churn out code to meet arbitrary dates. Meanwhile, the business side sees developers as elusive individuals who speak a different language, operating in an isolated bubble of "weird tech stuff."
This disconnect is what fosters the silence. Businesses don't understand the constraints, and developers feel trapped by them. Everyone loses. As a manager or CTO, your job isn’t just to lead people—it's to lead them towards understanding each other.
My Wake-Up Call – Remove Imperative Deadlines
"If you take shortcuts, it will become worse long-term."
The turning point for me was realizing that the pressure to meet deadlines, even at the cost of quality, was counterproductive. The more we enforced these "hard deadlines" without considering the nuances, the more we damaged the quality of our product—and, more importantly, the morale of our team.
I had to confront the truth: The anxiety around tickets, the fear of falling behind, and the refusal to speak up wasn't because developers lacked competence or interest—it was because we had made it unsafe for them to be honest.
I decided to change my approach. I began having open conversations about the realities of deadlines and expectations with my team and stakeholders. I explained that the shortcut might save us a few days now but would cost us months in lost quality, technical debt, and developer burnout.
Things started to change when I demonstrated that I could push back on unrealistic deadlines—when I proved that I would advocate for my team rather than simply transmit orders.
The Results of Real Change
"Your developers will fix that as fast as they can, even if it means over hours at that moment—because they have ownership."
Slowly, the silence broke. It wasn’t a sudden flood but rather a series of small moments. One by one, developers began to open up. They shared their fears about unclear requirements and unrealistic timelines. They brought ideas about how to make the software more efficient or user-friendly. They told me what was working and what wasn’t.
And the most potent change of all? They started coming to me before problems spiraled out of control. When you create an environment where people feel safe to say, "I think we might miss this deadline," you empower them to take ownership of their work. They stop being "quiet developers" and start being the active professionals they want to be.
Key Takeaways
Create a Safe Environment for Honest Conversations: Make it clear that missing a deadline isn’t the end of the world—it's a sign we need to adjust and adapt.
Bridge the Gap Between Business and Tech: The development team and the business must understand each other. It’s your job to facilitate that understanding.
Advocate for Your Team: Be ready to push back on unrealistic expectations. Show your developers that their work—and their well-being—matters.
Shift from Managing to Leading: Management is about enforcing policies; leadership is about inspiring change and guiding people toward a shared goal.
Encourage Ownership Through Trust: When developers see that you trust them, they are more likely to take ownership and go the extra mile when needed.
What About You? 🫵
Have you ever experienced a disconnect between your developers and your business? How did you tackle it, or are you still struggling with it? Let me know—I'd love to hear your experiences and insights.
Why are my devs always so quiet?