19 Jan Episode 005 – Why Smart People Stay Stuck Longer Than They Should
Summary
This conversation explores the challenges engineers face when performance becomes the primary strategy, leading to feelings of frustration and misalignment. It discusses how engineers often rationalize staying in roles that drain them, reframing discomfort as duty and fatigue as commitment. The dialogue emphasizes the importance of distinguishing between endurance and alignment in one’s career, and the need for self-trust in leadership roles. The episode concludes with a teaser for the next discussion on trust issues among capable engineers.
Takeaways
- Engineers often feel trapped by performance expectations.
- Staying in a draining role can be rationalized as responsible.
- Discomfort is often reframed as duty, leading to misalignment.
- Leaving a role can sometimes be the most responsible choice.
- Responsibility without agency leads to containment, not leadership.
- Self-trust is crucial for effective leadership in engineering.
- Endurance is about surviving; alignment is about thriving.
- Engineers are trained to absorb complexity and carry loads.
- Second-guessing oneself can erode self-trust over time.
- It’s important to assess whether a role helps you grow or just tolerates you.
Transcript
This transcript was produced by robots and left as-is. Accuracy and elegance are not guaranteed.
In the last interview, we talked about what happens when performance becomes the strategy. When engineers respond to friction by doing more, becoming faster, more reliable, more indispensable, and how often that turns into a trap. This episode is about what happens next, because a lot of engineers feel that trap. They know something isn’t right. They’re tired, frustrated, underutilized, but they stay. And they don’t stay because they’re unaware. They stay because they’re smart. Now, that might sound backwards, but it’s not. Smart people are very good at explaining things to themselves. And that includes explaining why nothing needs to change. Here’s the example. Most engineers don’t stay stuck because they lack options. They stay stuck because they can build a very convincing case for why staying is the responsible thing to do. They’ll say things like, this isn’t the right time, or I don’t want to leave my team in a bad spot, or I should just be able to push through this phase. Maybe even I’m lucky to have this role, or I need to be patient. And on the surface, all of that sounds reasonable. And that’s the problem.
None of these explanations are obviously wrong. They’re just incomplete. What’s really happening is something quieter. Discomfort gets reframed as duty. Fatigue reframed as commitment. And misalignment gets reframed as maturity. Engineers are especially good at this because we’re trained to endure. We’re trained to solve, to absorb complexity, to carry load.
So when a role starts to drain us, we don’t interpret that as a signal. We interpret it as a challenge, something to manage better, optimize, push through. There’s an important distinction here. There’s a difference between effort that builds capacity and effort that only sustains imbalance. One helps you grow, the other just keeps things running.
And most engineers don’t notice when they’ve crossed that line. They just notice they’re tired all the time. Another pattern I see a lot, engineers will say, well, I don’t want to be the kind of person who just quits when things get hard. That sounds noble, but it hides an assumption. It assumes that leaving is quitting.
Sometimes, leaving is the most responsible move available. Not impulsively, not dramatically, but deliberately. Because staying doesn’t just affect you, it reinforces the system. Every time you absorb work that shouldn’t be yours, the system learns that it doesn’t need to change.
Every time you smooth over dysfunction quietly, the organization loses the incentive to fix it. And over time, you actually become part of the mechanism that’s draining you.
So let me slow it down here because this is where the guilt shows up. Engineers feel responsible for outcomes, for people and for stability. And then they worry that changing roles or setting boundaries or stepping away is selfish. But responsibility without agency isn’t leadership, it’s containment. And containment has a cost. Usually paid in energy,
clarity and self-trust. This connects directly to the earlier episodes. If you can’t see your value clearly, you’ll overperform to prove it. If certainty stops working, you’ll do more. If doing more traps you, you’ll rationalize staying. Not because you’re weak, because you’re thoughtful.
But this is where the danger comes. The longer you stay in a misaligned role, the harder it becomes to trust your own judgment. You start second-guessing yourself. You think, well, maybe this is just how leadership feels. Or maybe I’m expecting too much. Or worse, maybe the problem is me. That erosion doesn’t happen all at once. It happens slowly through a series of reasonable decisions that all point in the same direction. Stay. Hold on. Push through. So what’s the alternative? It’s not quitting impulsively and it’s not blowing things up. It’s learning to distinguish between endurance and alignment. Endurance is about surviving conditions. Alignment is about choosing conditions that let you do your best work without burning yourself out and burning yourself down. So here’s one simple question to sit with this week. And it’s not one to answer quickly, just to notice. Ask yourself, am I staying because this role is helping me grow or because I’m good at tolerating it?
It’s not a judgment, it’s a diagnostic. And if that question makes you squirm a little, that’s a data point. In the next episode, we’re going to talk about why all of this eventually shows up as a trust issue, not trust in others, but trust in yourself, why engineers who are highly capable technically often struggle to trust their own judgment in leadership roles and how to rebuild that without becoming reckless or reactive. That’s where we’ll go next.
Sorry, the comment form is closed at this time.