How do I deal with a subordinate that insists on providing too much detail?

Question

I have a junior developer that has become a drain on my time.

Several times a day, he either stops by my office, or grabs me as I pass by his (his office is centrally located, so that I'd have to walk through several other people's offices in order to avoid passing his), to "ask for my help". However, frequently there are no questions involved. Instead, he provides me with a detailed list of every task he's accomplished recently, every problem he has run into, and, if he's already resolved an issue, exactly what he did to solve it, including detailed descriptions of the syntax he used and explanations of how new language features he discovered work.

If I try to leave his office before he's done (e.g. when he finishes describing foo, but hasn't started talking about bar yet), he'll continue talking as I walk down the hall, or sometimes even get up to follow me into my office.

We do a code review on each other's code every time we check in to source control, so he knows I will take a look at his code even if he doesn't tell me about it.

I've talked with him several times about this, explaining that if he doesn't have a question, or a problem that he is uncertain how to address, he does not need to tell me about it. Each time, he has apologized, and said that he'd work on that, but within a few days he's right back to providing multiple detailed descriptions of everything he's already done.

I want to be an approachable resource for him, as part of my responsibility is to provide him guidance and help him grow, but the insistence on describing in detail tasks that he's already resolved is a significant drain on my time.

Aside from telling him that he only needs to talk to me about problems or questions (which, even with frequent reminders, simply doesn't work), I've taken to walking him out of my office to end conversations, which has been somewhat successful, but he still grabs me as I walk past his office several times a day, and it can be 5-10 minutes before I can even tell if he's got a question.

I've offered to give him a 15 minute daily stand-up meeting each morning to give me an update, but that didn't change his behavior at all; it just gave him a guaranteed platform in addition to whenever he decided to initiate other conversations.

Short of continually saying "is there a question coming up?", is there a professional way to approach this?

I'm the lead dev and project manager, in charge of the department.

Answer 1

Here is a professional way to address it. Next time he starts his explanations, again point out that you don't need to hear this level of detail, and say that you've told him that before. And then ask if there is a reason why he keeps coming back to this behavior anyway. Make him explain why he insists on telling you details that you've both agreed are not necessary.

We have already discussed that I don't need to hear this level of detail. I do want you to come to me with questions you can't figure out, but if you've figured it out, I trust you to do the work without my input. And yet you keep coming back and telling me details I don't need to know. Is there a reason why you keep doing this?

And then be quiet. Let him answer. If it's awkward, it will help him remember so he doesn't continue.

Another option is to word it slightly differently, and ask if he's able to quit asking for input.

We have already discussed that I don't need to hear this level of detail. I do want you to come to me with questions you can't figure out, but if you've figured it out, I trust you to do the work without my input. And yet you keep coming back and telling me details I don't need to know. I would like you to only come to me when you actually have questions and need my help. Can you do this?

Again, be quiet. If he says yes, then remind him of that next time he fails.

You need to train him to stand on his own feet. You need to be direct (not harsh). If he sees you are trusting him, eventually (hopefully) he'll learn to trust himself.

Answer 2

One thing that might be a feasible solution is to ask him whether he can provide these updates through email. This has multiple advantages:

1. It creates a document trail so you can track progress and easily see whether there is evolution in how much he can do and how many problems he has;
2. Reading text is faster than listening to someone speak;
3. If you don't have time, you can simply ignore it;
4. you can tell him to limit his email to a certain amount of lines so he's forced to keep it short and simple;
5. it's asynchronously, so you don't need to both be available.

---

Mindwin actually made a very good comment. Instead of sending an email, another good option would be to turn it into a wiki. That way, you don't need to rely on email documents to keep a record. The wiki can be edited by anyone, and the subordinate can be as detailed as he wants.

Answer 3

These are classic traits of a person with asperges (aka mild autism), I know this because I am and also a sr dev / technical lead. He is showing signs of what some neurotypicals call data dumping. If he is hyper focused on tasks given, and shows a great deal of focus on the details on top of if he has troubles maintaining eye contact for a very long time when he is conversing. Are all signs of mild autism, it's very common with developers. He most likely values your opinion on his solution to problems given to him, and simple code reviews/testing feedback doesn't really satisfy narrow focus of details and confirmation from his peers who also share the interests that is coding.

I'm a tech lead mostly now and do what sounds to be the same as yourself, but for me however to be more functional and not so akward I work remote 90% of the time. If possible, allowing remote work may help.

But ultimately the best is being direct with him about it but consider the fact he could be looking for guidance and approval from you. So positive feedback such that is constructive criticism is best approach to take. But as someone else mentioned in a comment that documentation would be best way to solve the problem. It's an outlet for him, it's documented (probably too much) and gives you a response when shutting down his chatter with you vocally. But being persistent with halting the data dump and stating for him to put his thoughts down on a document helps everyone better in the end. That way it's not taken as being annoyed while keeping his possible affirmation of you and possibly other team members he may be doing the same with.

https://blog.codinghorror.com/software-developers-and-aspergers-syndrome/

Answer 4

My suggestion was going to be when he grabs you, ask if he has a question he needs a answer to or just wants to give you a update. If he has a question, keep him focused and provide the best answer you can. If he doesn't have a question, explain that you would prefer to receive the update in a email that you can review when you have time.

It sounds like he wont take subtle hints and you will need to be very clear that you do not have time to dedicate to him outside of your formal 15 minute meeting. Be firm, and do not be afraid to stop him with "This is one of those discussions we talked about in our last meeting where you apologized and said you would work on"

He sounds similar to people I know with anxiety disorders, but how to deal with that is unfortunately outside of the Workplace.

Answer 5

The key is to point it out when it's happening.

Get him to pause, consider what he's doing, why he's doing it, and determine what he really is looking for from these interactions.

It may be that he gets really excited about what he's done and wants to share his discovery, learning, and struggles. That's a good thing to encourage, but would need to be redirected to a better format. Perhaps he should write an email to the team with the new learning or document it on a team wiki page.

You want to be careful not to passively let it continue, or passive aggressively ignore him, or aggressively tear/break him down. It's a fine line to walk, but that's the challenge of being a manager.

Answer 6

It sounds like you've already done all of the things that I would normally suggest, such as set a scheduled meeting time to discuss issues, but if he isn't improving at all, there might not be any construction steps to take.

You may have to dig deeper into his behavior to determine exactly why he's telling you all of this to address his problem. Perhaps at his last job, he was scolded by his supervisor for not keeping them in the loop and he is over-compensating for that. This sounds like it is going to take some time from you, but perhaps it would be a good time investment if it keeps him from bothering you.

One thing that comes to mind is to cut him off early, saying that you have an important personal phone call to make, and after a few minutes tell him that you must cut the talk short. (Not sure how many times this will work).

Second, most extreme option if you have the capability, throw someone else under the bus and make him/her his direct supervisor and shield yourself. By putting a person between you and him, it might free you up.

Answer 7

I think it may be possible this developer is simply feeling a lack of perceived constructive feedback, possibly hoping that by explaining his actions you will stop to correct him or give suggestions for further work or improvement.

It might be possible to create a formalized feedback component of your code review process to satisfy this apparent need.

Of course, it could also be as many others have suggested and he is just lonely or unsure of himself. It's possible he is just feeling a lack of progress in his personal development as a programmer and is hoping for more help.

EDIT: I see where you wrote:

I've offered to give him a 15 minute daily stand-up meeting each morning to give me an update, but that didn't change his behavior at all; it just gave him a guaranteed platform in addition to whenever he decided to initiate other conversations.

That's definitely along the lines of what I was thinking, but a 15 minute session in the morning is not necessarily the most productive way to handle it. For me, at least, I haven't worked up a communicable state of confusion over my work until at least 10:30. It takes a little bit of time to get into the programming context. If my boss talks to me for 15 minutes in the morning, I can guarantee I'm not remembering very much of the finer points of what I was doing the day before. Of course, you could take a stand here and require him to prepare notes for this meeting the afternoon prior.

Answer 8

What worked for me

• Set up regular 15-20 minute status meetings for a certain time (e.g. 2-3 weeks) with him, and ask him keep back his question until then or them to figure them out. Insist that ghe keeps this schedule

• Accept his solutions, even if they are not perfect. He needs to grow self-confidence that he can solve a problem and make a decision.

Answer 9

Some useful phrases you can use every time:

• "Lets discuss it this Friday",
• "Can you prepare a report with that? I will check it later",
• "Ive not checked it yet, give me this week",
• "Yet not checked, I've been busy",
• "Did you talk it with Bob?",
• "How is your family?".

And some solutions: - Make a weekly time frame for checking, - Conduct other worker of your to be his checker, - Talking about other topics, not only code.

The key is him to realize you are a busy boss, not a free colleague. And always framing time in weeks, hence you have days of pause for these topics.

This is a problem of discipline. You can talk about that on Friday but not on Wednesday, so he learn he has a weekly time frame for solving those problems with you.

Answer 10

As a senior dev and his manager, listening to your subordinates is part of your job. You know how much detail he provides, so by saying yes to going over, you are essentially saying yes to that much detail.

You think something takes 15 minutes but in his mind apparently it takes longer. So my suggestion is:

• Ask him how much time he needs
• Take out exactly that amount of time from your calendar and sit down with him. When the time ends, leave.

If you find out that you personally don't have this much time, then either find someone else who does or fire the guy. Keeping an employee without meeting their needs will make you and them miserable in the long term.

Answer 11

If you are in academia, having him write a paper would be the perfect outlet for his detailed information. Otherwise I would suggest a developer blog, for example on GitHub Pages, which is very quick to set up and already benefits from version control.

Answer 12

One thing I don't see in other answers is that it is part of his job to filter information, especially since he holds a junior position. Eventually, he will need to have good intuition for what is important to tell others; currently, his value to the group is soaking up less intensive tasks so that more senior developer have time for larger tasks. In the future it will be necessary for him to determine how interesting each component of a project is when communicating successes and challenges.

Maybe you should focus on helping him there, guiding and constraining him in order to learn how to filter down to what's important. Since he is less experienced he will get it wrong sometimes, but it's​ up to you to make sure he can become progressively less dependant on your experience.

Answer 13

As an expansion on the email modus operandi, make him use a FORM!
As in: a formalized fill-out-form with two main categories:
a. status updates
b. stuff that can't continue without your approval (he needs stopgap tasks for this to be efficient and not waste time waiting on you, though)

c. Don't add an 'Urgent'- category .... on purpose!

Answer 14

This sounds like a very unusual situation. Almost extreme. At this point you need to reconsider whether this is your problem. If the employee has had that many reminders, and still can't work appropriately, it is time to involve HR.

Document the extent of the problem. Put it in hours of lost productivity. Set up a meeting with the HR manager. Sit down with the HR manager and the employee, and review the problem. Point out that this is going on his/her file and how much time you've already spent trying to correct it, and that it MUST be changed. Gently suggest that if it is a compulsive behavior that the employee just can't fix him/her self, that assistance from a psychology expert may have to be sought.