Optimal Stress
Brett Flegg
Drawing boxes and arrows on whiteboards and writing documents nobody reads
In this week’s article, I will discuss stress and its relationship to productivity. A couple of important disclaimers: First, as it says on my profile, I am a software engineer1, not a psychologist, and this topic is about as far away from my professional competency as they get. What I know on the subject has come from reading, personal experience, and applying some of the principles in practice, but you can (and should) take anything I am saying with a grain of salt. Second, I am focusing on routine stress in this article – the type we feel every day on our job working towards a deadline. Routine stress shouldn’t be confused with other kinds of psychological stress like traumatic stress or anxiety – the only ‘optimum’ level of this sort of stress is none. If stress negatively impacts your life, I implore you to reach out to a professional to get help (many of our employers have great programs to support us!).
When we think about stress, we think about lack of focus, reduced creativity, and burnout. But these are symptoms of excess stress. There is “good” stress too. As humans, we are wired to respond to stress. As I have previously discussed , people tend to produce better work and achieve more when we set difficult but achievable deadlines to induce some stress. This effect has been studied by psychologists and formalized as the Yerkes-Dodson Law :?
As stress increases, productivity and performance also increase—up to a point.?
Specifically, the Yerkes-Dodson law says the relationship between stress and productivity/performance follows a bell curve. Too little stress, and we don’t feel motivated to get out of bed. Too much stress will cripple our ability even to try and ultimately lead to burnout. The optimal amount of stress lies somewhere in the middle.
We all respond to stress differently, and the optimal stress level varies from person to person and job to job. Life rarely resembles a perfect academic bell curve. The curve tends to be much shallower for purely creative tasks (i.e. increasing stress does not have a significant positive effect on productivity). Some people have a slow decline in productivity after reaching peak stress, and some simply shut down (i.e. productivity immediately goes to zero). But, in general, I have found this to be a good model for team behaviour in practice.
I marked two points on the graph from Dr. C. Edward Pit . The first is pretty obvious to any math major: the point of maximum productivity. This represents peak productivity - any more or less stress will impair productivity. The second point, the point of maximum growth, is actually over the hump on the declining side of the curve. I believe that as individuals, we should strive to edge ourselves against the point of maximum growth periodically.??
As Sheryl Sandberg talks about extensively in her book Lean In , taking risks, choosing growth, and challenging ourselves is the key to career success, and being uncomfortable enables us to grow2. On the Yerkes-Dodson graph, we can think of this as periodically 'over-stressing' ourselves - pushing ourselves over the hump and allowing for the possibility of growth. Reflecting on the last twenty years of my career, I felt most fulfilled when I pushed myself into situations where success wasn't guaranteed. Higher stress levels forced me to re-evaluate how I approached problems and find new and better ways to reach my objectives.?????
But, it is unhealthy to spend an extended period at high-stress levels, and it is essential to monitor ourselves and make adjustments. As engineers, we need to embrace the ebbs and flows of the development cycle and make sure we take adequate time for ourselves to recover from periods of higher stress. Failing to do so often leads to burnout – which is hard to recover from. If you ever find yourself in this situation, it is critical you talk to your leads and peers to adjust expectations or rebalance work3.??
领英推荐
As a tech lead, carefully managing your team's stress level is critical. My preferred strategy is to build product plans and schedules that are hard but achievable. That aim is to push the team to the low-end of the optimal stress curve while leaving some buffer for unexpected issues. When there are a lot of unknowns, I create mini-milestones along the way that can be used as focus points for the team – but can also be moved or redefined as needed to reduce stress.?
I then seek to provide stretch opportunities for individuals on the team that want to push themselves to the point of maximum growth and set aside time to support them in these endeavours. The keywords here are "provide" and "support" (as opposed to "assign" and "manage"). To be effective, these stretch goals need to be self-managed and fail-safe (i.e. not a critical path for the project). Self-actualized engineers can then use these projects to find the right place for themselves on the productivity-stress curve – pushing forward or pulling back as needed.
I can't possibly cover all the intricacies of this topic in a short article, but I hope the article provides a framework for thinking about and managing stress. I would love to hear your thoughts or suggestions in the comments below.?
Be Happy!
Like this post? Please consider sharing, checking out my other articles , and subscribing to my weekly Flegg's Follies newsletter for more articles on software engineering and careers in tech.
Footnotes:
Please note that the opinions stated here are my own, not those of my company.