How to handle somebody who does not take into account what is said to him?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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?

Answer 4

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.

Answer 5

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.

Answer 6

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...)