views:

1578

answers:

20

I'm the lead programmer/manager for a team of 6 programmers. There's always one programmer who needs far more attention than all the others and comes by my office to talk to me as much as all the others combined. Some of these things are unimportant, but some are real questions.

I don't want to tell my guys not to come talk to me, but I need to cut down on the management overhead from this one standout guy.

Does anyone have any suggestions for how to handle this?


edit: to be clear, he's not asking technical questions. He's asking a mix of valid management questions (e.g. "can I take Friday off?"), and time-wasting questions (e.g. "I heard you're playing around with X in your own time, what do you think of the dev environment?"). He just stops by on his way to the kitchen, so I don't get any sort of warning and it's hard to schedule.

I'm pretty sure that talking to him about it is the way to go, but I'm not sure how to broach the subject without making it sound like he can't come talk to me. Then again, if there's another option then I'm all for that.

+15  A: 

Have you talk to him about it? Might be a good idea.

Daok
I think this absolutely has to be part of the solution. I just want to make sure that I don't make things worse as I do it.
edebill
He might haven't noticed and is only not enough confident and prefer to go see you instead of doing an error. Tell him that it's normal to do some error, to come see you if needed but not that much because you have other task to do.
Daok
+42  A: 

Schedule a time for the two of you guys to talk. That will allow him to "save-up" and "write-down" his questions, which might allow him to think about some of them before asking. It will decrease the amount of time he destroys your train of thought, because you'll deal with the questions all at once.

When you get a question that he shouldn't have asked, ask him to "answer it outloud" (to you) and then confirm that he already knew the answer. This will help build his confidence.

Bob
Both of these techniques are taught in management courses. They can be quite useful and apply to any field, not just programming.
Adam Bellaire
Giving him posted "office hours" for non-urgent questions might be very helpful. Maybe I can couple that with a request to put more questions in email instead of making a hard interrupt by stopping by my office.
edebill
+1  A: 

depending on the situation.. you could perhaps implement a 'middle management' style system.. where he (and everyone) needs/shoudl consult with another programmer before coming to you..

ShoeLace
+16  A: 

A couple of things: first, this is probably a sign that he's insecure about something. His job, his skills, or maybe he's just an insecure nerd. If you can figure out why and reinforce him, it might cut it down.

Second, when you're trying to do something, tell him so, and set a time with him for a talk, no later than the next day, same day if possible. Then you're setting a bit of a boundary on your time while still maintaining an open door.

Charlie Martin
Very good answer, building someone up is always better than cutting him down. Vote up for that.
BeowulfOF
+5  A: 

I agree that talking to him might be the first action. But I really think you should try co-locating if possible. If you and your team sit together in a open space environment naturally some questions could be handled by other team members.

Co-location strengthens communication within the team. Maybe this one guy is feeling left out of the team or isn't comfortable with asking the other members.

Another suggestion is to stop giving him answers, try coaching him to the answers instead:

"I don't know but you could look in this or this place to find the answer"

"I don't know but check with programmer XYZ he worked on that"

maz
If he was not already co-located with a senior developer, this would be a great first step.
edebill
A: 

As a manager, it is your job to deal with those sorts of communication issues and how it personally effects you. If you're unable to talk with him or have been ineffective when trying to convey your issues directly, you may want to reconsider your position as a manger. IMHO, remaining open to the possibility that the problems you face may be indicative of a misalignment of your skills and your job description is an important part of being an effective member of any team. IMHO, the first step to becoming an effective manager is being able to disconnect the daily social/human/communication issues from your own emotions and feelings about a project.

ezkl
I'm not going to downvote you, but I don't think the tone of your answer was particularly helpful.
unforgiven3
-1 because recognizing that this situation is problematic and seeking solutions that go to the root causes of the problem IS the sign of a good manager in my book.
Kena
I think that if more people were able to accurately assess their own skills, a lot of problems in the workplace would be nowhere near as serious. It isn't an easy thing to do, but that doesn't mean it isn't positive.
ezkl
Tempted to -1 just for using the corp speak buzzword "misalignment"
BobbyShaftoe
Humans have been "misaligned" with their jobs for far longer than the concept of a modern corporation has existed. It's not corporate speak, it's basic human psychology.
ezkl
So from your perspective, the only time you should take a new position is when you're so comfortable with it that you could cruise through it like an automaton? The best way to grow your skillset is to challenge yourself; this is what parsenome is doing.
cLFlaVA
No, what I'm saying is that *most* people aren't capable of being good managers just like *most* people aren't capable of being good programmers. It isn't common to find people who are capable of doing both *well*. They require unique skill sets and not necessarily the kind you can just intuit.
ezkl
+3  A: 

