confidence in tech > talent in tech
I’ve noticed that the confident engineer with average skills performs better. This isn’t a cheesy "believe in yourself" saying. It’s about how people do tech work in companies that make software.
I've watched this play out across dozens of teams. The engineer who asks questions first in meetings, or says "I can handle it", usually gets promoted. They become the person other engineers turn to when something breaks.
Meanwhile, the super smart engineer stays quiet in meetings. They think about problems and spot three edge cases that might go wrong. They're right about the edge cases. But by the time they formulated concerns, the confident engineer has already started coding.
This happens because confidence signals competence in ways that actual competence doesn't. When your staff engineer says "I'll check it" right away, it shows they can handle it, even if they are googling all things up. When your smart junior says "I’m not sure if this is right", it sounds unsure, even if their solution is actually good.
The confident engineer understands a key: being 80% right with 95% confidence beats being 95% right with 80% confidence. They make architectural choices that move the team forward, even if it's not perfect. They understand that in most cases, the cost of delay exceeds the cost of imperfection.
I've seen this dynamic destroy careers. The engineer can solve any coding puzzle. But they take three days to review a pull request because they think about every possible improvement. The senior developer writes careful, great code. But they never try to lead because they don’t feel ready. The architect spots every problem in every design. But they have trouble suggesting fixes because they are never happy with their own ideas.
The tragedy isn't that these engineers lack talent. It's that they've optimized for being right instead of being effective. They've confused perfectionism with professionalism.
The confident engineer has learned a different lesson. They understand that most technical solutions are reversible. Most code can be refactored, and most mistakes can be fixed. They know that making progress is more important than being perfect. This is true especially when things change every week and the product can change every few months.
This doesn't mean confidence excuses incompetence. The engineer who confidently ships broken code won't last long. But there's a sweet spot where average skills combined with high confidence creates outsized impact. These engineers keep the team together. They say "yes, we can build that" while others explain why it is hard.
The market rewards this combination because shipping is the ultimate skill. Companies don't pay engineers to write perfect code. They pay them to solve problems, make decisions, and move products forward. The engineer who can do this confidently, even imperfectly, creates more value than the engineer who can do it perfectly but slowly.
I've learned to hire for this quality as much as technical skill. The knowledge gap closes with time and mentorship. The confidence gap rarely closes on its own.
If you liked this post, hit the like button. It's the best feedback I could get.
Until next time,
Adlet
Connect with me on LinkedIn, just use the button below. I read every message. Cheers!