Over the last few years, I’ve noticed a pattern in team discussions that keeps coming back - especially when the problems get hard. Someone asks, “Do we build this as a distributed system or keep it monolithic?” And someone replies, "It depends."
But depends on what, exactly? On performance? On operational overhead? On whether the team can actually debug distributed systems at 3 a.m.?
Most of the time, nobody answers. The phrase just floats there — a way to sound thoughtful without committing to anything. It feels safe. Mature. Neutral. But in reality, “it depends” often isn’t wisdom. It’s fear.
#Fear of being wrong
#Fear of taking responsibility
#Fear of leading when things are uncertain.
Strong engineers know how to analyze trade-offs. Great engineers know when to stop analyzing and take a stand. I saw this characteristic in great CTOs I have worked with.
#When You Don’t Decide, You Still Decide
Eventually, you find yourself in a room where you have the most technical context — maybe you know the system best, or you’ve debugged the last three outages. And then a question lands on the table, and everyone turns toward you.
If you shrug it off or stay quiet, you’re not being neutral — you’re silently approving whatever comes next. Someone will fill the void. And sometimes, it’s the loudest or least experienced voice that wins by default.
I’ve learned that taking a stance isn’t about ego or certainty — it’s about protecting the team from randomness. You don’t need to be 100% sure. Sometimes 60% confidence and a clear direction move a project further than endless debate ever could.
#Why It’s So Hard to Commit
If I’m honest, I understand exactly why engineers avoid commitment. I’ve done it too.
It’s not fun to be wrong in public. You feel exposed. You replay the meeting in your head afterward, picking apart every word you said. You think, “If I’d just stayed quiet, I wouldn’t have looked stupid.”
That kind of regret leaves a mark. So we learn to hedge — to speak in safe phrases like “it depends,” “maybe,” or “we could explore both.” It feels like being thoughtful, balanced, even diplomatic. But often, it’s just fear dressed up as caution.
The deeper truth is this: commitment feels risky because it forces ownership. The moment you say, “Let’s go with option A,” the outcome — good or bad — becomes tied to your name. And that’s heavy. Especially in engineering, where the cost of a wrong call can echo through weeks of work.
But leadership doesn’t come from perfect calls — it comes from owning imperfect ones. The teams you respect most don’t follow people who are always right. They follow the ones who are willing to choose, to explain their reasoning clearly, and to adjust when new data arrives.
People don’t expect certainty from you. They expect direction. If you’re the person with the clearest sense of the trade-offs, your role isn’t to wait for consensus — it’s to create momentum. Sometimes that means saying, “Let’s move forward on A for now — here’s why Point A, B and C, and here’s what would make me change my mind.”
That’s not arrogance. That’s what responsible technical leadership looks like: clarity with humility.
#Where I’m Trying to Get Better
I’m not writing this because I’ve mastered it — I’m writing it because I’ve started to understand what mastering it looks like.
I’m learning to take a position earlier, even when the data isn’t perfect. To say, “Here’s my take — let’s pressure-test it,” instead of hiding behind “It depends.”. To treat being wrong as part of the process — a signal to adjust, not a verdict on my ability.
Leadership doesn’t start with a title. It starts the moment you’re willing to give direction when others hesitate — when you carry uncertainty with composure, and invite your team to move forward anyway.
That’s the habit I’m trying to build — taking ownership a little earlier, even when it’s uncomfortable.
#Closing Thought
If you’re the person in the room with the most context, people are looking to you — whether you realize it or not.
#Silence still is a decision and uncertainty is part of the job.
#Progress — in code, in teams — starts the moment you commit.
It’s not about being fearless; it’s about acting despite the uncertainty. Strong engineers don’t wait for perfect information — they create momentum and adjust along the way.
Because in the end, leadership isn’t about always being right. It’s about moving first, learning fast, and helping others move with you.