How to deal with a competent developer having trouble maintaining his productivity?

Question

I'm the team leader for a small team of software developers (4 people total).

One of my team members has been in the company for 4 years (came in directly after college) and is an extremely competent developer when he is productive. The thing is, his productivity will wear down in the weeks/months during which the project takes place.

Typically, the team will be assigned a new project and he'll be bubbling with ideas, be a very proactive element of the team, and generally be stoked about the new tasks at hand. But when the project is not as "fresh" anymore and the general needs of the client have been understood, when things mostly need to "get done" and the routine of the development phase settle in, his productivity will decline when most others in the team reach their cruising speed. He'll start arriving late, spend most of his day being distracted or daydreaming and things that could get done in a few hours start taking him a few days.

Now he's generally pretty upfront about it and there have been times where he'll come up to me and say, almost word for word, "I haven't been able to get work done today, I need you to be on my back tomorrow to make sure I'm productive".

So I've tried, as instructed, to be up in his business; checking with him every couple of hours to see if some advancement has been made, popping up behind him to see what he's currently doing, reminding him that he needs to get things done when I see him in the breakroom, etc. I don't like doing it and I don't always have the time for that level of micro-management. It doesn't really work as intended, as his productivity will not improve that much for the time I have to invest with this method.

I've tried a few other things:

• Pair programming with a junior member of the team
• Giving him the hardest problems to resolve instead of regular CRUD to stimulate him
• Giving him daily objectives to create a permanent sense of urgency
• Try to challenge him, as he is quite responsive to having his abilities being questioned: "I bet you're not able to program said functionality in less than X days!".
• Sometimes, the payment of a pint at the next after-work to the "winner" of the bet might be put on the line as further incentive.

All of those work fine for a few days/weeks, but eventually he'll become apathetic and unmotivated once again.

Now if you think of the project overall, his performance is still average to good, but it feels like he could do so much better and become one of the best assets of the team if only he could keep the same level of commitment to his work during the entirety of the course of development.

He is aware of this as well and would like to better himself. He uses various "tricks" to try and stay focused (pomodoro technique, anti-smoking wristbands to "slap" himself when he realises he's not focused, asking his colleagues to tell him when they notice he's getting off track...). He's even gone to see a doctor to check if he has some form of ADD, but it is not the case.

I've thought about referring this to upper management, but I don't know what good it could accomplish. As stated, when he is focused on his work, he'll be able to get a lot of work done quickly, which generally compensates for the low percentile of time that he is actually productive. Even though he could do much better, I still consider him a relevent asset of the team.

Is there anything else I can do to try to prevent his work ethic from decaying during the "routine" development phase of the next project?

Answer 1

I have similar issues, as do most creative and talented people I know. We enjoy the thrill of the challenge that a new project provides. It gets our mind working on solving big picture problems, the rewards are immediate and there is a lot of great positive feedback that keeps the engagement high.

When you get into the meat of the project there is much less positive reinforcement possible. Its our job and we know it, so mindless "You are doing a great job" type compliments tend to actually demotivate me during the grind. Because I am not doing a great job, I am doing code monkey work... granted that is part of my job, but its not the great part, really almost anyone could do it.

I find the less time I have to do the work the easier it is to focus on getting it done. If I have 3 weeks to get something big done, I will probably futz around trying to find the "Best" way to get it done then knock it out in a few days at the end because I no longer had time to think about it.

So instead of large action items reduce them to smaller tasks that can be accomplished in a few days. And increase the workload, but with tasks that are not action items for the project. Add in code reviews, maintenance tasks, consulting with other teams on other projects, internal quality improvement projects, etc. These things tend to increase the engagement of creative people and even if the engagement is not about the project specifically it gives us the energy to focus and get things done.

Now you have actual things to provide positive feedback about. "Hey thanks for your help on the TPS report project!"

Another thing that helps motivate me is collecting points in an agile development environment. I know agile is not a score thing, but that is really to keep management from grading by the score. It is a valuable internal score for self validation. Its actually irrelevant mostly for the business. If you think of it as a level in Super Mario, It doesn't matter to the business how many coins are collected its just that you get to the flag at the end. But to the player those coins help us to stay motivated to get to the flag. They are minor objectives that provide that reward that helps keep us moving forward. Story points do the same thing. Minor rewards that getting or not getting do not really matter but provide us with that immediate reward and inner score keeper that helps us feel that productivity. Please note that when management starts using these points to track productivity it loses that minor objective status that makes it a valuable motivator and gains status as a system to game to fake productivity instead of actually being productive.

Answer 2

It sounds like your developer has a problem with what is called "executive function". I have the same problem. Put simply, he can get the job done but he can't manage himself. I'm getting treatment for it.

What helps from management perspective is tight deadlines and goals as well as repercussions for not meeting them. It sounds almost counter-intuitive, but this is one of those rare cases when cracking the whip actually makes the employee happier. The daily requirements help, but unless he pays a penalty for missing them, he'll slack off. He probably doesn't have a conscious control over this.

Be a bit of a hard nose, if you can. Sometimes you have to be cruel to be kind, this may be such a case. (Apologies to Nick Lowe for shamelessly referencing his song)

see if this sounds like him

https://www.understood.org/en/learning-attention-issues/child-learning-disabilities/executive-functioning-issues/understanding-executive-functioning-issues?gclid=CLfw9sak_9QCFUK7GwodDTwNGw

If he does have executive function difficulties, getting that treated could make life easier for everyone concerned. Since he seems so open with you, talk to him about it. From the tone of your post, he seems cognizant of the issue and may be willing to dive into treatment.

Answer 3

If this developer is as good as you say, then let him do what he likes.

No, I don't mean "leat him dream all day", but find out what he likes - designing or finding the technologies or whatever - and mostly make his job around doing that. Presumably your company has more than one project on the go at the time, so he can spend more of his time doing the things that gets the company the most value for their money.

Same as other developers - same as other people, really. All people like doing different things - we just think some things are boring because we don't like them, but it doesn't mean other people look at it the same way.

Back on the topic - it seems you're doing CRUD or what have you, well, there are technologies out there that eliminate a lot of the tedium of that (jHipster+modelio, say) - why not set him on finding out about this stuff?

Also, I've found that getting people interested in doing code quality (eg removing errors from the log file, cleaning up slopp code, making things neater) often gives developers the break from the tedium of "build this CRUD", because cleaning up takes some creativity but not a lot of effort.