4

I work in a software division of a non-software company. I am the lead of a two member team (one junior, one senior). Team members report to me; and I report formally to the department head, but frequently to the division head.

The reporting structure is not strict - that is, at anytime I can discuss matters directly with my division head and between myself, the division head and the department head we have a great working relationship.

One of my tasks is to improve the efficiency of the development process. Therefore I noticed that the developers did not have any formal (proper) tooling in place - they were using whatever was "flavor of the month" to write code. For example, we had one person using Notepad++, one person using Dreamweaver, etc.

As part of their ongoing training/improvement - I send them for training on the software development package we would be using (twice); and we requisitioned licensed (professional) development software for the entire team in order to streamline and speed up the development process.

The problem is - despite constant coaching training, peer programming, guidance, etc. the senior of the two developers insists on using software that he is "comfortable with" which causes his productivity to go down as he is constantly struggling to fix issues that the development environment would have picked up and fixed automatically. I am talking about simple things like typos in variable names.

At this point, after a few months of training (and discussions with management) I am not sure what to do. This person's productivity keeps slipping (they keep missing deadlines) and when asked during our stand-ups the issue is always something other than the obvious.

Short of removing all other software, locking down the machines and only having approved software installed - an idea that has crossed my mind more than once - is there anything else I can do to encourage this person to use the tools provided - because he seems oblivious to the fact that his tooling is causing him problems.

|improve this question
4

This sort of situation is exactly what Performance Improvement Plans are for.

You need to set one up. Be sure you have MEASURABLE data to evaluate their performance with, and hold him to it. Explain that you're trying to help him keep his job.

Let him go two weeks, and show him how he's falling behind. Then, as part of the plan, have him use a good dev tool. That may mean sitting with him while he works to ensure he's not sandbagging to skew your results.

Be prepared for the plan to fail. You'll have then done everything possible to save his job.

|improve this answer
  • I would probably get the department head involved (since they will likely have to sign off on the PIP) But otherwise I agree. Sit down with your Department Head, propose the pip and make sure they agree this is the proper route. Because if/when it fails the result needs to be termination or reassignment out of your group. – IDrinkandIKnowThings Jul 6 '15 at 21:02
  • Wrong answer. Never invoke PIP unless you are already planning to fire the guy and he knows exactly why. It will destroy any trust he has in your judgement if you use this nuclear option when simply setting the same goals /requirements without the explicit threat would accomplish the same thing. – keshlam Jul 6 '15 at 23:02
  • @Keshlam: If the goal is to get the team to use the same tools in order to boost production and one team member refuses to go along with it, then that person isn't part of the team. According to the OP the goals were set, training was provided and it was mandated. At this point the team member needs to realize that continuing to go against the grain is a career limiting move. Perhaps they'd be happier applying the cowboy mentality elsewhere. – NotMe Jul 7 '15 at 1:34
  • 3
    I completely agree, @NotMe. The guy is openly insubordinate at this point. A PIP is warranted. I object to the "cowboy mentality" characterization, although I understand its colloquial use. Cowboys had to work together very closely and be on the same page all the time, or they'd get killed by the half-wild cattle they were working with. The "Rogue mentality" wasn't tolerated on the open range, either. (Direct descendant of "cowboys" and grew up on cattle ranch.) – Wesley Long Jul 7 '15 at 2:02
4

As a developer, I have dealt with this situation on more than one occasion where it was a lower developer and even the person assigned as the team lead who were slowing down progress based on biased preference for their own comfort vs. growth and increased productivity. My recommendation follows closely to the suggestions above.

Get your upper management involved.

Sometimes change needs to be initiated from the top down. Get your senior mangement involved. Make the change a team initiative and if at all possible try to avoid pulling rank and file. But worse comes to worst it may be necessary in order to institute change if the friendly approach doesn't work and resistance is ongoing.

Setup a non-threatening coding session

This is my one developer specific recommendation. Sometimes the best proof lays in the pudding as the saying goes. You pick a small module and have it built in 2 different platforms and then let the evidence speak for itself as to the speed and efficiency of the new development environment vs. the old one. Your project road map should be on hand to in order to show how the new suite of tools better aligns with the long-term road map compared to what they are comfortable with. In the end, the pain of growth is temporary but the damage of stagnation can be felt forever.

I have found that when senior decision makers are part of the process as a team effort, not as an authority figure and you pair that with approachability, usually the most entrenched resistance to change will begin to loosen up. Remember humans by nature are resistant to change. Its all about psychology more than it is about proving a point or making a change for ego's sake.

|improve this answer
  • Better answer. Don't threaten, don't assert, demonstrate why he should invest the effort in moving over. Engineers are much more willing to believe when they can see the difference. – keshlam Jul 6 '15 at 23:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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