Stress Robs You of Your Ability to Think Strategically
Principles for Leading Software Teams: Part II
I’m a fan of the NPR series Hidden Brain. A particular episode tells the story of a young mother who found herself terminated from her job for a careless yet forgivable mistake. The stress of being without a job understandably was creating marital friction which led to a separation. Being a single mother without a steady source of income only multiplied the stress. She was struggling to make ends meet. At a time when supplies were getting particularly low, a new credit card seemed like a godsend. After getting the new card, she promptly ran to Walmart to stock up on household items. In her rush, she maxed out the card.
Only after the fact did she realize that she had put herself right back into a difficult spot. Had she thought about her expenditures for the coming month, she would have realized that paying for gas to get to job interviews is more important than making sure she doesn’t run out of detergent for 6 months. In her stressed state, she was thinking only of her immediate needs and how she would ensure those were “permanently” taken care of. She wasn’t thinking clearly. She wasn’t thinking strategically.
This was just one compelling anecdote in an episode about how we get “tunnel vision” when we find ourselves in stressful situations. When I heard it on my commute, it struck me that scenarios like this (though, perhaps not as extreme) happen all the time at work. Work can be loaded with stress — some of it self-imposed; some of it externally imposed. What if that stress is causing us to make poor decisions?
Remember, software is “knowledge work.” A wise mentor of mine once said, “Every line of code is a business decision.” Maybe a stretch, but you get the point. Do we want those decisions to be made with clarity of mind and from a strategic perspective?
Think back to times you’ve been under duress on the job. What was your sole focus? Likely: what is the shortest path between where I am and the place where the pain will stop? For software, that can be disastrous: poorly thought out implementations; manual tweaks to environments that people will forget about to get systems limping along; lack of creativity.
Dan Pink’s Drive considers the effectiveness of extrinsic versus intrinsic motivation. Inducing stress to get people to be more productive would be an extrinsic motivator. Per Drive, it turns out that for routine tasks (like working on an assembly line), extrinsic motivators such as stress can cause an increase in productivity. Hence, businesses during the industrial revolution were rewarded for having fear based cultures, and it became standard practice. Alas, the industrial revolution seems to be the origin of so many of our bad organizational practices. But software professionals and knowledge workers in general are not doing routine tasks. They have to think creatively and make business decisions with every line of code they write. How does extrinsic motivation impact that kind of work? According to Drive, it’s “devastating” and “impairs performance.”
If we grant that stress is counterproductive in knowledge work, what should good leaders do about it? Perhaps the simplest most immediate thing you should do is remove it from your management toolbox. Don’t give in to the temptation that things won’t get done if you don’t spell out some fearful consequence. Definitely stop the passive aggressive hint dropping, “Oh wow, we’re behind? Can you let me know if we’ll get it done by Monday because that’s when I have to update the executive team.” (Full disclosure: I’ve done that myself. Terrible, I know.) It might not be obvious to you that you’re even doing this. Ask around. If it’s a habit, it will be hard to break. Enlist some colleagues to hold you accountable when they see it happen.
“But some people just won’t get things done if there isn’t stress involved!” Those people have no place in the organization. If your job consists of making sure people are feeling stressed, you’re robbing your organization of your time which could be better used elsewhere, and you’re probably making yourself miserable in the process.
Beyond that, let’s look at a few systemic things that can lead to stress and what we might be able to do about them.
Deadlines
Deadlines can often induce stress, and they’re famous for causing developers to take shortcuts (tunnel vision). “But deadlines are unavoidable!” Are they? I find most deadlines to be arbitrary. Business leaders get tired of waiting and waiting and feeling like nothing ever gets delivered, so they fall back on the only thing they’ve seen work — a deadline.
The Agile approach to this can be very effective at defusing the necessity for a deadline. If business stakeholders can see day after day in production that progress is being made toward a goal, then they don’t need status updates telling them everything’s on schedule (with fear motivating people to stay on track with the project plan).
I’m reminded of one executive’s story about this problem. Each week he got a “RAG” report (red, amber, green). Week after week: green. As the final week or two rolled around, suddenly: RED! (No stop at amber; straight from green to red.) He felt lied to. Didn’t the team know sooner that they wouldn’t hit the deadline? If instead of trusting weekly status reports, you’re just constantly looking at the software, and you can see with your own eyes in production that progress is happening, you don’t have to take somebody’s word that “everything’s fine.”
I’ve heard more than one business leader say that they will set a deadline tighter than necessary because they know it will slip. That sounds pretty arbitrary. However, for those deadlines that aren’t arbitrary, my claim is that Agile still gets you way ahead of the game. Implied in a deadline is usually some scope: the product needs to do x, y, and z. Unfortunately, that list is rarely correct. You think you know what needs to be built, but things change significantly when people start playing around with the software. If you know your customers need something by a certain date, you’re better off iteratively delivering bits of functionality along the way. When the deadline arrives, at least they have something and it’s much more likely to be closer to what they actually need because they’ve been steering the progress all along.
I’ve heard all too often in other contexts besides delivering software: if I don’t set a deadline then people won’t get their work done. Perhaps I’m overgeneralizing, but I can think of two reasons why people don’t get stuff done. First, the work doesn’t actually matter. If people believe the work matters, they do it. If you find yourself having to hector someone into finishing a task, you should pause and ask if it’s really that important. We tend to do a lot of arbitrary and pointless stuff for a variety of reasons.
Second, the person simply doesn’t have the internal motivation to work. If that’s the case, that person should probably work somewhere else. Again, if your company is paying you to remind people to get their work done, you should feel guilty. There are much more important things for you to do.
As an aside, deadlines do more than just induce stress. They often keep people from focusing on what’s actually important. See what Brian Robertson, inventor of Holacracy, has to say about that: The Insanity of the What-by-When.
Crazy ideas, I know. I warned you.
Production Deployments
Anyone in software can relate to the stress of production deployments. My last gig did monthly, midnight deployments. Multiple times those late night deployments had failures that forced us to scramble. You’re making great decisions at times like that, right? I’m happy to say at my current job, we deploy around 8 to 9 times per day on average. Deploying is a non-event. Totally different levels of stress.
Of course, it isn’t just a matter of deciding to deploy more frequently. It takes work to build a system that can support that, but if we grant that stress has negative impacts, isn’t it worth the effort? For an in depth treatment of the habits of high performing software organizations (like frequent deployments), I would recommend Accelerate. They cite “deployment pain” as being one of the main organizational factors correlated to burnout.
Fear of Failure
Fear of failure is an element of Psychological Safety which I covered before, but it can also be a source of stress. Want to be the guy that broke production? Probably not, but Accelerate shows us that you can make it safe to fail so that you don’t have the associated fear and stress. They emphasize shrinking your “mean time to resolution” — the time between when a production failure is discovered and when it’s resolved. If your MTTR is low, then you don’t care that much if you break production. You can quickly fix it. Less stress (although certainly still some) and higher productivity because you aren’t holding on to get things just right. This is a work in progress for us. We have a roughly 2% change failure rate right now, but we can vary pretty widely on our MTTR (from minutes to several hours). Something for us to strive to improve.
Tangentially related to fear of failure is something that people consider to be the hallmark of a good company culture: “accountability.” “If everyone is responsible, no one is responsible.” “I need a throat to choke.” That sounds ominous and stressful.
In the early days of software, quality was the responsibility of the tester. People went to great lengths to establish a chain of accountability. This bug should have been caught by this test case. Who ran that test case? We need to hold that person accountable. There’s so much wrong with that approach, but let’s just focus on one aspect: consider the system. What in the system caused that to happen? Most people (if you have been vigilant in hiring and firing) want to do a good job, yet we seem to think the fear of punishment will cause them to do better?
There’s an important study on this topic by the Institute of Medicine. At the time of the study, in the medical profession, mistakes were typically dealt with punitively. It occurred to someone that most healthcare professionals get into that line of work because they care about people. The last thing they want to do is make a mistake that leads to injury. The study authors posited that perhaps since people’s intentions are good, there might be something in the system that is leading to failure. They tried changing a handful of things:
- Cap the number of patients a healthcare professional can actively care for.
- Limit the number of consecutive hours worked.
- Change medication labeling to make it harder to administer the wrong dose.
The study found that the incidence of mistakes went down significantly. The full report is To Err Is Human: Building a Safer Health System. A summary is available here. From the summary:
One of the report’s main conclusions is that the majority of medical errors do not result from individual recklessness or the actions of a particular group — this is not a “bad apple” problem. More commonly, errors are caused by faulty systems, processes, and conditions that lead people to make mistakes or fail to prevent them. For example, stocking patient-care units in hospitals with certain full-strength drugs, even though they are toxic unless diluted, has resulted in deadly mistakes.
Back to my point about holding testers accountable: testers don’t want to miss bugs. Making them think they’ll get in trouble for missing one is not going to make them better testers. It will make them worse because they stop thinking creatively due to the stress. Fortunately, automated testing and continuous delivery have been significant systems improvements that have gotten us out of the business of “holding testers accountable.” We still have testers. They just get to focus on the fun, creative stuff like exploratory testing which is generally more motivating. Machines are better than humans at the repetitive stuff anyway.
Similar sentiments from Accelerate:
How organizations deal with failures or accidents is particularly instructive: Pathological organizations look for a “throat to choke”: Investigations aim to find the person or persons “responsible” for the problem, and then punish or blame them. But in complex adaptive systems, accidents are almost never the fault of a single person who saw clearly what was going to happen and then ran toward it or failed to act to prevent it. Rather, accidents typically emerge from a complex interplay of contributing factors. Failure in complex systems is, like other types of behavior in such systems, emergent (Perrow 2011).
Thus, accident investigations that stop at “human error” are not just bad but dangerous. Human error should, instead, be the start of the investigation. Our goal should be to discover how we could improve information flow so that people have better or more timely information, or to find better tools to help prevent catastrophic failures following apparently mundane operations.
Do you take time to consider the system when a failure occurs rather than just looking to hold someone accountable? Wouldn’t you rather work for an organization that does?
A sort of corollary that I often cite when I’m talking about trying to minimize stress is that innovation and creativity need breathing room. If you’re always slammed by deadlines, you don’t have time nor the inclination (tunnel vision due to stress) to think a bit bigger. I would claim that minimizing stress therefore leads to more innovation.
In addition to impacting innovation, I don’t think it’s a stretch to say that our effort to minimize stress leads to systems that are more iterative and emergent in nature which means the organization is nimble. Similarly, it drives us to create systems where we can easily recover from failure which means the organization is antifragile. That’s three for one: minimizing stress makes the organization innovative, nimble, and antifragile.
I’m Not Stressed
I suspect that there will be those that disagree with my overall point and believe that a bit of pressure (which doesn’t necessarily cause stress) is helpful in creating focus. I’m open to that perspective. I have generally found that to be the exception in software engineers, though. Therefore, I tend to lean in the other direction in my approach with the overall organization. What do you think? Does pressure always cause stress? Do you think we need that from time to time? Leave a comment to let me know what you think.
Postscripts
Giving Feedback
Some time after publishing this essay, a colleague passed along this very interesting article. It is about critical feedback and how the orthodox approach to it might be counter-productive. I would highly recommend it. I mention it here because there are a couple very well stated points that support the overall thesis of this essay, so selfishly, I want to store them away here for future reference:
Take us very far out of our comfort zones, and our brains stop paying attention to anything other than surviving the experience. It’s clear that we learn most in our comfort zones, because that’s where our neural pathways are most concentrated. It’s where we’re most open to possibility, most creative, insightful, and productive. That’s where feedback must meet us — in our moments of flow.
I truly love how that quote dunks on the trope of “getting out of your comfort zone.”
In the brains of the students asked about what they needed to correct, the sympathetic nervous system lit up. This is the “fight or flight” system, which mutes the other parts of the brain and allows us to focus only on the information most necessary to survive. Your brain responds to critical feedback as a threat and narrows its activity. The strong negative emotion produced by criticism “inhibits access to existing neural circuits and invokes cognitive, emotional, and perceptual impairment,” psychology and business professor Richard Boyatzis said in summarizing the researchers’ findings.
Is It Really About Fear?
An interesting update from reading The Fearless Organization: the author makes a very simple statement. “Brain science has amply demonstrated that fear inhibits learning and cooperation.” That seemed inline with what I am trying to say in this essay, but I paused on the word “fear”. To my final point (“I’m Not Stressed”), perhaps that’s the difference? Maybe it’s stress induced fear that is so counter-productive — not just stress itself. Not all of us feel fear when pressure/stress is applied (but I’d wager that many of us do).
Curious to Learn More?
Check out Principles for Leading Software Teams: A Guide for related articles and reference materials.
