When the Job Changes But the Programmer Doesn't Part II: Saving Frank's Job

Last week, I described the plight of a maintenance programmer whose company was moving to a new language and development platform. Although Frank (a real person but with details changed to protect identities) has worked for the medium-sized company for some years, he's just not being productive. I promised the rest of the story this week.

In last week's post, I described the situation (you might want to read that first to get the context) and some of the arguably-draconian suggestions I received from developers, management consultants, and IT managers. They suggested that if Frank couldn't do the work, and the company couldn't find another position for him (such as testing or continued maintenance work), it was time to (however gently) push him out the door. It sounded as though all Frank could look forward to was a pink slip.

But others had several suggestions for methods that might help Frank make a successful transition. I'd like to think that some of these might work!

Applying a technical or management technique can save the day.

Several people assumed that Frank had been thrown into Ruby without training, and left to sink or swim. In fact, he'd been trained on the new system along with the rest of the team (though the assumption itself was fascinating—is training so rare that you assume it doesn't happen?).

While "Send him for Ruby classes" is an obvious answer (and a good one), the truth of the matter is that the most recent course he took a few months ago (which Frank personally chose) was in PHP. That's not a lot of commitment on his part to learning the new environment.

Nonetheless, additional training might be in order. Dan Walter, CEO of Performensation Consulting Pay-for-performance, suggests that the company may want to send him off-site for intensive training in the new language (and possible new skills to approaching change). "Providing Frank with the focused opportunity to transform himself gives the best solution for him and the company," Walter says. "If it works, the company wins, and so does Frank. If it doesn't work, there will be a common understanding that Frank needs to move on. The company makes a small investment in its future, or in the long term integrity of their personnel approach. Either result works for the company and the employees who either appreciate or do not appreciate Frank."

Another way to address the situation is to change how Frank is giving assignments. Agile project management guru Esther Derby says, "I'd also look at how the work is chunked up. It may be that if Frank broke the work down into more discrete one- or two-day chunks, he'd be able to make better progress."

Derby isn't the only one to suggest that projects and assignments be "bite-sized." Developer Jason Seiden adds, "And I mean bite-sized from Frank's point of view: step 1, step 2, step 3." Gradually, Frank's manager can slowly provide Frank with more autonomy, but then needs to stop as soon as Frank starts to struggle again. This is Frank's limit. "That's it," Seiden says. "No magic, no special tricks, no wishful thinking, no fancy conversations, no politics, no re-writing of the job description. Just some good, plain, old-fashioned management."

The premise is that by removing pressure from Frank, he'll get unstuck. George Dinwiddie, a software development coach at iDIA Computing, suggests, "Don't expect any productivity from him at all. Perhaps remove him from the team, for the time being, so that he's not subjected to the whispers of the colleague who could do the work in three days. That's not helping him. But remove him in a non-damaging way." Dinwiddie suggests that Frank help one person with a small special project. "Then work with him, side by side, so he isn't alone and lost. Help when he gets stuck, but let him do what he can. I suspect that slowly he'll get what he needs to work on his own."

"Working with him one-on-one" is a common theme in the suggestions, unsurprisingly since I solicited input directly from the Agile community. But others felt this way, too. Developer and management consultant Shava Nerad opined, "If someone would spend two weeks with him, really with him, instead of leaving him for two weeks to stare at a screen and feel frustrated, you might be able to come up with a definitive, compassionate, practical solution to your dilemma.

For example, Nerad points out, Frank may be the kind of exploratory learner who needs to see something done before he can understand it." Have the programm who could do Frank's task in three days show him just how it's done. Then give him a similar task he can use what he's learned. Some folks simply do not learn from books, and the steep early learning curve can be a pain.

Frank may need some time to read books, do exercises, or otherwise get away from productive, goal-oriented development, suggests Nerad. "It takes time to learn a new programming paradigm, and if Frank doesn't have a safe, mentoring environment to support this learning, I think that the pressure to deliver could be killing learning. I also wonder if this 'emotional' willingness to changed has spurred any behavior (quiet study time at home?) or if it's more of a 'Someday I'll go to the bookstore to buy some books on Ruby.'"

