How To Help Unmotivated Developers
A practical guide
Some time ago I wrote about why highly motivated people seem to lose motivation and what can managers do to prevent it.
In today’s article, I’d like to share an experience I had as Engineer Manager (EM) working with a developer who had completely lost all motivation and engagement.
Being the new manager
At some point in 2019, my manager asked me if I could take over the role of EM for a team that had been without one for a couple of months. My manager told me they were having some delivery issues and although it was nothing major, they would benefit from having an EM. At first, it seemed like a good opportunity for me because I would be leading a very different team than I was used to since it was a 100% back-end team dealing with infrastructure mostly. On the other hand, I hesitated because I knew that team had been through many different managers in a short period of time so I sensed it could be very challenging. Eventually, I accepted.
My manager announced to them I would become their EM and I was left to it. In the first week, I set up 1:1s with all developers and also with the Product Manager so I could start getting a sense of the status of the team.
The 1:1s
Although I knew the people on the team because we had been working in the same area for a while we weren’t very close and the initial 1:1s were a bit awkward (as normally are). As I started meeting them it came clear that the team was struggling with not having a clear vision and a scope that was all over the place, making the Product Manager frustrated and the developers somewhat angry. All in all, it was kind of expected.
Then, it was time to meet with the last developer on the team. Pretty much 5 minutes into the meeting he said “I’m going to start looking for a new team. To be honest, I don’t really want to come to the office in the morning”.
As an experienced manager, my first thought was *Shit. What do I do now?*
Bringing them back
How do we bring someone back from that place into a place of motivation, and engagement, and actually enjoying what they do? And should we even try?
Of course, if that person had already completely made up their mind about leaving they should totally go. But I think that as managers we have the responsibility of trying and helping them.
1. Acknowledge the situation
There’s no point in denying that that person was feeling low and disengaged. Saying things like ”Come on, it’s not that bad!” won’t help at all. What I did was thank them for being honest: other people could’ve just said nothing to the new manager and two weeks later announced they were leaving, and I wouldn’t blame them.
Then, I acknowledged how they were feeling and that I understood it, and offered my help. If they wanted to give it a shot, I was there, but if they didn’t, I wouldn’t push it.
2. Let them vent
People who vent are, in many cases, not helpful and can end up creating a toxic environment. But allowing someone to vent once and take everything out of their chest is very important. I asked why he was feeling that way and he went on for several minutes about how he struggled with the previous manager and how while said manager never provided feedback at all, in the last performance review they gave this developer a subpar score with claims that he has had communication and stakeholder management issues.
He clearly was frustrated and angry, and I could understand it because I could see how unjust that situation had been.
3. Ask them to reflect
Since I had asked him if he wanted to give it a shot at fixing this and he said yes, I pressed on. I asked him if he agreed with some of that feedback.
Once he had finished venting, he seemed a bit calmer, and now with the frustration out of his chest, he was able to reflect on the feedback. Just because the previous manager didn’t manage it in an optimal way, it doesn’t mean the underlying issues were not true. He thought for a while and eventually, he owned it: Yes, when collaborating with team X the communication wasn’t the best and it was hard to get their requirements, which made the project take longer than expected and I didn’t communicate it well.
That was a great moment for me because I could feel that he was taking my questions and my process seriously and because he showed trust in me as he could’ve easily not answered the questions with honesty.
4. Set the right expectations
Once I knew that he acknowledged some of the issues, I knew that we could work together. But it was very important to me to make it extremely clear that I was not interested in arguing about the feedback from the previous manager or how he acted and I was only interested in improving those areas.
I explained to him that I couldn’t speak for how the previous manager behaved because I didn’t even know him and regarding the last performance review’s score, I was not interested in discussing if it was right or wrong. It was what it was and we couldn’t change it. I explained that my goal was to work on those areas he acknowledged he struggled with and improve the score on his next performance review.
He seemed very receptive to those expectations and he thanked me for the honesty. We managed to change the vibe of the first 1:1 from a negative one to a more positive one, and we managed to clear the air.
5. Get them involved, and get yourself involved
With the air cleared, when our next 1:1 arrived, I thought there was no point in wasting time and I moved into working towards our newly set goal. So I asked him to describe what he thought good communication and good stakeholder management were, and then I would share what I thought they were. It is known that, especially in big companies, the performance criteria are loosely defined and open to interpretation, and in my experience, they are always a friction point with people because they interpreted something one way and their manager differently.
By asking him what he thought those things meant, I was able to get him involved so he didn’t see those expectations as being pushed to him but defined by him and, also, I was able to gauge how close he was to what I, as EM, consider those things meant. And by sharing what I thought those things meant I was able to show him that I would not be taking a position of evaluating him from the outside but that I would be working with him.
We were not far off and with a short discussion we were able to agree on a list of behaviors of good communication and stakeholder management that satisfied the expectations of both of us.
6. Let them do the work, but don’t be passive
Once we had that list of things to work on to eventually improve the areas he was struggling with, I asked him to think about what he could actually do to make improvements in those items, and that could be from reading certain books to sharing a weekly written update with stakeholders to working less in isolation and communicating his decisions earlier.
Coming up with these things and executing them was, of course, something that happen over the course of weeks and months and something we discussed weekly in our 1:1s. And although he came up with most of those things, I didn’t sit there just looking what he did. I took an active role in challenging his ideas, providing feedback every week and sometimes suggesting things he hadn’t thought about.
The last part is something I have discussed with managers many times. I think too many managers take a passive role in working with their teams as if their role was merely the role of a referee who decides if what they did was right or wrong. I think our role as managers is more like a coach: the coach doesn’t do the work for the players but they do share their point of view and use their experience to help them better themselves.
Wrapping up
This turned out to be a successful story. Eventually, this developer improved and was rewarded with a positive performance review score and he went on to continue improving.
Personally, I consider it a success story not only because of the score in his next performance review but especially because of how we managed to turn around a very negative situation into a positive one.
If you found this article useful, please consider clapping and following. You may also be interested in checking out other of my articles: I write about software development, management, and leadership.
