I knew an engineer once who was quite dedicated to their job. This was the type of engineer you’d want to be on any team you’re on—quick learner, and what they lack in immediate knowledge, they make up for in a sense of obligation to their team and ownership of problems. They want to be responsible for a product’s success.
This person got to the point where they spent a full day at work, and also most full nights. I don’t mean that they worked through the night; I mean that the constant state of worry and dread kept them from achieving restful sleep. Each aspect of their thought life had been invaded by work to the point that dreams each night were about work.
I personally have found that it’s actually pretty easy to find one’s self in this position. Any place I’ve worked, there is a never-ending mountain of work. The couple of times there wasn’t, it was because a project ended when a customer withdrew their funding for one reason or another. That is to say, there was never a moment when I’ve had a funded project and there wasn’t so much work that it induced stress.
The most common prescription I’ve heard to combat this is to encourage engineers to take breaks during the week to disengage from work and to focus on the things that make them a well-rounded person. Vacations are also encouraged; the idea is that by taking time off from the things causing the stress, engineers will not be stressed by them.
Neither of these suggestions have ever worked for me personally, nor for anyone I’ve known. Sure, there may have been momentary relief, but it wasn’t something sustainable.
Here’s a picture of me from a vacation years ago. We had found a local brewery, and my spouse posted a picture of me enjoying a stout to social media, saying: “Look, Trevor is relaxing!” It was the first day I wasn’t worried about what was happening at work and how it would affect me on my return, and if I’d be able to accomplish what was demanded of me.
It was 4 days into a 5-day vacation.
For me, usually relaxing from work came with a tremendous sense that I was not accomplishing some work that I could be doing I wasn’t relaxing. In fact, I’ve several times in my life felt relaxation come while I was working, since I knew that I was doing all I could to relieve the sense that I wasn’t ever going to catch up.
I’m no psychologist, but if I saw such behavior in anyone outside of the technology field, I’d wonder if they had obsessive-compulsive tendencies. Maybe there’s some truth to it, but I don’t think most (surely some, but not most) engineers who exhibit this behavior have it extend to other portions of their life (but again, I’m no expert). While I’ve seen a small number of engineers reach this stage very early in their career, most don’t seem to exhibit it until they are responsible for a large project, or an important piece of a larger project (like an entire subsystem).
It’s easy to think, then, that such reactions come as a result of being busy, but I don’t think that’s a good explanation. Plenty of busy engineers lead perfectly balanced lives, and plenty of busy engineers do not suffer from sleep loss over performing their duties at work.
Getting a bit philosophical, it’s pretty easy to make the case that all stress is caused by the ultimate fear of one’s own death, and while I suspect some people suffer from allowing normal job stressors to tap into fears to reach this level, I have personally never met a substantial number of people in this category. One could extend this category to include worries over losing a job that is required to sustain one’s self or family, but I’ve also never met someone who had these worries unless there were actual termination notices being handed out already.
This isn’t to say that fear of mortality is not the general under-pinning of job stressors (maybe it is, ultimately—ask the philosophers and psychologists), but rather that most fears do not cause a level of stress that induces sleep loss, and yet work fears frequently do. For instance, nearly all engineers comfortably make their way in their commute each day without much concern that every person alive today will eventually die, and out of that 100% eventual death rate rate, 1 out of 114 deaths is from a vehicular collision. Something that is such a high probability (1 in 114 deaths!) doesn’t cause most engineers who are commuting to their jobs any worry at all, but slipping behind on a project? Now then, that’s tough to let go of at bedtime!
There are a number of ways that this can happen.
- An IC or manager is in over their head. They want to be in the position they are, but they know they can’t meet the demands of the position at the current time.
- Expectations are not lining up with reality (either by an engineer’s leader, or else by the engineer themselves). There is a mis-calibration as to what is actually possible, and it’s never possible to meet the bar.
- There was insufficient guidance, or insufficient requests for guidance, which lead to a point where failure looks inevitable.
This is clearly not a comprehensive list, and the solution to each of the above is worth a discussion for each one on its own, but the root cause of the feeling of overwhelmed is the same. That’s what I’ll discuss in the remaining space.
Ultimately, an engineer who isn’t on the chopping block feels stress when there is danger that their goals are not being met. The difficulty then becomes finding why missing the goal is a stress. This is where it gets very specific to each person, and impossible to describe in a formulaic manner. Each person’s goals are different, and so also the reasoning for their goals. But without understanding the core meaning in a goal being met or missed, one cannot understand the source of their stress. One simply needs to ask: “what happens if my goals are not met?”
Regardless of the answer, there’s good news in this situation. When an engineer is feeling stressed, it means that either the engineer is motivated to meet some goal set for the benefit of the company, or else they are stressed over something more intrinsic to their own interests (say, like job security or a raise). In the former case, they want to see the goals of the business be met. In the latter case, the goals are not something that the people managing the people working for the business need to worry too much about—either the business can be used for these goals together with the engineer, or else they cannot, and the engineer will decide if they want to continue to invest effort to meet the business or goals or if there may be a better place for them to work. It is a trade-off decision at that point, and it should be encourgaed; a business does not need the negative effects of employing someone who does not want to work there, since their goals can not actually coincide with business goals.
In trying to address the problem, a manager’s reaction to an overwhelmed engineer can range across one of three options:
Describe that the consequences of missing a goal aren’t as severe as the person is perceiving it.
This path is often not productive, even when the case may be a good one. It can come across as dismissive. But more than that, the manager speaking to a subordinate in this case isn’t necessarily dealing with reality, they’re dealing with reality as the overwhelmed engineer perceives it. Any argument the leader gives to explain why the consequences aren’t that bad, the other party probably has an answer to, or else they wouldn’t feel overwhelmed to begin with. Each party in the conversation is probably weighing the consequences of missing goals differently.
This response is often ineffectual because the two parties aren’t objectively looking at the situation the same way, which makes it impossible to find a common starting point.
Describe that their goals will be achieved, and there is no need to worry.
This may actually be an appropriate response, but only if it is true. If a promotion is locked in stone, or a deal has been signed but not yet made public, or some similar situation, it may be acceptable to share that information. But to state the obvious, it is beyond risky (and potentially unethical) to choose such a response unless the outcome is already known and can be shared.
Affirm the positive things the engineer is bringing to reach their goals, especially the positive things that they may need to do more of to achieve their goal.
Sometimes people are on track to reach their goals and just need a bit of affirmation to know that the things they’re doing are going to get them across the finish line. Other times, people are not on track to meet their goals and need to be steered to the way that those goals will be met. Importantly, even with the best of intentions, telling someone that they aren’t on track to meet their goals is usually not productive (they may become defensive, and now you are their problem, or they may double down on the things that are causing their stress). If they are unaware that they are not on track, that is itself a problem that needs to be corrected in such a way that they can determine it themselves. If they are aware, then reminding them only adds to the stress they’re feeling. Instead of falling into a trap like this, affirming the things they are doing well, and introducing new suggestions as extensions of the things they’re doing well, can help to steer them the right way. It also gives them something objective to focus on, preventing them from ruminating on the subjective reality that may prevent them from keeping out of their own way.
But in any case, a manager or lead can’t know that there’s an issue to be worked on unless the engineer tells them. And the engineers can’t tell their leadership that they’re overwhelmed if there isn’t a sense of mutual respect and understanding.
And so, the first step before any reaction at all can be given, is to build a relationship of mutual trust, and mutual respect. Any reaction that isn’t built on such a foundation is tenuous at best.
What this means, especially if an engineer has had a failure that is still affecting them, is that good leadership must continually seek opportunities to build trust, and must seize them when they are available. Overwhelmed engineers must have a way to know that their leadership means what they say, and are a reliable barometer to measure a situation.
And when an engineer has a victory, it is no small thing to recognize it. This might mean something as small as a simple call-out, or as large as a promotion. But it is important that it comes from their leader, as a sign that the leader has their best interests in mind when also considering the best interests of the business. It also means that overwhelmed engineers should recognize when their leadership is working in such a way for them.
Trevor Kemp 