There is a belief quietly embedded in some engineering cultures that suffering equals seriousness. That if your team is not always reachable, not always slightly panicked, not always racing something, then they must not be working hard enough.
This belief is wrong. And it is worth naming clearly, because it does real damage.
The Confusion
Challenge and stress are not the same thing.
Challenge is being handed a problem you have never solved before and being trusted to figure it out. It is learning something hard. It is designing a system under real constraints. It is disagreeing with a technical decision and having to defend your position with evidence. Challenge stretches you. When it is over, you feel like you grew.
Chronic stress is your phone buzzing at 10pm. It is a deadline moved up without explanation. It is the ambient anxiety of knowing you must always appear available, always appear busy, always appear to be giving more. When it is over, you feel hollowed out. And then it starts again.
Some managers treat the second thing as if it were the first. They see responsiveness and call it ownership. They see exhaustion and call it passion. They create urgency as a management style, not because the work demands it, but because urgency feels like leadership.
Why This Happens
It is not always malicious. A lot of it comes from a simple measurement problem.
Stress is visible. You can see who responds fastest. You can see who is online at midnight. You can see who never pushes back on a deadline. These signals are easy to read, easy to reward, and easy to confuse with performance.
Genuine challenge is harder to observe. Deep thinking is invisible. The best engineering decisions often look like nothing happened, because a problem was caught early. The developer who said "we should not build this yet" and saved the team three months of rework does not have a story that makes it into the all-hands.
So the proxy gets promoted: availability, urgency, perpetual motion.
What It Costs
People in chronically stressed environments often look highly productive for a while. They respond fast. They ship things. They are visibly busy.
But the quality of their thinking degrades. Their decisions get narrower. They stop exploring better options and start choosing the fastest acceptable one. Their appetite for hard problems shrinks, because they do not have the cognitive space to sit with difficulty. They start optimizing for speed over correctness, for appearing capable over actually being capable.
And eventually, the best ones leave. Not always loudly. Sometimes they just get quieter, do what is asked, and start looking elsewhere. The people who stay longest in high-stress, low-challenge environments are often those with fewer options, not those with the most to contribute.
What Real Challenge Looks Like
This is not an argument against hard work, tight timelines, or high standards. Those things are real, and good engineers often want them.
Real challenge tends to have a few properties:
- It requires thinking, not just doing. The constraint is intellectual, not just temporal.
- There is genuine ownership. The person doing the work has some say in how it gets done.
- The pressure is contextual, not permanent. There are hard sprints and then there is recovery. The urgency is tied to real circumstances, not manufactured as a default state.
- Failure is information, not catastrophe. People can take risks without dreading consequences.
Paranoia is not a feature. Misery is not a signal of commitment. A team that is always stressed is not a team that is being challenged. It is a team that is being depleted.
Silence Can Be the Sound of Quality
I experienced this firsthand when I was leading a team.
We were, by most measures, the quietest team around. Low communication overhead. Calm standups. Not a lot of noise in the incident channels. And the reason was simple: we had very few bugs, and when something did get fixed, it stayed fixed. We were not constantly putting out fires because we were not constantly starting them.
But I heard through the grapevine that other teams thought we were not doing much. Because we were not loud. Because we were not visibly scrambling.
Meanwhile, the teams that were most vocal, most communicative, most frantically active were dealing with recurring issues, patches on top of patches, the same problems resurfacing in slightly different shapes. That busyness was real. The work was real. But a significant portion of it was self-generated, the cost of not getting things right the first time.
The irony is sharp: doing quality work made us invisible. And being invisible got mistaken for being idle.
This is what happens when communication volume becomes a proxy for productivity. The team fighting fires all day is easy to see. The team that quietly prevented the fires does not have a highlight reel.
A Note to Managers
If your team seems disengaged, it is worth asking whether you have been offering them challenge or just stress. The two feel similar from the outside, especially if you are the one setting the pace.
Challenge requires trust. It means giving someone a genuinely hard problem, stepping back, and letting them work through it. That is harder to do than creating urgency. It requires believing that thinking is work, that slowness can be wisdom, and that the goal is excellent output over a career, not maximum output over a quarter.
The teams that do the most interesting, lasting work are rarely the ones running on panic. They are the ones who are genuinely absorbed in hard problems, who have space to think, and who know the difference between a real fire and a manufactured one.
That distinction is worth protecting.
Top comments (0)