Managing Software Development Team Dynamics from Within
What marks out software development from other industries is that disruption in practice is the norm, and people acting unusually may be a feature, not a bug. Team member problems like inexperience or unpleasantness effect every workplace, and you can read plenty of tiresome management tomes about how to diligently smash those square pegs into their round holes. But agile software teams have always been on the cutting edge of self governing, and they don’t usually wait for resolutions from above — assuming there is an above. Little of what they do is mandated, most is agreed upon after observing recent practice. That is why they have a little more responsibility to act when they see problems with the team’s dynamics or in working relationships.
Like most of us, I’ve been both a team problem and a team problem resolver at different times, so I certainly don’t intend to offer up disciplinary actions; if the team can recognize potential issues early on, they can usually just use soft power to squish them.
This post tries to mark out different problem relationships that I have seen more than once in software teams or projects. I’m not talking about vertical problems (”I hate my manager”, etc) but team-level or horizontal communication with other peer services in larger organizations. Quite by chance, another article has recently popped up about managing difficult software engineers, but I’m nearly always looking at the dynamics between two parties. I don’t believe individual devs have a permanent type that they adhere to in all situations. Yet sometimes the spotlight does fall on one person and that is how you first notice an issue.
Over Communication
One team member, probably male, has a tendency to enthusiastically over-communicate. That is, he doesn’t shut up and interrupts others. This not only blocks the passage of conversation but also reduces the quality of the time the team spends together. This can be a big problem during a retrospective where the more introverted team members decide that their input should take a back seat. In the cold light of day, this just means information is lost — and this should not be tolerated lightly.
The problem isn’t “owned” by the over-communicator, however. The adversarial style of a courtroom works because the judge carefully directs the time and focus of arguments. It doesn’t matter if one lawyer is correct, or is more charming; once on their feet arguments must be focused, to the point, and time partitioned. The team, probably through the team leader, has a responsibility to moderate all meetings. If you can’t manage one vocal team member, then the hard slog of making products against the tide will seem really difficult. A team meeting isn’t a comfortable 18th-century Parisian salon; it is a place of work. Sorry.
Teenager with the Car Keys
Most of the problems with teams are disruptions of trust. When someone is managing a system, they may become perturbed by a user who is careless. The typical situation is when a service manager thinks that one of their users is opening too many resources without closing them down afterward. This can lead to the teenager having their keys confiscated.
Ultimately, you have to trust the teenager because that is the only way to breach the experience barrier. And a service is built to be used. Nevertheless, a bad driver is a good test for a system’s bounds. Valued resources should be audited. Nudges, like emails reminding the teenager and their manager of long-term open resources, are a sensible way to manage this. Usually, a bad driver quickly transitions to a better driver — or comes to a sticky end. But a rigid system will eventually snag others. The worst outcome is for the experience with a bad driver to cause a system administrator to lock more young drivers out.
Having to grit your teeth to push through a teammate’s apparent thoughtlessness isn’t something to ignore — it should just be placed in perspective. Unlike a car crash, software misuse should be neither fatal or too expensive. But it should, of course, be noted.
Under Reporting
This isn’t the opposite of over-communication. This is a self-aware editing decision, made by team members, that their team doesn’t need to hear or won’t value some of the details they know.
One of the common problems in this area is a poor relationship between a project manager and a lead developer. The lead simply doesn’t package issues into the right size pieces to be digested by a busy manager. The lead-over dramatizes small issues and leaves out growing cracks. And the manager is too incurious to cross-check.
But a similar problem occurs within teams, which agile only amplifies if various signals are suppressed. Discomfort, confusion or suspicion about a task shouldn’t be withheld. But these feelings can be hidden by a dry retelling or summary.
Examples include summaries such as “I connected with the database” which forget to add how hard it was to find the credentials, or that permission was unexpectedly needed from a third party. This wastes the time of the next team member who needs the connection. There probably exists an environment where everyone is a hero, so ignoring efficiency problems shows fortitude. But in this case, it just hides the lack of a team wiki or similar information radiator.
Sometimes everyone uses a slow tool, but just assume that is the cost of doing business. So no one brings it up as a blocker. When this type of problem is found, the team needs to play back their actions in time to see in which past retrospective better reporting could have saved the day.
The New Pusher
In most cases, the whole team will benefit from trying new tools or services every now and then, just to understand patterns and trends. We know we should always be increasing automation. However, especially with things like JavaScript frameworks, up jumps the New Pusher — too keen to adopt the new when no evidence exists that the gains are worth the disruption cost. Or worse, ignoring the disruption cost entirely.
The New Pusher can make the team pine for the road not taken, as opposed to do what they should do, and investigate a little on their own time to see how the team will truly benefit from their shiny find.
When thinking about adopting a new tool or service the team should not trial it somewhere inconsequential, as that will be neither conclusive nor beneficial. A short examination or study period should lead to a yes/no decision and the use of the tool or platform somewhere of value. Once the pattern is set, the New Pusher can work to that template.
The suspicion that people just want to put new experiences on their CV is a little irrelevant. The ability to filter out possible paths for solid reasons should be a team muscle, even if the final decision may rest with the lead. A large number of apparent options can definitely be paralyzing, which is why it is vital to quickly assess what you really want from your toolchain, what is possibly missing and what is just hype that you didn’t ask for and don’t need.
Overall, all teams have minor issues that just represent the wonders of working with other people. Sadly, software teams are not mini Leagues of Extraordinary Gentlemen, they are just ordinary people that are asked to excel for many hours a week. This means that eternal vigilance is required, not occasional sleuthing. Yes, the team lead must take the brunt of the responsibility to keep the dynamics right, but they should really act as the beacon. Being a good team is what all team members should be about.
