“Bob, we need to talk. I’ve been reviewing the check-in histories, and Steve hasn’t bothered to check in anything in the past 6 days. When he does check-in, his quality is just utter crap. I don’t know what happened, but I’m tired of dealing with him and his slack attitude.”
We’ve all had team members that are hard to deal with. In my last post I mentioned that we need to respect our other team members. But is that where it should end? Do we merely just need to acknowledge them as humans?
When we work together as a team, we bring together people with different skill sets, different personalities, different learning styles, and different wants and desires. Bob above may be passionate about building code, and is willing to sacrifice personal time to do that. Another developer on the team may be passionate, but is more passionate about his home time, and rarely sacrifices that. A third may be just using the job to pay the bills to fund his real love of music, art, motorcycles, crafting, or whatever.
When we make blanket statements about development teams, we forget to take these individual attributes into account. Indeed, even as individual developers we forget to take these into accounts. The struggle you see in someone else might not be technical. Steve might not have a slack attitude – he might be going through a divorce, or a sick kid, or a variety of issues.
So what has this to do with compassion, and more importantly, software development? Technically, perhaps little. But from a team dynamics perspective, it is a key tenant to growing a team. You don’t have to attend a team member’s kid’s Little League games, but understanding that something is causing them to not be able to focus on the task at hand can help them get past it.
As an example – we had a team member in a previous job whose child was sick. They had taken time off to try to handle it, but it got to the point where it was impacting their work, and they were running out of sick days.
One response would be simply to be disinterested. After all, it’s a personal problem, and they need to deal with it. But a compassionate response is to try to find out what you can do to help. From a peer perspective, it may be just going up to them and saying, “Hey, I noticed you seem to be distracted lately. If there’s anything I can do to help, let me know”. As a manager, you need to provide them with the comfort to come to you.
In our example, the team member did come to us, and we were able to work with them to come up with a schedule where they were able to focus on their child getting better, but also to still get done what they need to get done.
The other team members responded in kind by helping to define their work, provide assistance where needed, and generally respond as a team would to protect their team and provide an environment of compassion.
Compassion also comes into play with foundational changes. When you shift the fundamental way people work you have to be concerned about two things. The first is the response to change – do they understand the new roles? Do they understand how they need to work?
But the second is more primitive. Does their personality, who they are, make it difficult to work a certain way? If you have someone who thrives on doing one task at a time, in a siloed fashion, how do you incorporate them into a dynamic, collaborative environment? What opportunities do you present them to prepare them?
Obviously at some point, compassion turns to altruism, and then at some point it becomes charity, and you have to make a hard business decision of whether or not you need to keep someone with the team. If they can’t adapt, and there aren’t roles to slide them into, you may have to let people go.
But in our day-to-day activities, we need to be aware of when our teammates are struggling, and offer support to them. It may not be technical, and it may not always be easy, but the impact it has to growing your team will be worth it.