What to do? A team member spending a lot of time on the phone
An example with action points
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
The root causes of low engagement from a team member can vary immensely. While thinking about what to write today, I remembered a pre-pandemic story, from a time when everybody was stuck in an office all week.
How the story begins
The story is about a newly appointed Team Leader who shared with me a case about how she was managing a developer who was constantly on his phone, answering calls all day instead of advancing the work assigned to him. This was indeed a major red flag, but we both had different views. From her perspective, she was dealing with a lazy developer who needed reinforcement and some pushing to get work done. My perspective was that the root cause of his low engagement needed to be assessed before taking any action. The first step would be to have a conversation with the developer to understand what’s going on—starting with “why” before moving to “how.”
The Developer’s feedback
Eventually, a conversation with the developer took place, which I wasn’t part of since the scenario was outside my scope and team. However, as someone looking from the outside and based on the feedback I received from the Team Leader, the developer wasn’t enjoying the work. The codebase was too legacy-heavy for his taste, and the technology stack was too outdated for his CV to gain value from that particular project, among other reasons.
Unfortunately, the Team Leader persisted with her approach of “whipping” the developer for his low engagement instead of addressing the root cause. She continued sharing the complaints that the developer was spending too much time on the phone. She was treating a grown man with years of experience in software development like a small child whose phone time needed to be controlled. This, unfortunately, can happen with newly appointed Team Leaders who lack proper training or regular coaching. In this case, she was receiving neither training nor coaching from her direct manager.
The root cause
It turns out those phone calls were from other companies scheduling interviews with the developer, and that screen time was the poor guy trying to fix his professional life by sending CVs everywhere. The developer was using his phone a lot because the company’s policy blocked most typical job-search websites. The Team Leader was surprised by the developer’s resignation, and I was surprised to see her so shocked that he wanted to leave—two surprises for the price of one. Of course, this developer was going to leave, and of course, treating developers like small children isn’t a good strategy for managing a development team. However, she didn’t know any better because no one was training or coaching her.
What could be done differently?
Let’s assess the feedback and the signs. The first one that caught the Team Leader’s attention was someone constantly picking up personal calls and spending a lot of time on the phone. This alone could signal a lack of interest or a personal issue. It’s easy now to understand the reason for those phone calls, but back then, no one took the time to sit with the developer and figure out what was going on—they only pointed out his bad behavior. It became clear after the developer decided to leave and came clean about what was happening.
It’s difficult to assess root causes based solely on behaviors, so if a developer is experiencing a drop in performance or a series of unusual events, the proper approach—rather than playing a guessing game—is to have a conversation with them before resorting to corrective measures, ensuring the nature of the situation is understood first.
When finally the conversation happened the feedback was more resourceful. The first feedback was the work was not enjoyable, since the project turned out to be different from what was presented to him. What could have been done here? Asking a series of probe questions:
What are the aspects of the project the developer enjoys the most?
Why the project is not aligned with the expectations?
What was missing from the project description that could avoid this reality gap?
The feedback from this situation could vary widely—from unmet developer expectations to differing perceptions between the developer and the Team Leader about the project. However, the key is to understand why the developer finds the project unmotivating and to explore what a Team Leader can do to make it more engaging for them.
The developer also has responsibilities
One aspect of managing software development teams is that good developers are continually concerned with keeping their CVs updated with modern technologies. This is because the IT landscape is highly dynamic—developers switch companies easily, and an impressive CV opens doors to more exciting job opportunities with better compensation. Even the most conservative project managers and corporations need to be mindful of avoiding an outdated codebase or obsolete technologies that no one uses anymore, as this risks failing to attract top talent. Managing a technology stack is a separate conversation altogether, but the key takeaway is that projects will always need good developers, and good developers feel compelled to work on current technologies to prevent their CVs from losing value.
In this specific case, the developer knew the technology stack beforehand and should have understood what he was signing up for. Any developer should ask questions about the project and not hesitate to inquire about how technical debt is being addressed. In reality, developers don’t do this enough, and situations like this often arise in teams dealing with significant legacy code.
The project should be attractive to good developers
From the perspective of someone leading a team with significant technical debt, the team should prepare and implement a plan to improve the situation—not only to reduce team turnover but also to mitigate risks tied to obsolete components. Managing technical debt might be one of the most challenging aspects of software development, as the team must justify investing in something that’s already working. Yet, it’s essential. I’ve seen software fail in production due to a simple MS Office update. I’ve witnessed security vulnerabilities uncovered that threatened entire systems. It only takes one bad day to force weeks or months of development effort just to patch something that could have been addressed more effectively and seamlessly with proper planning.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message on Substack.
Cheers,
Artur