Blog

The relationship between confidence and arrogance in the tech industry is bizarre. When a founder confidently states that their new app will “revolutionize society,” we applaud. Yet we’ve all sat in a meeting listening to an engineer confidently explain how their new framework solves every known tech problem, and we roll our eyes.

If you’re like me, you sit somewhere between those extremes. You’re grounded enough to accept that your app is not going to change the world, but you have a sinking suspicion that you’re not qualified to be on the team in the first place.

Welcome to imposter syndrome, which is everywhere in tech. Yet despite how common it is, we don’t talk about it enough (or at all).

From a systems standpoint, it’s easy to see. We work with complex systems that constantly change. Yesterday’s best practice is today’s technical debt. The learning curve never flattens out, and when things break, they often break publicly and loudly.

Given this environment, it’s no surprise that imposter syndrome is rampant in tech. Unfortunately, the industry’s typical response to that doubt is to demand performance art instead of competence.

The Cost of the Mask

I’ve been in countless meetings where technical leadership felt more like a test of dominance than a discussion of trade-offs. The culture often conflates technical skill with intelligence, and uncertainty with weakness. If you admit you don’t know how something works, you risk losing credibility.

Because of this, imposter syndrome creates a distorted relationship with confidence. When you fundamentally doubt your own competence, confidence feels like a mask you put on. This performance anxiety manifests in two predictable, and equally destructive, paths.

The first is overcompensation. People swing so far away from their insecurity that they adopt an aggressive, know-it-all persona. They interrupt in meetings, dismiss alternative ideas out of hand, and speak with absolute certainty about topics they barely understand. I’ve seen projects derailed for months because a senior engineer was too insecure to admit they didn’t know how to configure the database properly, and so they invented elaborate excuses for why the chosen database was actually fundamentally flawed.

The second path is withdrawal. The fear of being “found out” paralyzes people. They become the silent participants on the call, keeping valuable insights to themselves and avoiding anything that looks like leadership. They trap themselves in a cycle of preparation, never feeling ready to ship code or propose an idea because they haven’t met a self-imposed impossible standard of readiness.

Both responses share a common foundation: the belief that competence means certainty, and that uncertainty signals incompetence. Neither is true, but the industry’s incentive structures reinforce both assumptions relentlessly.

The Accountability Asymmetry

Part of what drives people toward the confidence mask is the way we handle mistakes. When you act and it goes wrong, everyone sees it. Failed deployments, blown estimates, architectural decisions that aged poorly—these are visible, documented, and often used as evidence against you both in the moment and in performance reviews.

But when you stay silent and miss an opportunity to prevent a problem, when you don’t speak up about a design flaw because you weren’t certain, when you choose inaction over action—those failures are invisible. No one writes postmortems about the bug that wasn’t caught because someone was too nervous to point it out in code review. No one tracks the projects that failed because the junior engineer had the right insight but kept quiet.

This creates an asymmetric accountability structure that systematically punishes visible action while rewarding invisible inaction. It’s an example of Abstinence Bias, a cognitive bias where people tend to avoid actions that have uncertain outcomes, even when the potential benefits outweigh the risks.

For people already struggling with imposter syndrome, this asymmetry becomes a trap. The safest play is to stay quiet, to defer to others, to avoid any situation where your limitations might be exposed. The confidence mask becomes a survival strategy: either project absolute certainty to shut down challenges, or project absolute compliance to avoid drawing attention. Neither approach is sustainable, and both prevent teams from actually solving problems.

The Problem With Pretending We Know Everything

Arrogance in tech is a liability, not a leadership trait. Pretending to know everything prevents teams from actually solving problems. A system built by people who can’t admit when they’re wrong is a fragile system.

I’ve watched this play out in operational contexts more times than I can count. The worst incidents I’ve dealt with weren’t caused by someone making a mistake. Rather, they were caused by someone being too proud to admit they’d made a mistake, and then spending hours digging the hole deeper trying to cover it up. This is where hazardous attitudes such as anti-authority, impulsivity, invulnerability, macho, and resignation show up in engineering teams, often as compensation mechanisms for underlying insecurity.

Real, healthy confidence looks very different. It starts by acknowledging constraints, normalizing “I don’t know, but let’s figure it out”. It prizes listening and understanding over speaking and performing. It’s the quiet confidence of someone who knows their limitations and isn’t afraid to admit them.

Ironically, people who struggle with imposter syndrome are often the most self-aware and the most capable of admitting when they don’t know something, versus people who are perpetually convinced of their own brilliance.

