When the Job Changes But the Programmer Doesn't

A programmer on your team is great at maintaining the old system. But the company has switched to a new platform. What do you do with the no-longer-effective developer?

This story is not hypothetical, though I've changed the names and technologies to protect identities. Based on the response I got when I asked dozens of developers and managers how they'd handle the situation, the situation is also not at all unique. See how you'd respond. (Warning: This is part 1 of 2.)

The programmer—let's call him Frank—has worked at this medium-sized company for about six years. He was hired to work on an existing system of applications written in, oh, let's say it's PHP. Frank now knows that system extremely well and can quickly do anything necessary to and with it.

However, those applications are now in maintenance mode. The company adopted a new framework and is building its applications in... let's say it's Ruby. (It isn't. The languages could be anything; that's not the point.) And Frank is having a very, very hard time.

It's not just that Frank is slow to learn Ruby, though he sure is. It's that he finds it so hard to do anything new, particularly when he has to start with a blank screen (one colleague swears he could finish Frank's task in three days, and Frank's been working on it for two weeks). If you give him a very clear procedure, and something to copy from, he's great. But if asked to come up with a creative solution, he is slow or never finishes, and keeps trying to do things the "old way." It's as though he was taught as a child to never color outside the lines in a coloring book, when the rest of the team does free-form art.

Frank is a good maintenance programmer, maybe excellent. And he did everything he was hired to do... until his job changed. After six months on the new system, his inability to come up to speed is slowing down the project for his teammates and frustrating his manager. His manager has talked with Frank; Frank is emotionally willing to change (or at least he thinks so), but the guy just isn't getting any better.

Here's your opportunity for advice to Frank's manager and the other programmers on his team. What can be done to resolve the situation?

That's the scenario I painted to a few dozen software developers, IT managers, and management consultants. As you'll see, I got several conflicting suggestions. But before you go any further, decide for yourself what your answer would be. As a manager or a developer, what would you do?

The answers fell into a few rough categories:

  • Frank needs to leave the company. Everyone has tried, but some people just aren't able to make a change.
  • Find something else that Frank can do to serve the team.
  • Applying a technical or management technique can save the day (or at least make it clear to everyone, including Frank, that the situation is hopeless).
  • It's a failure of (someone's) attitude. Fix that, and everything will be okay.

There's way too much here to cover in one blog post (I sure bit off more than I could chew) so in the rest of this post I'll cover the first few suggestions; next week, I'll describe the alternatives. (Besides, it's a good reason for you to subscribe to my RSS feed or to sign up for the Javaworld newsletter. Weren't you meaning to, anyway?)

Frank needs to leave the company.

Many people responded with compassion for Frank. He's undoubtedly in a tough place, challenged to do more than he's ready for. But several people felt that Frank has had plenty of opportunity to change, and maybe it's been enough.

For example, asks author, teacher, and consultant Jerry Weinberg, "Is this a business or a charity? If it's a charity, keep him right where he is. If it's a business, find him another position in which he can earn his pay."

James Harvey, a learning and development consultant, agrees. "Frank is unable to meet the requirements of his job. And, it appears that you have in good faith provided him with the time and resources necessary to learn his new job. You can continue to accept his inadequate performance, move him to a job he can do, or terminate his employment.

Does Frank have less brutal options? Absolutely. But he has to be a willing participant. Frank has to believe the case for change, says change management consultant Sharon Bond. "Has the 'burning platform' message been absorbed by Frank?" she asks.

Agile project management guru Esther Derby says Frank's manager needs to have another forthright conversation with him, explaining his expectations and concerns, and also hearing Frank's point of view. "Chances are pretty good that Frank is as distressed as his manager is," Derby points out.

"If Frank wants to try once more to get up to speed, they need to agree on a plan with specific actions," says Derby. "They need to agree how they'll evaluate whether Frank is making the kind of progress the job requires. And the manager has to put a time limit on it—weeks, not months. If Frank recognizes that he's just not in the right job, and he's an employee that can still make a valuable contribution somewhere in the company, set a time frame for Frank to find a job internally—weeks not months. Start looking for Frank's replacement. If Frank hasn't found an internal job by then, end his employment."

This is in fairness to Frank, too. "It's obvious Frank is in a position that does not call for his natural strengths, the way he naturally strives to get things done," says Richard Deems, performance specialist at at WorkLife Design. He suggest using the Kolbe technology to identify what Frank does best, and place him in a position where he can be successful for him and the organization. Deems recommends that Frank take a Kolbe A Index, which identifies his natural strengths, and a Kolbe B Index, which identifies the strengths he perceives as necessary to be successful in his present position. His supervisor would take a Kolbe C Index, which identifies the strengths the manager perceives as necessary to be successful in that position. "We project they would not match up: What the manager wants is not the skill-set that Frank has," says Deems. "And we would project that Frank's perception of the job needs do not match his natural strengths." Deems expects that Frank will never do the new job, and to spend time on him in that position is to waste money. "For the company to get the most from Frank they need to replace him in a position that calls for his natural strengths," he says.

If it turns out that Frank really has worn out his welcome, the company can make it as easy as possible for him to make the transition to another company. Weinberg suggests that, since Frank's been a faithful employee for several years, your company should help outplace him into a business that needs him ("He deserves that from you," says Weinberg), but he doesn't deserve your charity.

The decision to separate can be mutual. Points out developer and management consultant Shava Nerad, Frank may need someone to tell him that it's okay for him to say he wants to look for other work, that his recommendations for past service are stellar, and that his management will support him in whatever he decides. "It doesn't reflect on his worth as a person, and he needn't keep his plans or worries a secret from the group," she adds.

But all may not be lost...

Find something else that Frank can do.

In some shops, it might be an option to leave Frank as a maintenance programmer—though in our scenario (and the real Frank's actual job) there's less an less to maintain as the company moves to its new platform. Over time, of course, today's new development will need maintenance, and Frank might be suitable for that. But that doesn't solve the immediate problem: today's productivity.

Several people suggested that Frank's manager should look for other positions on the team or in the company. After all, he has several years of experience with the knowledge domain (i.e. what users need and want). Perhaps his maintenance experience might make him an effective tester. His programming background might help drive towards more test automation.

All of the above assumes that the cause is probably lost. But perhaps it's not. Several people suggested technical solutions, process improvements, and management techniques that might save Frank's job— and make him a productive team member again. But to learn what those are, you'll have to wait until next week.

Edited: Part 2 is here.