I'm facing a problem that is quite new for me, and want to discuss it. I have in my team a developer who doesn't take into account the directives that are given to him. He doesn't follow priorities that are given to him and sometime even specifications.

The person is competent in coding, motivated and well intentioned, so I'm pretty sure that we can come up with a way to work that work.

Let me give a few examples to have a better understanding of the situation.

We had a project that was almost ready to be published. However, a bug has to be fixed in a functionality, and another in the function that register customer account. We had another developer on the bug in the functionality, so I told him that fixing the one in account creation was absolutely critical, and he should spend his time on that. I tried to be as clear as possible: "If we cannot register a new customer, we cannot sell our product, so functionalities, with or without bugs, are useless. This is the #1 priority". Obviously, I find out that he goes helping the other developer. He did good work, but that work was not the priority and was not what he was assigned to.

On another project, we gave him technical specifications about a development he has to do. He comes up with something that works, but doesn't fulfill the specifications. We said to him to refactor his work to match the specification. This was better but still didn't match them. The specification was more complicated than what was needed to make his work, so he decided to make it more simpler. Which is good, except the fact that I'm responsible for that, so he should discuss with me when he takes decisions like that, and that we know that a future improvement of the software will need that specification (which he would have known if he had talked to me).

I'm pretty sure that the problem comes up not from the guy, but from the interaction between him and the way the management is done in the company.

So basically, how to get the situation to improve and make everybody walk in the same direction? What do you think we did wrong when managing here?

  • 2
    Did you confront him? Perhaps he justified it somehow? What were his reasons for doing this?
    – jmort253
    Commented Jun 3, 2011 at 4:40
  • 1
    this question may have some answers that could help you out - pm.stackexchange.com/questions/2459/…. Good Luck
    – M0N4K0
    Commented Jun 3, 2011 at 7:51
  • @jmort253 Yes, I had, and my co-manager too, several meetings whith him to make sure thing where explained. But it looks like it's only breaking more the communication. @M0N4K0 I already read that question. Actually, this is not the same. He is not argumentative at all, this is the other way around. He doesn't communicate much and does things his way.
    – deadalnix
    Commented Jun 3, 2011 at 12:41
  • Is this a question about project management?
    – MCW
    Commented Dec 15, 2015 at 13:33

6 Answers 6


I see two approaches to the issue and from where I sit, I'm not sure which is the best approach:

  • Co-opt him: From the description, he has pride in his work and he puts out quality code but he does it his way. You have to make him believe that your way has become his way. Before you hand off the tasks, you have to spend time getting him "into" the current issue and he'll take ownership of the whole thing. The best technique for that will vary a lot and the whole process is likely to take a lot of time but you could end up with a valuable team member.

  • Go Formal: When giving tasks, give ultra-clear targets, deadlines, checkpoints, and deliverables. Follow up and check in regularly on the the status and make clear to him that his missed deadlines is putting the project at risk. If he doesn't change behavior, you'll have to go up the management chain until someone does change his behavior or until they move him off your projects.

  • Good point. I already begun to become more and more formal, as you suggested. I'll try to thin about the first point, which is a really interesting suggestion.
    – deadalnix
    Commented Jun 3, 2011 at 12:39

I'm not sure I'm following your logic -

You said you told him what to work on (specifically) and he went and worked on something else, and you gave him 'specifications' (which are, you know, specific) and he built it the way he wanted to, and you're thinking it's due to a lack of understanding or interaction with management???

The problem is him, pure and simple. If you've been as specific as you say and are still getting this reaction, then it's time to re-evaluate his position with the company. Yes, he's a good coder, but there are lots of good coders that can also follow directions and work on what they're supposed to.

From a purely business perspective, he's costing you time and money. You paid him to work on a big fix he wasn't supposed to work on (which delayed release of your product) and then you paid him to work on what he should have been working on in the first place. Then you paid him to build something three times when he had the specs from the beginning, but chose to do it his way.

And not to be too blunt, but it sounds like you (or whoever he reports to) might be part of the problem as well. If you're seeing these problems and still either saying it's not him, or that there must be some way to work with his behavior, well, that's a problem as well. So what did you do wrong? You're excusing away his actions, which only tells him they're okay.

Sometimes the most difficult part of managing projects is managing the people.

  • No, I'm certainly not telling him that what he does is okay. We had meeting for both exemple before, and several others, where I explained him what I just explained here. The other manager did the same. But's it's only breaking more the communication, and not solving anything.
    – deadalnix
    Commented Jun 3, 2011 at 12:27
  • 1
    I wasn't saying you were 'telling' him that it was okay, but in trying to work around it you're tacitly saying it's acceptable. I understand your wanting to fix things, but if both of you have formally told him it's unacceptable and it's gotten worse, then it's time to ask yourself if it's worth it. I'm sure he's not the only person that can do the job, and sometimes we all need a kick in the pants to realize our behaviors aren't acceptable. Maybe just knowing his position is in jeopardy will be enough. Commented Jun 3, 2011 at 15:13
  • Understood your point. That's what I want to avoid, but I keep in mind that if nothing changes, that the way it will ends.
    – deadalnix
    Commented Jun 3, 2011 at 15:57

