Tuckman in the Age of Slack

I spent most of my life being a square peg attempting to fit in. From my nerdy high school days to the present, I have always felt like the odd person out. I presume it is why I have dedicated most of my career to leading change in organizations. I saw good people ruined by toxic work environments that permitted mediocrity, so I wanted to do something about it. This is why I joined the Agile Reformation.  I have spent six months with my current client, and I want to discuss what I have learned.

The Myth of Clean Transformations

When you read books like "The Experience Mindset" and "Turn the Ship Around," organizational transformation sounds both heroic and straightforward. Many of these stories are told from the perspectives of people with responsibility and authority over their organizations. They can set priorities, hire and fire, and control budgets. For those of us in the messy middle of most organizations, all we have is responsibility and multiple priorities pulling at us like taffy. Psychological safety is never guaranteed, and your career's future is always contingent.

In this kind of chaotic atmosphere, a project manager or Scrum Master must count on the knowledge and wisdom that came before. One of the central works of leadership comes from Bruce Tuckman's model of team development. In 1965, during the Mad Men era of business, Tuckman reviewed over fifty articles on group development and found a pattern. Those steps are forming, storming, norming, and finally performing. It is not a linear process, and it often gets disrupted when people join or leave the team. Some teams never make it out of the storming phase and are content to burn through time and money. It is a depressing situation, and often the Project Manager ends up getting fired. You really have not worked in technology unless you have experienced this kind of setback.

Tuckman in the Era of Remote Work

Unfortunately, we no longer live in a business world Tuckman inhabited. Today, instead of offices and people working in proximity, teams are geographically scattered thanks to outsourcing and remote work. The dominance of shareholder value means that project timelines are shorter, and employment security is elusive. Finally, challenges normally hashed out in person are now mediated asynchronously via email or chat programs. It is a perfect petri dish for dysfunction and passive-aggressive behavior.

So, what is a project manager to do? I work in an organization using SAFe, so I find Product Increments a helpful tool for tracking the team's progress. Working agreements can be renegotiated, and expectations reset. The annual review or offsite meeting isn't fast enough to keep up with the pace of most projects and their turnover. But a cadence is only a container. A sprint or a PI planning session provides the schedule, but it cannot do the emotional heavy lifting. If a team uses that rhythm only to coordinate tasks while hiding behind Slack handles, dysfunction will fester.

Fixing Friction in Real Time

That is why conflict must be addressed directly and in real time. Chat and email threads don't build agreement and often breed more conflict. Address conflict in person, over the phone, or via a video call. Grievances and resentments must be brought into the open so everyone understands the source, nature, and substance of the conflict. It may not get fixed, but the problem will be exposed and open to everyone, which is the best means to eventually fix the situation.

Tuckman and his model also assumed there was a strict chain of command from the CEO to the team doing the work. In many companies, the reality of a matrixed organization makes that impossible. Fights over priorities are often battles between competing priorities from different departments feeding into the team. Legal requirements might conflict with UI/UX. An executive might demand a particular ERP feature. I have often been asked to mediate these priorities. The product owner has the final say in these conflicts, and if someone tries to pull rank or go over the Product Owner's head, the Scrum Master or Project Manager must call it out right away. During a retrospective, document these conflicts and develop strategies to resolve them.

Agile has evolved since the Manifesto was drafted in 2001, yet many of our foundational management techniques date back more than half a century. We have to adapt them to how business actually operates today. We should evolve and change with the current business environment. My last six months have been a testament to that realization. Understanding how Tuckman's model works, and in what context, helped me see that my all-remote team would take longer to move from storming to the norming stage.

I am still a square peg in the round hole of corporate governance, but I have shaved enough corners to understand that getting work done with people is not about being the smartest or most important person in the room. It's about facing conflict out loud, guarding team priorities, and listening. It is thankless and tedious work but still heroic. It just doesn't feel like it most days. After six months, my team and I finally understand each other. Tuckman’s model still works; it just takes longer in a scattered world that looks nothing like the one he studied fifty years ago.

Until next time.