When Do We Hold the Whole Team Accountable?

Let’s begin with the answer to the question in this lesson’s title: when looking at the aggregate output of the team’s activities.

Most often, engineering team accountability is in the realm of “success or failure” and we most often focus on their failures—either the team collectively chose to take no action or it lacked a process to prevent the failure (and could’ve and should’ve created one).

Consider a scenario in which an engineering team fails to respond to a production incident or, worse, creates a production incident. A few years ago, there was a rather embarrassing moment for HBO Max (the entertainment conglomerate) when an email went out to a subset of their subscribers by accident. HBO Max later tweeted that “it was the intern” who was responsible. The tweet itself highlighted a common scenario: the intern does something that embarrasses the team.

But really, this is a team failure. How was it that one person had the ability to take that kind of unilateral action in a production system? Why weren’t processes in place to catch this sort of thing? Humans make mistakes all the time, regardless of the level of experience or seniority of the individual making the mistake.

Even senior people make mistakes! Early in my career, I had an entry-level IT operations role and I was helping the VP of Operations move some servers around in the server room. As part of that move, we needed to move some files off of servers we were about to turn off. He took me to a terminal to log in, and I began to move said files to their new hardware home. While I was doing that, I found some files to which I lacked access. I pointed this out to him. He frowned and said, “That’s weird.” Logging in under his own credentials, he muttered something under his breath and promptly typed rm -r *. When that command took a lot longer than it should have, he was surprised. Then he paled, shouted an expletive, and canceled the command; one of the “files” in question was actually a symbolic link to the root of the shared network drive for all employees. Since he had root access, his command was methodically destroying every single file on the shared network drive of a company of several hundred people.

Mistakes happen, and it’s part of the responsibility of the team to prevent them.

Even when there aren’t mistakes, however, the team is responsible for their performance in other ways. Project deadlines, for example, are a shared team responsibility. The overall responsibility of getting the project done is broken out over several (or all) of the team members individually, but the overall project is a shared, team, target. If the team meets the goal, awesome! Let the team celebrate. Missed the target? The team needs to figure out why and how to avoid such misses in the future.

"Shared accountability means no accountability." I had a boss once that was quite fond of this phrase. He insisted that when you don’t hold one person responsible for a problem, nothing gets done, because everybody assumes it’s everybody else’s problem. Although he was partially right—psychologically, diffused responsibility leads to greater willingness to act in ways we wouldn’t otherwise, fueling what’s known as “mob mentality”—in a small team setting, it’s usually possible to stress the importance of fixing the problem while avoiding blame. Taking it in the opposite direction—always finding a person to blame—means that the team falls into the habit of seeking out a “scapegoat” anytime something goes wrong, and that can destroy team culture. Team members cannot feel psychologically safe if they have to worry about being labeled as the scapegoat for the next incident.

By the way, it’s important to note that a team meeting its goals doesn’t always mean every single individual met their targets. In a high-functioning team, team members will cover for each other, and one who finishes early will step in to take on additional tasks or stories to help the team as a whole. Similarly, just because each individual completes their tasks doesn’t mean the team will be successful, particularly since most tasks/stories/project plans don’t incorporate all of the various “little details” that fall through the cracks during planning. In a high-functioning team, the team members will go that little extra distance to make sure their task fits into the larger whole seamlessly. In a poor-performing team, on the other hand, each team member focuses on doing only what they’re “contractually obligated” to fulfill, with little to no concern for how it all plays out in the larger whole.

Remember that psychological safety is paramount for a team to behave collectively.