One of the things I learned in my first manager training session was about keeping your open door policy. If you are not adverse to keeping an open door, by all means do so. However, everyone has a different work ethic, personality and means of finding out information. If you do find someone to be a bit invasive (to put it harshly) or someone who seems to overuse your open door policy, set some guidelines. Make a new policy. "Feel free to come to me with any questions you may have, between the hours of 1pm and 3pm."

You could also play it off as a characteristic of yours so as not to offend your developers. "I'd really prefer if you all would consolidate any questions you have and come to me with a list, any day, between the hours of 1pm and 3pm."

Setting guidelines ahead of time will clarify and vocalize your expectations. If the person still does not abide, you can then address the situation directly.

cLFlaVA
+2  A: 

It sounds like they don't feel comfortable asking their fellow team members. 90% of questions should be able to be answered by their peers before coming to you. They may feel much more comfortable approaching you, unlike the rest of your team who probably have as many questions but sort them out amongst themselves.

In short, this could be a sign of an underlying team problem which you want to talk to the person in question about.

Garry Shutler
+1  A: 

It is his job to learn which questions are important (i.e. a reson to interrupt your work) and which ones aren't.

It is your job to make it possible for him to do this. Therefor he needs a feedback from you, which questions he should ask you, and which ones he should answer himself somehow.

Make an appointment to speak about this with him and agree on a process how you two want to handle this. Regular Q&A meetings which he has to prepare for, as proposed by Bob, are a good solution for this. (I also agree with Bob about the guy probably being insecure. Make it your goal to boost his confidence).

Treb
+2  A: 

I'd suggest a sit down with him to find out why he feels the need to talk with you so much. It could be that this guy is just not a good fit for your organization. Perhaps he just needs more social interaction than he's getting as a programmer and takes to wandering around, finding an excuse to talk to people. In that case, maybe all he needs is to know how disruptive that can be. Or perhaps you could address it by building in some social time -- schedule lunch with him once a week. It could also be that he's trying to be a suck-up and failing miserably at it. The point is, you won't know until you talk to him about it. I'd also check with your other team members to see if the same visitation pattern occurs with them. It could be that is more than just a drag on your time.

If the interaction is truly disruptive, then I would work with him to help him improve either his coding skills -- maybe the unimportant issues are only unimportant to you, perhaps he really doesn't get it -- or his interaction skills, so he understands the cost of his behavior.

tvanfosson
+4  A: 

Speaking from experience, both the managerial side and the developer that needs attention side, I've found that often the driving factor is a lack of confidence on the part of the developer. Seeking answers often give the developer a sense of security that they are doing the right thing and doing it in a way that will not result in negative (even were it constructive) feedback. Perhaps this is a person that, given more confidence would not need assurance from you as often.

You can:

  • tell him that the work he does is good and you trust him to make smaller decisions
  • schedule a time to meet with him and ask that he store up a list questions
  • ask him to answer his own questions to get him to realize he knows the answers
  • make sure he and the team are comfortable with constructive peer feedback
Instantsoup
A: 

As an addendum to ShoeLace's answer, even if you don't want to implement a formal policy of requiring your developers to ask among themselves before approaching you, you could prod your developers towards doing this on their own simply by asking them "Have you asked another developer about this?" every time they ask you a question (unless it is a question only you could have answered from them). If your developers know they will be asked this every time they come to you, they will anticipate having to answer the question, and start asking each other first.

Robert Gowland
A: 

Regular development meetings are good. Either once or twice a week is not excessive. Make the format informal, where you can all talk about new technologies, what you have been reading, do a mini-workshop, etc. You would be surprised with how much your developers have to talk about. The goal is to keep this meeting informal, though. Make it rigid, and it will fail.

As far as things that fall out of scope for random interruptions, such as your day off example, ask for things like that to be communicated via email. It is always good to have a paper trial on that kind of stuff anyhow.

joseph.ferris
A: 

It sounds as if he is letting you take the responsibility for what he is doing by asking so much. The more he asks you, the less he himself is to blame if something turns out wrong. It is important to break out of that behavior pattern.

I would suggest pair him together with another experienced programmer a couple of months to do pair programming. That way you get him out of your hair and he learns from the other guy. You still should meet up with him (and the other programmer) once a week to check progress and feedback. After a couple of months of pair programming he should be ready to take on own responsibility.

Anders K.
+3  A: 

Every developer is different. It is your job as manager to help them be productive. Nothing you said seems out of line to me. Some people need more "managing" than others. Some of he best and most productive people who reported to me needed 10 times the attention as the other team members. That is the nature of people. I didn't mind it. It is part of the job description.

If you feel some things are not appropriate for work time, then say so, but do it in a way that does not make him feel that he can't talk to you about other things. It is a risky proposition and in the case you mentioned I would probably refrain from checking this person.

