Team Dynamics, Patterns and Anti-Patterns

I've had the opportunity in my software career to witness two distinct kinds of team dynamics: self-organizing and hierarchical command-and-control. I prefer self-0rganizing by a long margin. This is not to say that it's inherently better (although I have heard interesting arguments about the self-organizing of a military unit in the field), but that I enjoy it more, and find it more productive in the world of creating software.

Command-And-Control Teams
If you and your teammates are largely given separate assignments, work on them individually (or in very small groups) and report status and or defer critical decision to one or a few team leaders, you're probably on a command-and-control team. When your work is late or incorrect, it's between you and your leaders.

On the whole, I find command-and-control teams to be less adaptive, nimble, less reactive to change. Less Agile. This is mostly because a select few are responsible for decision-making, and those few tend to be a bottleneck in the decision-making process.

The command organization is often responsible for both organizing the team internally and co-ordinating the team with all outside influences. They're seen as key stakeholders to involve in both internal and external discussions. This is a lot of responsibility for what is often a very small part of the team. Time management and organization is a constant challenge. Even when the command-structure is well-organized and practices good time management, there's still a bottleneck, and that will cause perceptible delays in decision-making.

When these team leaders are overworked, busy, or not well-suited to detail-oriented leadership, there can be a significant leadership gap. If the team they're leading has been socialized to work within a command-and-control environment, they may not pick up the slack. In these cases, you'll see a well-intentioned team where many things aren't getting done.

It can be easy for team-members on a command-and-control team to slip into dysfunctional habits. There's a whole host of problems here, ranging from 'silos' to "It's not my problem". These boil down to not operating like a team at all. Rather than working together to achieve common team goals, command-and-control teams can break down into competitive self-interested fragments whose primary goal is their own success, sometimes at the deliberate expense of other team members.

Self-Organizing Teams
If you and your team-mates have a are given a set of goals to accomplish, and allowed to structure yourselves as you see fit to accomplish those goals, you may be on a self-organizing team. You'll find that you're committing, as a team to complete team goals, but making local commitments to the team (as a whole) about work that you're taking on yourself. When your work is late or incorrect, you'll resolve it as a team.

Because each team-member is empowered to take on a fair amount of decision-making, this means that the team is adaptive to change, nimble, able to shift resourcing and address issues in a natural, community-oriented manner rather than waiting for a more formal decision-making process.

Giving teams this kind of local autonomy scares the crap out of some business leaders, so it won't work for everyone, but I have tended to find it extremely effective. I've heard it argued that this works best with a small, smart/skilled team. I'm inclined to agree, but I'd also say that's often a factor in the success of any team effort, not just in self-organizing teams building software.

One of the more common anti-patterns in a self-organizing team is slipping back into a command-and-control mindset. Many of us have worked in more hierarchical organizations than we have in self-organizing ones, and it's sometimes easy to let dysfunctionality creep in. These habits are not reinforced by the team structure, but if the mindset of self-organization to accomplish team goals hasn't fully sunk in, some people will slowly slip back into old, bad habits.