Imagine a project where the "deliverable" is a baby. Once a woman gets pregnant, the delivery time is extremely predictable, right? 9 months, on average, with some slight variations, of course, after all every project needs some risk mitigation.
Replacing team members
Meet Juliana: she's 7 months pregnant and ready to deliver Lucas to the world in about 2 months.
Meet Amanda: she's not pregnant.
Then, Juliana gets a phone call:
"Hi Juliana, we know you've been on Project Lucas for 7 months, but we need you on another more important project. Amanda will be replacing you on Project Lucas. We know that she's not pregnant, but don't worry, we will make sure we have enough handover so that Amanda can still deliver Lucas on time"
It is quite clear that Amanda cannot deliver a baby in 2 months, she's not even pregnant. Even if she gets pregnant straight away it's still not possible to deliver Lucas in the expected timeframe. As a result Project Lucas will be delayed.
Baby/Knowledge Transfer
There was an assumption that the 7 month pregnancy could be transferred quickly from Juliana to Amanda. When we talk about a baby it is quite visible that it's impossible to transfer Lucas from one mother to the other and still deliver it in a certain date. If you, like a friend of mine who is pregnant, thought that talking about transferring a baby is "wrong, distasteful and ridiculous", I have to be honest that this is exactly the kind of reaction that I'm looking for. There is something completely wrong with treating people as replaceable units and that is what I'm trying to express here. The ridicule of transferring a baby was the closest way I could find to convey the message of not treating people like people.
This comparison to pregnancy is an "outrageous oversimplification", just like in the famous and so quoted Brook's Law: "Nine women can't make a baby in one month" coined by Fred Brooks in his book The Mythical Man-Month.
Usually when a team member replaces another on a software project, for example, we have some time for Knowledge Transfer, which has to be planned carefully.
Wikipedia: "Knowledge transfer is more complex because knowledge resides in organizational members (...)"
Skills and knowledge take time to be developed. Much longer than babies, in fact. Some take years to be acquired and perfected. In the case of Juliana (pregnant), being replaced by Amanda (not pregnant), there is a handover time that needs to be taken into account and it's dangerous to underestimate this time. The assumption that one can replace the other without much of an impact is unrealistic. The impact of one team member to a team can be as significant and underestimated as the flapping of the wings of a butterfly.
When replacing a team member, it is extremely important to take into account what is the contribution of that team member to the team to which they belong and not just look at them as a replaceable unit: a resource.
The snowflake team member
Treating team members like a replaceable unit or a resource is problematic because it gives the perception that if you have a Senior Java Developer, for example, they can be replaced by any other Senior Java Developer and this will have no impact whatsoever on a team.
To paraphrase Frederick P. Brooks, Jr., I would say:
"Our staffing management techniques fallaciously confuse roles with team contribution, hiding the assumption that people with the same roles and seniority levels are interchangeable."
From my experience, that Senior Java Developer has so many other unique skills that are not possible to be boxed into a role name.
To borrow the metaphor used in DevOps about avoiding snowflake servers, when it comes down to staffing people on teams we do need to look at them like snowflakes. Each team member has a unique skillset that helps achieve a shared objective.
These skills go beyond their roles, they can be:
- Relationships with the other team members
- Domain knowledge
- Internal specific frameworks relevant to certain teams only
- Any other intangible benefits
What should I do then?
It is almost impossible and not ideal to keep everyone on the same team forever.
I usually get the question:
"What should I do then if I need to move people around teams?"
The most important thing is not to treat people like replaceable units that are entirely represented by their roles and can be just moved around like chairs, desks or any other physical resource. Here are a few things I usually do which help:
- Ask other team members what skills that particular member brings
- When changing the staffing of a team, there is always an impact that needs to be taken into account
- Stay close to the team members that you are managing so you can get to know them better, their current skills and aspirations
- Look at each team member as a snowflake, a unique person whose skillset is based not only on their role description, but on an entire life of experiences
- Refer to people by their names and skills:
- Saying: "Our developer Paulo is going to move to another team and we have to find someone with equivalent skills" is much better than:
- "We are losing a resource that needs to be replaced" - this makes you sound like one of your desks broke.
Further reading
- The Magic and Science of Teams by Mark Levison
- Management 3.0 by Jurgen Appelo
- The Mythical Man-Month by Frederick P. Brooks Jr.
- Snowflake Server by Martin Fowler
- Peopleware by Tom DeMarco