The Five Conditions for Improvement

by medium.com6 min read

The Five Conditions for Improvement

Roy Rapoport

Jul 26, 2017

Bob reports to you, and you notice Bob has some sort of performance problem that will need to be rectified, because long-term (which means anywhere from a month to a year), this problem will affect Bob’s chances of keeping this job. What’s required for Bob to be able to turn this around? I’d argue five questions need to be answered affirmatively, more or less in order:

  1. Does Bob agree there is a problem? There’s no point in discussing remediation if Bob still doesn’t believe there’s a meaningful problem here. It’s a classic case of begging the question;
  2. Does Bob actually want to see this problem resolved? If Bob sees the problem, but thinks it’s perfectly OK — maybe it’s not a high priority right now, or not something he thinks he should care about, nothing good will come of this;
  3. Does Bob see his role in the creation or ongoing care and feeding of the problem? If Bob’s thinking “yup, it’s a problem and I’d like it to be solved, but it’s got nothing to do with me, I’m just a victim of it, and I can’t do anything about it,” Bob’s assumption that there’s nothing he can do to mitigate or solve the problem is likely a good sign that you can rest easy that until this changes, Bob will in fact do nothing to mitigate or solve the problem;
  4. Can Bob figure out a plan to solve the problem? Imagine Bob agrees the problem exists, needs to be solved, and that he’s not helping. But if Bob can’t figure out what to do about it, it’s likely not going to get better;
  5. Can Bob successfully execute his plan to solve the problem? This may take some time to prove out; in the process, the plan Bob came up with initially may prove to not be ideal, and he’ll need to pivot. That’s OK — startups do it, products do it, people can do it too.

And … that’s it. But what the hell does it mean?

Well, for one thing, this helps figure out what conversation we need to have with Bob, because in the absence of agreement on an earlier item, discussing a later item is a waste of time, and feels like “my boss is telling me there’s a problem, and that I’ve got to fix it, but I don’t see the problem, so I’m going to grasp at random straws to at least show that I’m trying.” If Bob and I don’t agree there’s a problem, we need to figure that out, and get to the point where we have agreement on that point before we get to, say, a plan on how to fix it. Having read some awful first-hand accounts of people on PIPs, that pattern — “My boss said there was a problem I didn’t see, and made a plan for me to remedy it, which I executed by rote” comes up time and time again.

The other, more terminal, part of this is that failure to go through some of these stages will help you get a clearer perspective on the likelihood of things working out. To some degree, the steps above are listed not just in likely chronological order, but also in order of how long it should take to go through them. I’d be surprised, given the caliber of people I work with, to have “is there really a problem here?” be a matter of debate or prolonged discussion; it might take more time for Bob to figure out what his contribution to the problem is. It will definitely take more time to figure out if the plan Bob comes up with actually ends up working out. I suspect most PIPs don’t work out because people skip over the three questions — Is there a problem? Do I want to solve it? Is it mine to solve? — and jump directly to the plan and its execution, which take the longest time. Stop doing that. If Bob doesn’t actually see the problem, see himself as having a role in the problem, and want to solve the problem, no plan in the world will make Bob fix this problem. Give up now.

When I Was Bob

The First Step

At a one-on-one with my boss, he said “hey, I see this performance problem you’ve got, that I’ve come to conclude is pretty severe, and potentially terminal. Here’s some evidence of it. What do you think?” Given a severe enough problem, this should not have been debatable, and I should not have needed a long time or material evidence to convince me that this problem existed. The good news (for me, and to some degree my boss, who was far more interested in having me be successful than firing me) was that I was able to respond with “Not only do I agree with you, I happen to have presented a talk to my team last week where I discussed at length this problem and how seriously I was taking it. Here’s the slide deck … “

The Second, and Third Steps

We discussed, Boss and I, whether I saw this as a problem that needed to be solved, and that I was contributing to. This was an easy case — it was all on me, and while in some cases one might be suspicious that the Bob one is talking with is just trying to say the right thing to not get fired on the spot, in my case having some evidence that I had already proactively acknowledged this with my team and started working on it made my stance on (2) and (3) above pretty clear and unambiguous.

The Fourth Step

There wasn’t much more to discuss in that meeting. We concluded it by agreeing that I would go off and figure out a plan to address this. That plan wasn’t so much about outcomes — outcomes are easy, how to get them is a little more difficult — but rather how I would fundamentally change my approach (in this case, to unnecessary conflict) so as to result in the right outcomes. By the end of the week I sat down with him again and shared my perspective, along the lines of “OK, here’s how I’m going to change my conflict management model to accomplish the outcomes we both want.” That still didn’t give him (well, or me to be honest) complete confidence I could execute successfully, but it was a credible plan.

The Fifth Step

Time passed. Every few weeks we caught up informally about how things were going. Every once in a while I’d explicitly mention “here’s one case where before I would have done something different, but based on my plan I’m doing this thing right now. Seems reasonable?” Over the next few months, we saw that the plan was working, and I had resolved the issue.

That’s what successfully going through these steps looked like in this case. It required both of us to be thoughtful and explicit about which step of the process we were on — there was no use trying to figure out a plan if I wasn’t onboard, owning the problem, and highly committed to solving the problem. It worked for us.

See if this is useful to you. I’d love to know if it is.

p.s: A Note On Being Bob

When I wrote this post and asked some friends to read it, someone asked if everyone I works with knows of the performance problem I went through in 2016, and whether disclosing this would cause me to suffer some stigma.

And … maybe. Maybe it will.

I’ve gone through the process above from the perspective of the other party at the table, as someone who’s worked with people to help them improve their performance. Some succeeded and stayed, some failed and left.

It’s rare for us to acknowledge failure. It’s rare for us to talk about “the time I had a performance problem,” and generally this means that most discussions of working through a performance problem come at it from the perspective of “and then I was fired.” I’d love to shift that conversation. I’d love for us to see more discussions of “that time I was failing, and turned it around,” because otherwise we’ll continue with the stigma of dealing with performance improvement as the obvious last step before someone’s fired. There’s hope. You can turn things around. And talking about when we were failing and turned things around is (IMO) a necessary reminder for all of us.

 See original post

Share article on
 Facebook Twitter


Created by Articled

Create your own reading lists.
No ads, no distractions.
Share with anyone.
Even send to your Kindle.