“Split Your Overwhelmed Teams”
Communications of the ACM, March 2023, Vol. 66 No. 3, Pages 54-56
Practice
By Thomas A. Limoncelli
“If your team is suffering from low morale and high stress, look at the cognitive load on the team, review its sources, and look for substantive changes that will have the desired impact. Splitting the team could be exactly what is needed.”
A friend came to me asking for advice. His SRE team was suffering from low morale. People were burning out. Attrition was high. People leaving often cited high stress levels as the reason. There was concern that their backfill replacements wouldn’t last.
Then Todd (not his real name) told me the biggest shocker: The team is overworked, yet his boss won’t let him hire more people.
The way he explained this gave me the impression that he thought this was the first time in the history of the world that a request for more staff was denied. I broke the news to him as gently as I could.
After wiping the tears from his eyes, I tried to refocus the conversation the best way I knew how. I asked the most powerful question you can ask an engineer: “What problem are you trying to solve?”
He responded, “How to convince my boss to hire more people!”
“Yes,” I replied, “but what problem are you trying to solve?”
He thought for a moment and said, “Low morale? High stress? The fact that everyone is so overloaded that nothing gets done?”
Yes! Now we’re talking. Hiring more people is a solution, not a problem. By restating the problem as one of morale and stress, we open the door to other possible solutions.
The Problem
Here’s what I learned about the team’s situation:
His team was responsible for managing six systems: the physical infrastructure (wires, cables, and physical computers), as well as cloud infrastructure, plus a series of applications that ran on top of that infrastructure.
Onboarding new people took many months as they learned all the various systems, technologies and processes, policies, and procedures. Todd said they had tried different ways to train people, manage documentation, and so on. All that helped, but it was still a lot of information to keep in your head.
It was clear to me the main cause of the team’s stress was being responsible for so many wildly different systems. The team members weren’t stressed by risky, high-stakes work, as you might expect. There weren’t a lot of outages. However, people were stressed because they felt incompetent. Six major areas of responsibility meant that no matter how good you became at one thing, there were other areas that you always felt embarrassingly ignorant about.
In simple terms, the team was feeling overwhelmed. This stresses people out and leads to low morale.
Todd said, “But that’s all in their heads!” and I agreed. Overwhelmed is a feeling, not a physical problem. If it were a physical problem, it could be surgically removed.
Psychologists’ term for this is cognitive load: the amount of working memory resources used. Like a computer running slowly because it is running too many programs at the same time, your brain is overwhelmed.
When I talked with members of the team, I often heard phrases such as “I feel stupid” or “At my last job, I was the expert, but I’ve been here a year and I still don’t know what I’m doing.”
These were highly intelligent, experienced engineers, yet they frequently put themselves down. They weren’t just being humble; they really felt inadequate.
One team member told me something that explained this better than any book on management theory could. He said that with six areas of functional responsibility, he never did a single task long enough to get good at it. At previous jobs, he learned a task and then applied that learning to literally hundreds of projects. He pointed out that it is normal to feel inadequate while learning a new skill, but every time he got to use that skill, he “got the dopamine hit of a job well done.”
On this team, with six major areas of responsibility, there was constant context switching. Every task would bring this team member back to the “feeling stupid” phase. There wasn’t enough repetition to get to the “feeling of accomplishment” phase. Nobody wants a job that makes them “feel stupid” every day.
Yes, if he waited long enough, he would be assigned a task that let him use a skill he learned earlier. Skills fade if you don’t use them, however, so he would go back to “feeling stupid,” compounded by the fact that he would be kicking himself for “not taking good enough notes.”
Engineers often say they enjoy learning new things, but I believe what they really enjoy is demonstrating that new knowledge. To achieve a feeling of accomplishment, they need to be able to demonstrate the new skill soon after learning it. Constant context switching among six areas of responsibility meant the dopamine hits were few and far between.
It wasn’t always this way. Years earlier, the team was half the size and had half the responsibilities, and everyone was happier. There was no talk of burnout. Everything just worked better.
My suggestion was simple: Split the team in two and give each half as many responsibilities.
About the Author:
Thomas A. Limoncelli is a Technical Product Manager for SRE at Stack Overflow, Inc. in New York City, NY, USA. He previously worked at small and large companies including Google, Bell Labs/Lucent, and AT&T.