IT Employment

General discussion


Possible uncooperative employee

By CBV ·
Hello everyone,

I'm quite new in the management sector so I'm wondering what measures should be taken in the following situation.
In our litle software company we have this guy who's probably the best in the company, he's also the oldest; he's working by himself on this large application that is very important, the others are starting writing/porting code to this platform. The problem is that he is not very sociable, he's using the latest coding methodology (he was left by himself to write the code) and nobody else besides him understands the code and architecture. His communication skills are not so good so it is very difficult to make him conduct a workshop regarding his code.
The bottom line is that we will have to make him document the code and the application otherwise we will have big problems, the thing is that we've tried already to get someone with him to understand the code but with no results. (the management is just starting here
So, any ideas ?

Thank you

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

I would

by Jaqui In reply to Possible uncooperative em ...

give him 3 options:
1) teach the code to others
2) completely document everything, including manuals for end users
3) find new job. ( if he isn't willing to work with you you don't need him. the other programmers can then have full access to the code base to decipher what he has done, without him complaining about it. )

Collapse -

Wrong on all counts

by amcol In reply to I would

This is (apparently, hard to tell from the brief description) a long term qualified competent employee with no communication skills. He's not going to teach anything to anybody, he's not going to write any documentation, and he's probably too valuable (especially in a small organization) to lose altogether.

Which is another part of the problem...he's the way he is (you can't teach an old dog new tricks), and he's been there way long enough not only to have gotten years of reinforcement that his approach is acceptable but also to have figured out just how valuable he is. You're not going to change him, and you don't want to lose him.

The approach I'd take is to move him to a new project, putting other people on his. Bite the bullet and trust your people...they should be competent enough to figure out what this fellow's done on their own, and if they're not this'll be a good test whereupon you can replace THEM, not HIM. Figure out a positive way to incent them to take on this challenge, don't announce that they have X amount of time to get control of the project or they're out...that never works.

Your reluctant programmer almost certainly has a great pride of authorship and ownership, and he's not going to want anyone else screwing with his code. That may be all the motivation he needs to suddenly find his cooperative spirit and work with his colleagues...he'll have no choice.

You may find that his code isn't so great after all (who can say, since it seems he's the only one who knows it). In that case, you'll have the evidence you need to replace all his work with something new that's well documented and that everyone understands. Either way, you win.

Collapse -

It happens everywhere

by house In reply to Possible uncooperative em ...

We are a pretty tight knit office, and it still happens. Sometimes, our client management application does not talk to our various servers properly after an update, leaving our first level reps convinced that everything is fine, when in fact the change did not actually replicate properly on the back end.

Internal apps are always a work in progress, and there will always be mistakes made. Having someone developing some sort of alien code only compounds the issue.

My advice, hire someone who is well versed in the language to map out the code. It will be a long and difficult process, and it will cost more money than you'd like, but it is vital. I would not be too impressed with your coder, despite his longevity with the company. Part of his job is to document the development of the application. It is the golden rule of any project's development.


Collapse -

Fix Your Process NOW!!

by nottheusual1 In reply to Possible uncooperative em ...

OK - so there is an immediate issue. Attach someone to his hip that is smart enough to figure out what he is up to - somebody that can offset his obvious shortcomings if he really is that important, but won't make it a power thing. It needs to be teamwork. Explain the "bigger picture" to him - that if you aren't successful as a group (company), you aren't successful at all. If he can't fathom that, then you'll have to make bigger decisions.

Second, and a bigger issue, is that you don't seem to have a proper process in place for managing your workflow or deliverables. People will only do "to you" what you will let them. Fix your business process before you get runover again.

Collapse -

Have a talk with him

by jmgarvin In reply to Possible uncooperative em ...

He is going to hurt your company in the long run. Talk to him and explain the importance of proper documentation. One thing to get him documenting is to put a newbie with him.

The newbie will probably be just itching to learn what the code does in all places. The constant questions will "force" him to write documentation or at very least comment the code.

While most programmers are valuable, if your other coders can't figure out what he is doing, he is probably not doing something right. Send one of your other coders in there with him for a day or two and see what happens. While some code is sloppy or obfuscated, it should be readable. I would be your other programmer walks out with a little knowledge of how the code works.

If, after you have tried the other two solutions, you need to start thinking about HIM and what he is doing. If he can't create readable code, proper documentation, or teach others, it is time to do an evaluation on his benefit to the company. While I would take all steps NOT to fire him, you might need to send a message to him. Take him off a project and put him on a low priority one. Put him under a younger programmer who documents their code. FORCE him into being a "proper" coder.

If he can't manage the change, he'll quit or you'll have to fire him.

Collapse -

Think of yourself

by ge3putt In reply to Possible uncooperative em ...

Unless it's by accident, you are now a manager and need to deal with difficult people. I assume your performance in dealing with this situation will be used to decide if YOU stay or go. Are you beginning to get it!? Explain to this person, what is expected of him, and what the consequences of his ignoring you are. If this person is completely dismissive of you, get another person to sit in on the discussion, as a witness. If things do not improve as needed, then dismiss this person as soon as possible.

Collapse -

Thank you all for your answers

by CBV In reply to Possible uncooperative em ...

We've had this meeting where the COO participated. This guy now has some tasks to finish and after that he will have to document the code and the application. He will not be allowed to do any more coding. Hopefully this will go well, also I will try to explain to him why we need this documentation done properly and what's his role in the company. I also might put a newbie with him on this, I like this idea. If this doesn't work, I will get him on another project and put some of the other programmers on his code to figure it out.
Anyway, we're implementing some new coding standards and policies so that these things will not happen again.

Collapse -

Establish your own authority

by amcol In reply to Thank you all for your an ...

Sounds like you're on the right track. Don't make the mistake of falling back on your COO if things don't work out as planned...neither this guy nor anyone else will have any respect for you. You're the manager...go manage.

Also, don't make the mistake of letting this guy go off and execute the plan you've all agreed to without any additional oversight, once again from you personally (don't EXpect what you don't INspect). And don't be surprised if the whole train goes off the rails...frankly, from what you've described I'm not optimistic. Hope I'm wrong.

Collapse -

by The Admiral In reply to Possible uncooperative em ...

I think you have an opportunity here to do a good thing.

First, I would hire someone who is not so sensitive and is thick skinned but knows their stuff. The reason is because you will need someone to get in there watch the code being generated and take what ever abuse or anti-social behavior that comes accross. We did this to one of the programmers with someone who rode a Harley and had tatoos coming out both ends, they wound up being good friends.

Second, you have to watch to see what his likes and dislikes are. When I was in grade school I passed Geometry by handing the teacher M&M's every morning. Sometimes you have to give a flower to get honey.

Third, managing and micromanaging are two different things. I get pissed off when micro-managed because I have always had the attitude that if you knew how to do the project, why do you need me? So you have to slack off on trying to keep the heart of the beast pumping how you want it. I tend to control my managing control freaks, and they hate it, but it is like Mr. Scott said:

"You have to give a captain what he needs, not what he wants." So you have to manage that way as well.

Collapse -

Model It

by kprivette00 In reply to Possible uncooperative em ...

Most modeling tools you can model the whole application based on the code and components. Get with an infrastrcuture person where the code is at and run the modeling tool against. Describe-embaracdero, togetherJ, xde or rose, enterprise archtitect by sparx systems. These tools can all port code and build your class diagram. Most senior level SA's or BA's can form domain models and use cases from this and then develop the artifacts for this application.

Oh course this goes along with my earlier me we can discuss.

Related Discussions

Related Forums