A high performing team means the individuals who make up the team are working in a collaborative, supportive way towards a collective goal. The individuals on this team are all successful or all failures; there are no individual differences. While you are citing some positive behaviors of this worker--probably because from an individual perspective they are positive behaviors that could produce some positive results--his behaviors are inconsistent with the teaming and the team's goals. Focusing on how his behaviors are positive comes across more as trying to justify and excuse what he has done and, if you do this, you become his enabler.

Identify and tell him what he did "wrong" (I put that in quotes because it is a value judgment based on your particular situation, not necessarily his work ethic), tell him what is expected here on out, time box his improvement plan, evaluate his performance at the end of the time box, and then react accordingly up to and including removal and replacement.

On your side of this equation, you need to evaluate your communication channels. While I am trying not to justify his behavior, I am picking up a broken communication link as the possible root cause. He made a couple of "executive" decisions that were inconsistent with your directions. Question one is: is there something about this guy, like his personality trait, that sort of causes him to avoid communicating. For example, he is an introverted, heads down kind of guy, lost in his work, and he just attacks. Question two is: have you disabled the two-way communication channel? Is your office door open? Do you listen--I mean, really listen--to your team and their messages to you? If you fixed this link, would this problem magically disappear?

  • Yes, I'm wondering too if it comes from the guy or the communication link. The communication is open, I'm not in a closed office and my co-manager isn't either. I'm listening to teams members, and if they point me something wrong, I'm gratefull, because this is the only way to progress. But I feel him quite scared - maybe the word is too strong, but the idea is here - of engaging communication when he needs to. Anyway, thank for the feedback, I see good hints in what you wrote.
    – deadalnix
    Commented Jun 3, 2011 at 12:54

Don't you just love people :)

This is a performance issue, not just your project. If you have already talked to him and it hasn't made a difference, you need to talk to his functional manager. I've been on the client end of this behavior, and I have to tell you that it broke my trust with the team. I work very hard to make sure I don't treat my clients with the disregard this person does.

You have good advice from others above about how to confront the problem directly, but don't forget to include the functional manager.

Good luck.

  • 1
    I agree with Perry that you need to include the functional manager. There may even be a misalignment between what this employee is asked to do by his functional manager and what he is asked to do by the project manager. Commented Jun 7, 2011 at 9:33

Often when a team - not just an individual - does the wrong work, it's because the constraints have not been made clear to the team.

In the first instance, did the second developer also know that your problem dev's work was a priority? Would he have distracted the first developer if he'd known that?

In the second, why did the developer need to ask you about the reasons for the design and specification? Why wasn't he given all the information he needed for his work to make sense?

It sounds as if he would be absolutely perfect on an Agile development team. He's helping others collaboratively, keeping things simple, making pragmatic decisions and producing excellent software that performs for the capabilities he knows about.

Unfortunately, these very tendencies which would work so well in Agile mean he is probably frustrated by more traditional processes, in which he doesn't get to use his creativity, collaborate, make decisions about how to solve problems (rather than just implementing solutions), etc.

Sometimes it's not a matter of managing people correctly as much as spotting that their talents and strengths are not well-aligned to the task at hand. If you have any Agile pilot projects ongoing, I would suggest he's an excellent candidate. Otherwise, it may be time for him to leave - and that doesn't have to be a bad thing, for either of you.

  • Interesting point of view. I think he would have the same problem in agile. Actually, the problem isn't, if we take that exemple, that he changed the specs. This is perfectly fine and show that he has a good sense of what need to be done. The problem is that he should have discusses that with me (which is also the key in agile developpement) ! If specs didn't make sense to him, he could have talked with me, and I would have explained him why the choice was done. If he had a good, I would even has changed the specs. We are not in a very rigid structure.
    – deadalnix
    Commented Jun 3, 2011 at 12:34
  • I understand. I'd still say, work with reality - he doesn't do this - and put a process around it, instead of fighting him, since his work is good for what he does. Maybe you could try pair-programming, putting him with someone else who does do the necessary leg work? Or ask him to help you improve the specs as he goes through, so that he still feels empowered? Either might work well.
    – Lunivore
    Commented Jun 3, 2011 at 13:13

I'm somewhere between the opinion of SBWorks and the opinion of Trevor on this. And I think it comes down to the level of unconformity you have.

As a 1st step, include him in the design process as much as possible in your project system. While doing so, listen hard to his opinion. Look for clues of hidden objection in him. If there are no disagreements, document your common decisions (highlighting his consent). There's a good chance you won't agree on everything though. Naturally, you decide after evaluating the possibilities, that's not new in any way. Just take care of documenting the minority report and the reason you choose an approach over the other.

If you succeed, you're done and you got a valuable resource for future planning work. No problem on this branch.

The other option is that the same thing happens again. You ask him why he left the path you agreed on, he tells he always knew the path was wrong. At this point, you should refer to the agreements and the documents produced in step 1. I saw this happening a couple of times and I'm still not sure we handled them well...

I think after two rounds of this still failing, I'd let him go. In that case he really needs a different process or work environment. (I have to say, I never fired anyone for this reason...)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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