Recently, Tim Ottinger posed a question on Twitter regarding the change
in teams and the impact of the change in their effectiveness.
This made me reminisce about some things. I’ve rewritten this post a few times, unsure of how much detail to go into, or whether to publish this at all, but I think at least a few remarks bear mentioning.
I have seen people who accelerate every team they join, and people who put the breaks on every team they join (yes, there is an in-between, but the extremes prove a point). I’ve seen teams swapped whole and the results become “permanently” faster, and I’ve also seen them become slower.
I think the direction and magnitude of change comes down to a few different factors: how the individuals interact with the craft of software development, how they interact with other team members, and how the organization interacts with the software projects they own.
People who respect software development as a craft, would feel embarrassed about making avoidable mistakes and like efficiency in general tend to accelerate software development when they’re included in a project.
People who make their teammates feel comfortable, are willing to learn, teach, and grow together, and don’t feel ashamed of having to learn new things tend to accelerate software development when they’re included in a project.
Organizations with sane rules, specially about developing internally transferable skill sets in collaborators, knowledge sharing, and architectural uniformity tend to suffer less with team changes.
The opposites are opposites, and there’s a lot of nuance that doesn’t fit in this margin, and I can’t claim to comprehend everything completely.
Managers tend to have an big impact in their teams, which should be obvious, but feels worth mentioning. A supervisor who doesn’t know their team, doesn’t teach, motivate, cultivate, and prune their team, makes the company (and the projects the team is responsible for) more fragile.
Teams are bound to change. Requirements change, people move on, people move in. Having every change in the team be a possible cause to a “permanent” slow down in development is a mind boggling, yet alarmingly commonly accepted proposition.
Software development should happen in a way that a change in personnel is more like going trough a bumpy section of the road and less like slashing a vehicle’s tires.
I have sometimes felt that some companies try to treat their employees as exchangeable. This is a liability. Everyone is different, and software should be written in such a way that unique people can bring their unique strengths to the table. This implies, as in any kind of team, that taking care of the composition is crucial. And this goes not only for skill level and skill type, but for attitudes and tendencies. Compare with team composition in your favorite team sport.
*Permanent is in quotes because … well, obviously I’m not looking into eternity. I mean over a period of time when the team has settled into their “day to day performance level” plateau.