There are management benefits to this approach. Agile developer Adam Sroka points out that another developer who's pairing with Frank can better assess what he is doing (or not doing) that might be slowing him down. "If he does much better with the pair, it might be because he wasn't focused on his own or didn't know where to start," says Sroka. "The experience of pairing will reveal a lot of information that the pair can communicate back to his manager."

Plus, Sroka adds, the pair can provide guidance and encouragement that may help Frank to constructively move towards greater productivity. "Being told, 'You aren't doing so hot,' is nowhere near as useful as being shown what you should be doing and why," he says.

It's a failure of attitude.

Although I asked for specific "what to do" suggestions, several respondents took time to identify where the process or people failure was. I was a bit surprised at how much everyone brings to the answers his own... well "agenda" sounds negative. Certainly I see how we each carry our experience silos with us, and they shape our responses (e-mail and emotional!). Several people responded with assumptions that weren't reflected in my little case study (for instance, some were certain that the company didn't value Frank at all, or the colleague was being "snide" by saying he could do the task in 3 days instead of 2 weeks). That was a little lesson on its own. It makes me wonder how often I read things into a situation that really aren't there.

For example, one developer judged from the scenario that the team members were playing politics, and that it needed to brush up on their people skills and help Frank out. "Snotty comments like 'one colleague swears he could finish Frank's task in three days, and Frank's been working on it for two weeks' don't play in today's job market. If the manager permits that kind of gossip and backstabbing, the project is doomed regardless of the technology." (I didn't mention this earlier, but the reason the developer knew he could finish the task in three days was because he had done so.)

"If it were my team I would point out that Frank is not, in fact, under-performing," says Sroka. "The team is under-performing. The issue belongs to the team and should be addressed by the team." Sroka feels that focusing on Frank at this point is probably premature. "What we really need to know is what is the team doing wrong that is causing Frank's perceived failure-to-thrive," he says. "If we can identify that we might be able to fix it."

Others point their finger at the manager, not the team members. "From my point of view it's the manager to blame," says one programmer. "After this long time he should know his employee better."

Management consultant Thomas Martin is more hard hitting. "Is it really Frank? Is he working for a manager or a leader?" he asks. "His manager will continue to give him tasks. A leader would look for ways to inspire and motivate and move him from his comfort zone of PHP," says Martin, who questions the response from management for coloring outside the lines. "Pavlovian conditioning is the fundamental building block of learning. Managers instill this, leaders work to break it down."

"Your description of the situation sounds to me more like a leadership/systems issue than an employee performance issue," agrees Sharon Rich, a business consultant and coach with Leadership Incorporated. Rich sees the source of the trouble in the original switchover six months back, indicating significant gaps in the organization.

So there you have it. Lots of advice, some of which is contradictory but all of which, I think, is interesting.

This has been a fascinating exercise for me. In addition to the wide breadth of professional opinion (which I expected) and the relatively high incidence of assumptions (such as those who are sure that Frank was thrown into the situation with no training offered, which did surprise me), I realized that I'd had an unspoken assumption of my own: There's an attitude difference between maintenance programmers and "initial art" programmers that I had never explicitly examined. The latter recognize that this particular project will eventually end, and it will go into maintenance mode. At that point, the "blank sheet" developers know to find another internal project to work on, or get their résumé out. But I wonder if the people who support existing systems ever imagine that the stuff they're maintaining will be closed down and go away. If they don't, they could easily assume that the work will be around forever, essentially unchanging. There's nothing inherently right or wrong about this; it's just a head-scratch moment.

Now you have the suggestions from several experts — everything from "Boot him" to "Give the guy a break." I'd be interested in hearing where you fall in; please let me know in the comments what you do if Frank was on your team or if you are (or have been) Frank. After a few days, I'll chime in with a little additional information about the real Frank and his current situation.

This story, "When the Job Changes But the Programmer Doesn't Part II: Saving Frank's Job" was originally published by JavaWorld.

Copyright © 2009 IDG Communications, Inc.