Home | Login | Recent Changes | Search | All Pages | Help

ItsJustOneSmallChange

As I write my PM book, I'm realizing I still hear this from people on projects: "It's just one line" or "It's just a small change" or something else. And because the project team does not have enough regression tests, nor have the developers been using test-driven development, we don't actually know how bad things are.

What's your favorite line? What do you say when you know the risks could outweigh the value of the change? -- JohannaRothman 2006.09.27

I have two responses. The first is swiped from Jerry: "So is an airplane propeller -- until you walk into it." That tends to get people's attention.

The other is drawn from many years of experience, sometimes grim. "Whatever time you're estimating this will take -- multiply by 3. That should just about do it." --FionaCharles 27-Sep-2006 (I've said this all before somewhere, probably on this wiki.)

"Oh, that's easy . . . (for you to do)." The "for you to do" is silent. Reply: "Cool. So, that means you'll be done soon and we don't have to talk about it any more." Of course, all subsequent conversations begin with "Done yet?" and go no further until there is a proper answer to that.

A minor variation is "Oh, that's easy . . . (for me to do)." Again, the "for me to do" is silent. "OK, so let's make sure you are available to take care of things if it doesn't turn out to be so easy. What do we need to set aside for you to . . . " Similarly, all further conversations are simple, until the "easy" thing is actually done.

-- JimBullock 2006.09.27 (I start by claiming that everything is hard. Then they're impressed when anything gets done at all.)

As I consider the phrase, "It's just ...", two things quickly pop out. "Just" is a lullaby word. See LullabyWords. The other deals with systems thinking, and in systems it's not possible to change "just one thing." DonGray 2006.09.27

For "one small task" read "one tiny change". There's always a limit to how much work a team can do, but it's rarely marked with a bright line.

--DaveSmith 2006.09.23

You are kidding, right? You have to be kidding. "Those managers who said . . . " There were some of those? Seriously, has anyone ever admitted to answering "Yes" to that one? Clung to their "yes" for more than a nanosecond? Failed to laugh at their own folly when it was pointed out?

This really happened?

-- JimBullock 2006.09.27 (I thought I was crazy. Apparently, not so much.)

But Jim, you are crazy...

I've met a few managers (and more Product Managers) who acted as if they believed they could always squeeze just a bit more out of the team. I suspect it's fallout from the leadership myth that one can always be a more effective leader. --DaveSmith

And I'll bet many managers have had a positive experience with making a last second change. Each success reinforces that a last second small change will work.

The managers who learned that high risk may result in high penalty rather than high reward may be gone leaving only a pool of positive thinkers. And positive thinking will naturally cause the change to work as planned. Right? If the change doesn't work, distort the effect or blame someone who was thinking negatively.

SteveSmith 2006.09.29

Ah, well, that explains it. I am crazy after all. Somehow, that's reassuring.

How about this for "always being a more effective leader." I can't create more good stuff - that's what the people around me are for (and if I were worth a damn at doing actual work, I'd be doing that too.) The best I can manage is to *continually reduce my negative impact* on the good stuff that's possible with this bunch of people. So, it's kind of like the second law of thermodynamics. The best you can do is break even, and you can't even get the whole way out of the way, so the best you can do in practice is worse than that.

I think maybe Steve's example would serve as a quality test for managers of technology efforts. One, small change that works, and they note that "We got lucky." and go work to see that we don't have sudden "needs" pop up again. Go work for those folks. Anybody with a different reaction, not so much.

I have had three and a half bosses in all my time who really got the "quick change" thing. The three were former engineers. The half was an architect in a previous life, with a real drive to understand what he was trying to manage. I think it has a lot to do with their mental models of the work, the social system that does the work, and of course their place in that social system.

Engineers are fatalists, really, at least the ones who get it. That's a strangely empowering perspective.

-- JimBullock 2006.09.29 (Crazy only because I can't help it.)

Joe, the CEO, made a deal with company X. If we make this small change to the software, X will buy $10M of our products this quarter. We need this revenue to meet the commitment Joe made to Wall Street. The stock will be hammered if we don't receive the revenue.

Johanna asks, What do you say when you know the risks could outweigh the value of the change?

No.

Did I miss something? Is this a trick question?

SteveSmith 2006.09.29

"What are you willing to give up to get this?" - JimBullock 2006.09.29 (I'm easy but I'm not cheap.)

Answer: Nothing.

Are willing to accept dissatisfied customers? Answer, No. And stop trying to negotiate with me. I didn't try to negotiate with Joe. He said we must do whatever it takes to gain the revenue. He said make it happen. So just do it.

Despite my glib reply, it's the right question. Sadly, middle management may believe that negotiating with the people at the top is a bigger risk to their career than going with the flow. They might think differently if they thought their roll of the dice had to result in either snake eyes or box cars to win, any other result would end their career. Negotating with upper management would become an imperative rather than a dangerous action.

So what would you estimate the odds of a last minute change being a failure? What data backs up your estimate? Do all last minute changes have the same odds? How would you assess the impact of a failed change and feed it up the food chain?

SteveSmith 2006.09.29

I beg to differ. ". . . He said we must do whatever it takes to gain the revenue. He said make it happen. So just do it. . . ." Seems like a mandate to me. Seems like direct, explicit direction that anything else and potentially everything else is on the table. BTW, this is why I never, ever say "Whatever it takes." when I'm the boss. Then, the guys go start burning cars in the parking lot, and declare that I told them to do it. Not good.

(Rest of suggestion for managing up extracted to: AyeWantWhatAyeWant. -- JimBullock, s006.10.02)

Jim's got a point about not getting on the hook for someone else's decision. One of my scarriest professional moments was staring down the gun (figuratively) at two levels of managers who were trying to get me to commit to someone else's untested fiction of a schedule. Putting myself on to that hook probably would have been hell. I stayed off it by being very clear about what I could commit to, and by suggesting some sanity tests on the schedule that could get me to advance my level of commitment.

I found out later that the managers were already suspicious of the schedule, and were testing it by seeing who would sign up. (A dangerous test, given how easily many developers will cave to perceived pressure.)

--DaveSmith 2006.10.01

"We decreased your estimates by x% because we know that is all the customer can afford. But you will still do all the the same tasks."

This comment usually comes as part of the bidding process. How the managers know what the customer has budgeted is an eternal mystery. I suppose it is the same way they just know that we can get the same amount of work done for less than estimated.

DennisCadena 2006.10.02

Now, sometimes I think the risks outweigh the reward -- in other words, I think that the cost of the risk occurring multiplied by what I consider the risk's probability of occurring is greater than the value of the proposed change. When that's the case, I tend to start asking questions that test both my understanding of the risks and my understanding of the rewards. Perhaps I'm not aware that the contract really does hang on this one silly-seeming feature. Perhaps I've misunderstood what the problem really is. Perhaps there's an alternative approach with lower risks and/or higher payoff.

Actually, the more honest answer is I do all that question-asking when I'm afraid that the risks outweigh the reward - and that dealing with the consequences will be personally more painful than I want. If the situation is one where even the worst-case pain is minimal, I'm much more willing to forge ahead. (TestDrivenDevelopment is a classic example; knowing that I can back out of a coding hole cheaply gives me the confidence to risk getting into one in the first place.)

-- EdmundSchweppe 2006.10.02

It just occurred to me that, while it is fun to snipe at Those People Who Are Silly, some people are less silly. Also, it's part of our job to help others be less silly - including bosses. So:

• EffectiveBosses
• EffectiveBossesWhoWrite
• HelpingBossesBeSane
• AyeWantWhatAyeWant
• WhatOrganizationsWork