Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

One colleague in our team has multiple jobs to do, but he don't focus on the job that is currently the most important. In our team we always discuss the next steps, but he still don't focus on one thing. He always has a reason why he's NOT doing the right thing.
He's with us for 9 month, so we thought this is common with guys newly from university. But the problem gets bigger every week. But we want to give him a chance.

How can we motivate him?
What would you guys do with him?

share|improve this question

closed as off topic by Martijn Pieters, Joel Etherton, thorsten müller, GlenH7, Kilian Foth Apr 6 '13 at 17:35

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

Have you actually told him you have this problem? –  Zavior Apr 6 '13 at 8:53
Does someone tell him the priority and he ignores them? –  jmo21 Apr 6 '13 at 8:59
A very simple measure is to give him one task at a time. With a queue containing only one element he cannot play this game any more. –  Giorgio Apr 6 '13 at 10:33
@joe then he needs to be managed better. If he has responded to team peer pressure, his boss should have a word. If that doesn't work, he should get a warning of some sort for no doing his job. –  jmo21 Apr 6 '13 at 11:10
"One colleague in our team has multiple jobs to do, but he don't focus on the job that is currently the most important....But the problem gets bigger every week. But we want to give him a chance." - Sounds like an unbelievably strange team. I wish him to find a more sane one. –  SChepurin Apr 6 '13 at 11:19

5 Answers 5

up vote 10 down vote accepted

You need to find out what his problem really is. Chances are that he is just not motivated.

There is a good theory behind this called "Flow" by work of Csíkszentmihályi:


I am not expert on that but it is very worth to know. Apart from that:

I have some ideas for what his problems may be but before going into details, I provide a TLDR option:

  1. In the meantime I would opt emptying the task queue to a single task, as some of us already advised.

  2. Working in pairs can also be a godsend; he must of course feel involved in it.

  3. Simply tell him what you do if you have troubles to focus. (He will most likely simply understand why you are telling him this.) For example, what I use to retain focus:

    • make sure that I spend the first 15 minutes of my day with the real part of my work (ie. do not read coworker emails, etc., but do code). sets the mind.
    • close the web-browser. I won't actually need that reference for another 15 minutes, do I?
    • if I need I use Tiny Time Tracker to measure how much time do I spend with something
    • if I need I use Tomighy as a funny way to make me retain focus on a single thing
    • keep pen and paper and have a physical todo list
    • cut out everything from the todo that is only "might be useful... someday... for someone... including myself"
    • have a plan on who do you want to become and how it is helped by this money you got for your work, or how your work help you with it, if it does
    • decide whether it is actually better for you to work for that plan, instead of doing something else, eg. "what am I doing here"

Some ideas about possible problems:

He is just doesn't feel involved enough The decisions are made without him, he is expected to comply with them, without seeing the reasons, without being able to throw his own reasons into the scales. All the same time not getting or being too afraid to ask help from anyone. I try to unfold this in the next two long ones. :)

He misses information but doesn't have the guts to ask it because he worries about asking something that looks him incompetent. He also may don't realize the actual questions, only feel uncomfortable.

It also needs to be realized that these questions are at least of three kind: technical questions about your workplace's code base, questions about the workplace culture itself (how do you know the requirements, how people exchange information, how people are notified about important changes, events, etc.) and there are technical questions that "everyone could know". He may not realize this what makes him overly separated.

The last item is causing the problems here, since it may make him afraid to ask anything. What I try to do to counter this is asking questions when I feel a certain uneasy in the air; questions that are focused on the most likely culprit of the unease and purposefully tell you it's "ok to be silly". For example, while talking about a piece of code I feel a change in the 'climate' every time when we're discussing something that involves our (hypothetical) in-house magic pointers. I do ask, "did you work with our magic pointers before?" or "I always had troubles understanding these magic pointers when I was new do you find think they are hard?". The unease may strike at places where he really should have known better, but there is no point letting this get in the way. I may notice he may have problems with (normal) pointers actually. I do ask, "do you use pointers in university?" or "did they teach pointers well in university?" - it may not be his fault after all, but even if it is, you are better off if you try to ease the situation.

Questions like this may uncover problems while trying to set a climate where it is ok to ask. It is very important.

He may have a hard time designing or working with complex code.

When it comes to creating complex code that many other people will use, like a nice API, or deciding on code roles and classes; there is a pressure that you only have one chance to get it right. Right? Universities may do a quite bad job training anyone for this. I asked the best teacher at mine and he told me handling this takes expertise, and some easy things like self-documenting names.