You might consider an answer like "let's talk about that over lunch" or something if it is an issue unrelated to work. Or perhaps tell him you will talk about that another time/later.

Why do you feel you need to cut down on the "management overhead"? That is your job - as you stated in the beginning of your post.

If you really need to change the behavior you can let him know that you also have technical work and he can come to see you during "management hours" for some set of issues that are not pressing. Let him choose the immediacy of the issues. If he is still out of line then talk to him, but gain, I think you are blowing it out of proportion and that is the job of a manager.

Tim
A: 

Sounds like he is lonely, especially if you have an offices or high-cubicle wall culture, rather than an open-plan office structure.

He does need to realise that he can't interrupt you whenever with trite trivial chat, however maybe you could do more to be available outside your office at other times. Regardless, once you've been interrupted you'll take 15 minutes to get back into work, so you might as well pop out to get your coffee at the same time as him, chat to him throughout, and hope that it means he will interrupt less at other times of the day. You could drop in hints about your impending deadline and you're hoping to get a quiet afternoon to get the work done, but how you bet that will be when HR start sending those "who parked in the CEO's parking space" emails, etc. I.e., you're hinting "don't see me this afternoon" whilst trying not to make him feel bad.

If he doesn't get it then, you've got a bigger problem. You will just have to firmly tell him to stop interrupting you whilst you are working unless it is important.

JeeBee
A: 

Close your door when you're working on something. If you don't have a door, get one, see http://www.joelonsoftware.com/articles/fog0000000068.html

Explain to the developers a closed door means non-emergency requests should queue (probably via email) and will be delt with later. Tell them that they too can close their door and it will let them concentrate.

When I worked in a cube farm in a previous job, we used headphones to accomplish the same task: if someone was wearing headphones, they were working, and you shouldn't bother them. Be sure to have regular breaks together so it's easy for people to reach you, however, and you'll be set. (Half the time I wasn't listening to anything on my headphones, btw)

Daniel Papasian
+15  A: 

It seems to me like you have a relationship problem. Jumping right to a technical solution, like official office hours, without dealing with the underlying problem means the next conflict is no likelier to be resolved smoothly than this one.

As a positive step, I would try a direct conversation, but bracketed by "hamburger buns"--the beginning and end of the conversation are soft, the meat is in the middle. So, for example, "JimBob, I appreciate that I always know what is going on in your part of the project [choose something real here, preferably related to the topic]. However, I need blocks of time to get my work done and you ask me questions frequently. I'd like to stay in good communication with you. How can you get your questions answered and still leave me time to get my work done?"

This opens the conversation. The result could be any number of things--weekly one-on-ones, a commitment from JimBob to ask colleagues, a tearful confession of how ignored he felt as a child.

If the behavior continues even after this conversation and a commitment to change, then it might be time to bring numbers into the conversation--"Last week you came into my office 43 times. Of those visits, 12 were related to the project. I'd like to stay in communication with you and I'd like you to be effective, but this communication pattern interferes with my ability to do my work. What are we going to do about it?"

Kent Beck
A: 

I've dealt with this exact problem.

My solution? Do it back... Every time he starts a conversation, just talk and talk and talk until he is so sick of the conversation that he finds a way to get out of it.

A question about a change in his working hours? Get out the employee handbook and read over the whole section about it. Then talk about the reasons why that policy exists, then talk about how it can be bended or modified, then talk about one time when you had to do that, and then talk about how you can totally understand his situation, and get all the details about what he's going to do with his time off... Oh, your mom's in town? what's her name? what does she do? where does she live? what's it like there this time of year? What are you guys going to do together? Do you have any brothers or sisters?

Just don't stop.

After a few sessions like that, he's likely to stop initiating conversations unless they are really important.

Good old table-turning solves a lot of problems.

Another tactic:

Just take control of the situation with a simple "Can we talk about this later?" in a polite tone.

"Hey man! I heard you were playing with the Entity Framework last night.. What do you think?"

"Hi, Rory. Can we talk about this later? I'm in the middle of something at the moment."

"Ok, man, see you in a bit."

... 15 minutes later ...

"Hey dude, so how about that Entity Framework?"

"Oh, that... Yeah, sorry, I'm still busy with this. I'll come by your desk when I'm done."

... 45 minutes later ...

"Dude, man that thing you're working on must be really intense. You've just been working, working, working! Whatchya working on?"

"Yeah, man... It's intense, and too involved to explain right now. Talk to you soon."


This will get decent results in the beginning.. A few days of interacting with you like that, and he'll stop bugging you for a while. But it'll start back up again.

The first method I mentioned works much better.

Troy Howard