Are you part of a team that seems plodding, downtrodden or dejected? Do you manage a group prone to infighting among individuals or conflict between factions? Do you go to work every day filled with dread that you'll be surrounded by people exuding negative emotions? If so, you're not alone. Unfortunately, this describes far too many IT groups and project teams.
In my work helping both troubled and toxic teams, I've noticed that there are innumerable ways in which teams descend into dysfunction. It's like the famous quote from Tolstoy's Anna Karenina: "All happy families are alike; each unhappy family is unhappy in its own way." In part, that's why there are so many troubled teams: Because there are an endless number of ways to get there, it's hard to spot warning signs before the dysfunction is entrenched.
And yet I have noticed something common to nearly all troubled teams, a contributing factor, not a primary cause. It's like brush in a drought-dried forest: a nearly endless supply of fuel, ready to transform any small spark into an uncontainable inferno.
I'm talking about the way the work of the group is organized. Groups are usually structured around the flow of work. The group itself is conceptualized as a machine that takes in tickets, requests or requirements and eventually outputs a solution. In the process, tasks are handed off as the locus of the work crosses technical boundaries between one person's responsibilities and another's. In other words, work flows like a car on Henry Ford's assembly line. One person attaches the left front wheel, and another attaches the right.
On the surface, this doesn't sound like a problem. It sounds like a well-defined process for meeting the managerial requirement of optimizing the flow of tasks. The problem is that organizing work this way doesn't meet the requirements of the people who perform the work.
People are not subroutines to be called when their exposed services are needed. They are flesh and blood with feelings and aspirations. Most people in IT are not disengaged, uncaring drones only interested in trading hours for money. They care about the people around them and the quality of their craft, and they hope that their work can make positive contributions. They feel excitement and resentment and fear and boredom.
Working in this sort of structure unleashes negative emotions. People feel:
- Isolated - People may sit next to and interact with other people in the group, but they really don't work together. They don't share goals that they work collaboratively to achieve.
- Bored - When people have a narrow set of technical responsibilities, they stop learning new things.
- Trapped - Organizations often only have a single person in a particular technical niche. Not only do such people feel burdened because there's no backup for them, but they also know that they are too valuable in their current role to be seriously considered for new and exciting work. They see no career path.
- Afraid - Workers who focus exclusively on a single system for a long time know that if the system is retired, most organizations will simply lay them off rather than retrain them. They fear, with reason, that they will end up on the job market with limited and outdated skills.
- Demotivated - Work organized as a stream of individual tasks is dispiriting. Doing it for too long feels like being a hamster on a wheel. There's no beginning or end, no excitement that comes with new challenges and no sense of accomplishment that comes with the completion of a project.
And people who live in this state for too long are emotionally depleted, fragile and, as a group, vulnerable to a spiraling down into dysfunction when things go wrong. They don't have the resilience to beat back despair when returning to normal is not that attractive an option anyway.
If your group looks like this, think about what you can do to make a workflow that accommodates both the tasks and the people. Not only will you be improving people's experience of working there; you'll also be improving the long-term effectiveness and efficiency of the group.
Paul Glen is the co-author of The Geek Leader's Handbook and a principal of Leading Geeks, an education and consulting firm devoted to clarifying the murky world of human emotion for people who gravitate toward concrete thinking. You can contact him at firstname.lastname@example.org.