The challenge isn’t forcing yourself to feel like you know everything; it’s learning to communicate what you do know without apologizing for it.

Finding the Right Balance

The reality is that nobody in this industry knows everything. The domain is simply too vast. But we do ourselves and our teams a disservice when we treat gaps in our knowledge as fatal flaws rather than normal operational reality.

I struggle with imposter syndrome. It’s worse when I’m around people I perceive as exceptionally talented—which in tech means it’s basically always there, lurking in the background. I’ve watched friends deal with the same thing, and I’ve tried to help them manage it. I say “manage” deliberately, because I don’t think you break the cycle entirely. The best you can do is dampen its effects enough that it doesn’t paralyze you.

What’s helped me most is a shift in perspective that came from my current role. When you work with enough people across enough domains, you start to see a pattern: everyone has areas where they’re exceptionally skilled and areas where they only have surface-level knowledge. We called this T-shaped knowledge in my MSOL program—very wide in general understanding, but very deep in one or two specific areas.

The engineer who can debug distributed systems in their sleep might struggle with frontend performance optimization. The person who knows every edge case in the authentication flow might be lost when it comes to infrastructure automation. This isn’t a flaw in their competence; it’s just how expertise works. You can’t be deep in everything.

Recognizing this pattern doesn’t eliminate imposter syndrome, but it does reframe it. When that voice starts whispering that you don’t belong because someone else knows more about Kubernetes than you do, you can counter it with: “Yeah, but I know things about database optimization that they don’t.” It’s not about pretending you’re better than anyone else. It’s about accepting that competence is multidimensional and nobody has universal depth.

There is a famous quote that goes something like “The difference between a novice and an expert is that the expert knows how much they don’t know”.

Instead of being embarrassed by and hiding those gaps, we need to learn to express uncertainty with authority. There’s a massive difference between “I have no idea” and “I’m not familiar with that tool, but based on similar systems, here’s how I’d approach it.” One diminishes credibility; the other demonstrates problem-solving ability while remaining honest.

This isn’t just semantics; it’s about separating your worth from your knowledge base. Your value as an engineer, and as a human, extends beyond the ability to know the optimal settings for a database or the latest framework’s API from memory.

The contributions that matter most are often the ones that don’t show up in commit logs: asking the clarifying question that prevents a critical bug, explaining a complex system in a way that makes it accessible to the team, recognizing when a problem requires a different perspective and bringing in the right expertise.

Some of the most valuable insights come from the people willing to ask the “dumb” questions that everyone else was too proud to ask. One of the best engineers I have ever worked with would approach new problems by asking “I don’t fully understand X, can you walk me through it?” and then proceed to ask questions that revealed fundamental misunderstandings in our approach. By asking this simple question, he was able to save us a number of times by challenging assumptions that we had long since accepted as gospel.

Stepping Down from the Tightrope

As you move into more senior roles, the stakes of this balance get higher. Lead engineers and managers have to project enough confidence to guide their teams, but they also have to model intellectual humility. If you’re struggling with imposter syndrome, you might worry that admitting you don’t know an answer will undermine your authority. I’ve found the opposite to be true. Teams trust leaders who are honest about their limitations much more than they trust leaders who pretend to have all the answers.

The strongest technical leaders I’ve worked with share a common trait: they’re comfortable saying “I don’t know” followed immediately by “but here’s how we’ll find out.” They make decisions confidently while remaining open to new information. They create environments where it’s safe to admit uncertainty, which paradoxically leads to better decisions because people aren’t wasting energy on maintaining the performance.

The goal shouldn’t be to eliminate imposter syndrome entirely. A little bit of self-doubt keeps you honest, keeps you checking your assumptions, and keeps you learning. The goal is simply to keep it from paralyzing you or driving you to put on the mask.

The next time you’re in a planning meeting and you feel that familiar doubt creeping in, don’t retreat into silence or overcompensate with bravado. Just be human. Ask the question. Share the perspective you have. Admit what you don’t know while contributing what you do. The industry doesn’t need more people who are absolutely certain; it needs more people who are comfortable enough to admit they’re still figuring it out. And if you’re leading a team, remember: every team member who stays silent because they’re afraid to look stupid is a failure you’ll never see in a postmortem. The mask you wear gives everyone else permission to wear theirs.

Related Reading:

• The Luxury of Ignorance - When not knowing becomes a strategic advantage for those in power