Wednesday, April 22, 2009

What to do with a struggling employee

Esther Schindler recently put forward a scenario about a struggling employee named Frank, and solicited advice from her network.

Briefly, the scenario is this: Frank was a great maintenance programmer, but the company is retiring the system he worked on. Frank has moved to a new project in a new language and he's not catching on. (Full scenario is here.)

The Other Esther summarized the advice she received in When the Job Changes But the Programmer Doesn't and When the Job Changes But the Programmer Doesn't Part II: Saving Frank's Job.

My full response (excerpted in Esther Schindler's posts):

It sounds like Frank has been a valuable employee. But now he's in a position where his skills and preferences aren't a good match for what the position requires.

So first, I'd think about whether there is a way to make use of his maintenance programmer skills on the new system. Can he fix bugs? Can he contribute domain knowledge in some other way?

It's not unusual for people who are learning a new skill to follow rules rigidly. They haven't internalized the new knowledge to the extent that they can see possibilities and use the skill intuitively.

The scenario doesn't say how Frank has gone about learning the new language. Pair programming can be a great way to learn, and pairing a beginner with an expert can be enlightening for both.

I'd also look at how the work is chunked up. It may be that if Frank broke the work down into more discrete 1-2 day chunks he'd be able to make better progress.

If there's no way to use Frank's skills, then Frank's manager needs to have another forthright conversation with him, explaining his expectation and concerns, and hearing Frank's point of view, as well. Chances are pretty good that Frank is as distressed as his manager is.

But before the meeting, Frank's manager needs to decide if he's willing to give Frank another chance, or give him time to find another job within the company. If not, get the ducks lined up with HR to end Frank's employment.

If Frank wants to try once more to get up to speed, they need to agree on a plan with specific actions. 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.

If Frank isn't a good candidate to stay at the company, don't let the situation drag on forever. The current state is painful for everyone. And while firing Frank will probably be painful, it won't be as difficult as the alternative.

A couple of things to emphasize:

Allow weeks not months to turn the situation around. That means 2-6 weeks, no more.

Choose based on how big a hit you can take on the project. Look at the trade offs. Some times no body is better than a warm body. If working with Frank is taking significant productive time away from others for little potential return, 0 weeks is the right answer. As Jerry Weinberg asked, "Is this a business or a charity?"

If Frank can be valuable to the company, but not on your project, set a time frame for *Frank* to find a new job. You are not a job placement service, and not your job to find him a new assignment. It's Frank's job to find that next assignment. You can offer to introduce him to people or give a reference, but Frank needs to do the work. And set a time limit 2-6 weeks, no more, depending on your project needs. Do not wait until Frank has found a a new assignment to start looking for his replacement.

Labels: , ,

Wednesday, November 05, 2008

Conditions for Change

I attended an Organizational Change BoF last evening at the AYE conference. Among other things, we talked about why it is that some managers fail to act when there are many signs of big problems.

I see three conditions that are prequisites for change (at any level):

People have to recognize the situation. One person at the group told a compnay that was losing billions, but kept cancelling projects that produced revenue, and funded projects that failed. The problem was obvious to anyone who *could* see. But the senior managers had a mental model of operating as a monopoly, and updated neither their mental models nor their corporate accounting systems. So they didn't see it.

People have to believe it is possible to change the situation in some way. If people don't believe it's possible to change, they are paralyzed. THere are some things can't be changed, that are out of the sphere of influence or control. People often forget that even when they can't change external circumstances, they can change their response.

People need to have some idea of how to shift the situation. WHen people have no earthly idea how to shift the situation, they become paralyzed. So paralyzed that they don't seek help in the form of new ideas or expertise. Or they grasp at the first silver bullet that's offered (which often makes the situation worse). Or they do nothing.

So how do you create the conditions for change in your organization? Stay tuned. I'll be blogging about that in the next weeks.

Labels: ,

Monday, November 26, 2007

They don't get it (...well, maybe)

I got a call from an acquaintance, Gloria, who is trying to convince her organization to adopt agile methods.

"I've given them every logical argument I can think of," she said. "They just don't get it. All I get is blank looks. How stupid can they be?"

"They" probably aren't stupid at all.

But they may have a different frame of reference, or a different mental model.

They may value something that isn't considered in Gloria's logical arguments.

They may agree completely with Gloria's argument, but don't see how to get to where she wants them to go.

They may be afraid that if they do what Gloria suggests, their managers will be angry.

What Gloria doesn't get is this: while logic is appealing, it isn't always the most effective tool for persuasion.

Rather than try to win through logical argumentation, Gloria might try understanding:

what other people value
what other people fear
what obstacles other people face
what problems they want to solve.


Saturday, April 07, 2007

Overcoming "resistance"

Back in February, I wrote a post on helping people change and pointed to George Dinwiddie's post on Overcoming Resistance. His post has grown up to be an article, and it's posted on the AYE Conference website.


Wednesday, March 21, 2007

Estimating hard-to-measure benefits

Last week, I wrote a post about decisions that look only at easy-to-count costs and ignore hard-to-count benefits.

Here’s one method for estimating hard-to-count benefits, subjective impact analysis:

1. Identify the proposed course of action.
2. Determine what’s important to the person who makes the decision.
3. Ask that person who they consider credible sources related to the issue.
4. Create a short interview protocol.
5. Interview the people the decision maker identified as credible.
6. Summarize and present the results.

Here’s part of a subjective impact analysis I did for a client a billion years ago (suitably scrubbed).

The client was a VP in an IT operation. The business was livid about the production problems and outages that followed when the IT group installed new functionality.

When I looked at the data about outages, it was pretty clear that the worst problems came from the hand-off between the development folks and operations folks. I poked around, and found that the two groups weren’t working together.

So I suggested a little experiment: a “readiness review” prior to installing a change where the development people and the operations people would sit down together and walk through the installation. And I created a half-page checklist for the development people to actually write down critical information for the ops folks.

Then we tried the experiment. We held a "readiness review" for a smallish update to the production systems. The meeting took about 45 minutes.

After the “readiness review,” the IT managers told the VP they were concerned about adding another meeting that took away from development time. The developers complained about the burdensome documentation (half a page).

The costs were obvious.

The benefits were not so obvious.

So I did a subjective impact analysis to show the benefits (if there were any).

Here’s what the VP valued:
• Avoiding production problems
• Improving the application
• Taking a proactive stance

I asked a cross-section of the people who participated in the review these questions:

1. What gaps and issues came up in the review that could have caused problems had they been discovered in production?

• What was the biggest problem discovered in the review?
• On a scale of 1 – 10 (1 = negligible impact, 10 = disaster), how big would that problem have been?

2. What was the team able to do to improve the application because of the review?

3. What problems did the team fix before they hit in production?

Then I summarize the data and presented it to the sponsor. Here’s the data from the first question.

Problems Discovered in the Readiness Review
(1 = negligible impact, 10 = disaster)

10 ****
9 *
8 ***
7 **
6 *
5 *
4 **
2 **

(This represents each person's assessment of only the biggest problem, so it’s a subset of the problems. For the most part, the development folks identified lower impact problems, the ops folks higher impact problems. Very interesting...)

This little data table helped people see the benefits of the readiness review, as well as the costs.

(Obviously, there were lots of other issues with this organization. This was a starting point to bring the level of conflict down enough for people to look at underlying problems.)

I did this subjective impact analysis after the fact, but you could easily adapt it to estimate benefits before making a decision.

Labels: , ,

Wednesday, February 28, 2007

A change story

I’ve been noticing a problem in my office lately. My dog, Pudge, spends a lot of time in the office with me. She has a blanket in the corner where she hangs out and naps or chews her nyla bone. The only problem is that the blanket tends to spread out and cover a large expanse of the hardwood floor right across the entrance into my office. Then I come in and step on it and go flying. Plus when it’s spread out, it’s not very cushy for Pudge.

So I had the bright idea to improve things and make things better for both of us.

I sent away for a fine, cushion-y, and washable dog bed. I measured Pudge, and I measured her other favorite spot (a chair in the living room) to get the right size.

I was sure she’d love it. Why wouldn’t she? The new bed would be much better than the ratty old yarn blanket, much cushier and more comfortable. And her nyla bone wouldn’t get snagged in the yarn and all tangled when she pawed the blanket around.

When the new dog bed arrived, Pudge was curious about the box. She was even curious about what was in it.

But when I took her ratty yarn blanket away, her curiousity vanished. I put the cushy new dog bed down and urged her to try it. She sniffed at it, then took her nyla bone into the kitchen for a good chew. Over the course of the day she moved all her chews and toys to a new location, far away from the new bed.

The next day, instead of hanging out in the office on her fine new dog bed, she sat in the kitchen on the hard floor. After a while, I enticed her onto the new bed with a biscuit. She stepped gingerly onto the bed, picked up the biscuit and left. Later, I picked her up and put her on the bed. She stayed as long as I was scratching her belly, then headed back to the kitchen.

Eventually, she accepted that her ratty yarn blanket wasn’t coming back and started lying on the cushy new dog bed. We’re in a new status quo. She’s content in the corner of the office, all her nyla bones have migrated back, and I’m not tripping on the blanket.

So what can a story about my dog tell us about change?

  • Our wonderful ideas of how to make things better for other people may not be greeted with enthusiasm.

  • Other people may value things about the old way that we don’t see or don’t appreciate.

  • Things that we don’t like about the old way may be valued by other people.

  • It takes time for most sentient beings to adjust to a new way.

  • People accept the new way to retain something they value.

  • Even when the new way is accepted, people may look back fondly on the old way.

    So don’t take someone else’s lack of enthusiasm as an indictment of you or your ideas--but look at how you introduce your ideas.


  • Tuesday, February 20, 2007

    Helping people make changes

    George Dinwiddie posted a story of how he over came "resistance" to a change he was proposing.

    I wrote up a description of the types of changes I was proposing and made my pitch to the team. As I talked about making these changes (and making them incrementally, as we added newly requested features), I could tell that they weren’t really enthused by the idea. I poured on the heat of persuasion, describing the benefits in the short term of the immediate features we were developing. The less progress I made, the more enthusiastic I became, scribbling UML diagrams on the whiteboard and building castles in the air as I pointed out the advantages in the long term of making some significant changes we knew were coming down the pike.

    I got nowhere but exhausted. I stopped, wondering how I could get these procedural programmers to understand the benefits of object-orientation. I was trying to figure out what to say next when a senior member of the team said, “I don’t think there’s anyone in this room who doesn’t believe you when you say this is a good thing to do. We just don’t know how to get from where we are to what you describe.”


    I guess I should have asked more questions.

    How did I get over this “resistance” to my suggestions? I can think of three distinct ways, demonstration, discussion, and retrospection. The demonstration is focused around what I did, as I provided examples of what I intended and described how I got from the current code to the new code.

    This is a great example blasting the notion that people who aren't following our ideas are "resisting." What "resistance" really comes down to is that other people aren't doing what we want or expect them to do when we ask them to change.

    This may be because...

  • they don't know how (as in George's story)
  • they don't feel they have time
  • they think their way is better
  • they don't think the new way will work
  • they don't like/repespect the person requesting the change
  • the new suggestion is counter intuitive given people existing mental models (or what they've been taught)
  • the new suggestion runs counter to existing reward structures or other organizational systems
  • the new suggestion doesn't make sense to them
  • they have no experience that tells them the new way will work, or how it will work.

    Listening for what's behind the "resistance" gives valuable clues on how to move forward.

    Unfortunately, I hear many people--even those who hope to influence others to change--label people who are "resisting" as clueless, stupid, or selfish. Some would-be change agents attack the motives of the people who aren't following their ideas, accusing them of wanting to bring the company down.

    This may make the so-called change agent feel superior, as he/she belittles people who don't get his/her wonderful ideas. But it doesn't help him/her bring about change.

    Change artists listen and adjust their approach based on what they learn. They try to make it safe for people to try new ideas. And change artist never ascribe maliciousness to what can be explained by simple ignorance (which is lack of knowlege, not lack of ability or intellect).