What I feel useful with this is a prototype milestone where everything works but the code is (allowed to be) garbage. This can be applied to stand-alone tools, maybe modules, less so with more internal stuff.

Another very helpful thing may be code review. We use ReviewBoard and a constructive style guideline for commenting. This I find a blessing. But it can be done with less initial effort too eg. shared folders, at desk or in emails. The only problem I find with it that it's hard to review designs or APIs that way.

That's why the third godsend for me is some kind of design meetings for more complex code. (Complex may mean different things for different people but based on his reluctance of actually doing a task and the common level of complexity of those tasks may give you an idea.) This is where mental knowledge of requirements can clash with actual necessities of code that needs to be physically be written. It may help you a lot if you are not alone in this. Of course this must be made to be a collaboration, not a teaching lesson. If the he is not accepted the meeting or is not involved in it than it's useless.

If this is the case you must make him understand that you are trying to help him because you need to reach the priorities as a team, but you fail to see what his problem is.

At a design meeting some example problems that can be dealt with are what roles are need to be represented in code in order to fulfill the proposed requirements. Cutting down everything that is not necessary. Discussing which way to do it, while gathering a list of reasons, best to be written on paper or a table and then photoed, of why should we do it this way why not another way, gathering reasons for them until everyone involved, most importantly him, feels ok with the design. How each role is best implemented (func, class, module, package, etc.), who is interested in which one, who will do what.

It is very important to see the boundaries of purpose in code, but it can also be very hard if you haven't let yourself fail yet - which could teach you a lot and is better than doing nothing.

Just my two cents (*200 pounds :P) ... hope it helps.

share|improve this answer
Also a single great breakthrough was when I found out/learned that the right word to ask for unknown words is terminology. Helps in conversations and keyword searches, and to point out where your difficulty lies. –  naxa Apr 6 '13 at 14:38
A likely bell-ringer of misunderstood terminology is what I call "the repeated words" in conversation: A: blah blah term blah... B the newbee: ok, but how should it be done? A: what? term (emphasis added). B: ??? –  naxa Apr 6 '13 at 14:39
Great answer - i'm impressed. The problem must be fixed by him AND also by the whole team. I our team there are some 'older' programmers, their short statement is: 'young guys must learn by themselfs'. But as short statement of yours - the team has to learn together. Thank you. –  joe Apr 6 '13 at 18:35

I have had same problem, I made him understood about dealing the multiple tasks, like setting up priorities, and we assign him single task at a time and make him responsible for that task. Hope this may work to you as well.

share|improve this answer
+1 for single task –  naxa Apr 6 '13 at 11:30

Institute a daily stand-up. Every morning at 9am, get into a circle, stand up, and each person has to say three things:

  1. What they did yesterday
  2. What they will do today
  3. Any issues or problems

The meeting should go for 5-10 minutes if that - each person should only take 60 seconds. Get everyone in the group to agree that the meeting is a good idea - everyone will know what everyone else is working on, better communication, better planning, good for morale etc.

On your first day, if the answer to number 2 isn't correct, immediately tell the person and explain why. On day #2, if the answer to number #1 isn't correct, immediately tell the person and what impact it has had on others.

If after a few days of this it's still going on - you need to have a more serious conversation.

share|improve this answer
"If after a few days of this it's still going on - you need to have a more serious conversation." - Or get transferred to another camp. –  SChepurin Apr 6 '13 at 11:29
My experience is that stand-up can help if everyone constantly feels why it is useful, and putting effort in to make usefulness happen. A leader who has a straightforward, funny-while-serious, charming personality and is fluent in the programming craft with no (unexpected) difficulties, is a catalyst for this. –  naxa Apr 6 '13 at 11:33

We had the same problem, and instead of pair programming we did some kind of "pair working". Doing all the tasks together for a week (including task planning) helped him a lot to understand why some things have to be done first and how to deal with priority conflicts.

share|improve this answer
+1 for pair working. it really can help, if both feel involved. –  naxa Apr 6 '13 at 11:30

Get your Team Lead involved. Ask him to monitor what he is doing periodically. Everyday as he comes in tell him what he has to do. Which tasks are of high priority and get him started with the said tasks.

An opinion, it aint very easy to just jump upon different tasks now and then. Consider if you are almost at completion of some task and you get a new one all of a sudden(high priority). Then your tendency to complete the ongoing tasks is more, coz you are completing something.

He always has a reason why he's NOT doing the right thing. If given reasons are valid enough well and good you can help it. Else you need to speak to your manager about it.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.