Hold me, I’m scared!

Fear is a terrible thing. And while some fears are justified, they are mostly overblown. Putting your fears into perspective is difficult. My first job out of college was a contact job working on the software for a blood banking system (I’m sure I’ve written about it before). Knowing you could kill someone if you screwed up the code… that’s fear! I can see how that might paralyze you from changing the code. On the other hand, if you knew something was wrong with the project, it is the same fear that would drive you to action.

In my case, the company was developing a new test for some sort of antibody screening. As I understand it, there are several types of blood products you can give the machine that it recognizes – centrifuged whole blood, plasma, or serum. For all intents and purposes, plasma and serum are interchangeable in the types of blood tests that the system could perform. However, this new test being developed for the system only worked with plasma (or serum, I can’t remember which, but it doesn’t matter except that it only worked with one of the two blood products). However, since in the entire history of tests they were interchangeable we listed the available option as “plasma OR serum.” Now, the people using the machine were supposed to know that they should only use the right product, but the machine didn’t have any warning about it.

While I knew there was something wrong with our system, I feared telling them that they needed to delay the release of their new test was going to raise their anger. Who was I to tell them? I’m not a scientist, I’m a programmer. But I swallowed deeply and expressed my concern. Their reaction was miraculous! They listened! They stopped, looked at me, thought about it for a minute, and said “you’re right. What can we do about this?” Then they invited me (a just out-of-college programmer) to meet with their scientists and discuss a solution! The collective desire to produce the best product outweighed the fear of management’s ire that we were delaying the product while we solved this problem.

So it was with some disappointment that just this other day I encountered fear at the office again. In the business I work in, no matter what we do wrong, nobody will ever die. The risks are not nearly as great, but it is still a business and there must still be a drive to do what is best – and to be ready to hear it if we are not doing the best we can.

We were in the process of reviewing a random sample of defects which we had gone back and looked for root cause. The data was pretty detailed – people seem to remember their bugs very vividly for some reason, especially high severity bugs that cause us to back out of pilots. We took all this data and we grouped it up and looked for patterns of mistakes where we could improve the process. Lo and behold, one big thing that came out was basic coding errors – the kind that could be caught by a static analysis tool like JTest. Stupid stuff. So I said to the manager we were working with “we need to go back to development and tell them they’ve got some basic coding issues.”

At first his reaction was “isn’t that kind of cliché?” I said “why? If they have basic coding issues, they’re really there and easy to work on.”

“Isn’t it quality assurance’s fault too?” the manager said.

“When’s the last time that QA ever injected a defect into the code?” I replied. “This is a development problem and it needs to be solved by development.”

“We can’t go back to development and tell them they have sloppy programmers! They have some good programmers too!” he retorted.

Alas, fear won out over doing the right thing here. The manager I was working with feared that we couldn’t go back to development and tell them they had a basic problem. It was ok if we went to them and said “you’ve got requirements issues” or “you’ve got a knowledge gap” but for some reason, if the blame fell directly on their shoulders they were unwilling to hear “you’ve got a coding problem.” We’ll never know if they would be willing to hear it, because apparently we won’t be telling them the truth of the matter on that one. We’re afraid they might react badly.

Fear of doing the right thing: 1, Us: 0.

Not one of the critical few

Ingrained in the Six Sigma school of thought is the critical few – the 80/20 rule. It is an important rule. In practice, there are a handful of things which often allow you to make big leaps from an incapable process to a capable one. There are more subtle characteristics of the process which can be refined to continually improve the performance, but this isn’t step change, it is refinement. And then there’s a class of things that just don’t matter.

So as I sat today through a long, long meeting trying to define a process, I spent a lot of time thinking about the things that don’t matter. That may have been because that’s all anyone spent their time talking about. And as facilitators, we were enablers of this dragging on. Having been instructed to drive to a single standard process and toolset, we discussed every little one-off thing that people wanted to allow for in the process to see if we could squeeze them out. A day’s worth of 25 people’s time to design a process spent talking about the equivalent of the carpet color.

We wanted perfect compliance to the standard, and that meant a standard which was not necessarily all-inclusive (because some of these one-off requests were truly ridiculous by any standard). This is where I believe we got off track with process work. Process design is about controlling the critical few things which will make the difference in process performance.

But that is not what we were discussing. We were discussing nuances, oddball cases, odd uses of the process, and data elements that some teams wanted and others didn’t. We talked about the 1% and largely ignored the 99%. We talked about things that weren’t going to make the difference, whether they were one way or another.

To begin with, we didn’t know what was going to make the difference. We hadn’t studied the existing processes to understand what made them work – what really mattered and what didn’t. This created unnecessary room for debate because we were unable to bring adequate materials to the table to help the team work through their differences. We had little to no information on what mattered and what didn’t.

Instead of define-measure-analyze-improve-control we just went right into improve. And there we got bogged down discussing every little quirk, because we didn’t know what else we ought to be talking about. Or more importantly, what we shouldn’t be talking about.

Instead of a conversation that was “do we really need that? How many of our teams use that process step?” we could have instead said “sure, it doesn’t matter to me if you allow for that.” And we’d be saying that not because we didn’t care but because we actually knew what did matter. Everything else, the little things that we debated with the teams could have instead been bargaining chips that we could dole out in heaps and have given up basically nothing that really mattered. We could have had a strong position, not because we won all the arguments but because we knew which battles were worth fighting and which were worth conceding.

Had we known what things were not one of the critical few things, we could have appeared very agreeable and allowed the teams as much “leeway” in the process as they claimed they needed. All along we’d be giving up nothing. Nothing that really mattered anyway.

It’s a reminder why a thorough measurement and analysis of a process is important. It isn’t just discovering what the current state is (measurement), but it also understanding why it works (analysis). And from there, narrowing down the bits of process that really do matter, and just letting the rest go. Some things just don’t matter.

Thoroughly considered or just the way it is?

I can never tell if my educational trips actually change mindsets of the people I bring along with me.  Sometimes I think that although people intuitively get the ideas being presented that it never affects behavior.  It’s like emotional intelligence (EQ).  Sure, you can know what the right answer is, but will you actually behave that way when push comes to shove? 

At any rate, though I wonder about the value I’m providing to people I often learn interesting things about my students.  In some ways, the teacher becoming the student is my favorite part of teaching.  Accepting that I know nothing (or at least very little) is what inspires this blog.  If I thought I knew all the answers, I wouldn’t be mulling them over in my head and writing my ruminations in this blog.

So I return to the scene of a recent trip to 5 Guys Burgers to discuss a student who came along.  This student, is an interesting sort of person.  I find that in some cases he’s really thoughtful and in others he doesn’t want to make the leap from “hey, if it works in a burger joint, could it work in a big company?”  It’s the power to extend a learning to a bigger thing, and I don’t think the inability is unique to him.

The interaction went something like this:

“Bob, see what they’re doing with the fries?  First they take a Styrofoam cup and load it with fries and then they put that in the bag and throw MORE fries on top.  What a waste.  Why do they need the cup?  Or why isn’t the cup the right size?”

And Bob’s response was “well, it’s part of their value proposition.  You get a lot of fries for your money.” 

Now, I’ll grant you that there were a lot of fries in the bottom of my bag, but I’m not sure that’s the issue.  The question in my mind is, did they get this way (of throwing excess fries into the bag) because they thoroughly thought it out or did it get that way by chance.  In effect, they bought cups that were too small and always intended to provide a larger order of fries than the cups could hold.  If they had bigger cups they’d just use them without the tossing of fries in on top.

It reminds me of a commonly told story about a woman who is preparing a roast for her family.  She takes the roast out, cuts off the end of it and discards it.  Her son, who is watching her, asks “mom, why do you cut the end of the roast?”

“Well, that’s what my mother did.”

“Why did your mom do it, ” asks the boy.

“Because that’s what her mother did.”  But it turns out that the only reason the boy’s great-grandmother did that was because her pan was too small to fit the roast.  The rest of tradition handed down is nonsense.  It doesn’t make the food taste better.  It wastes a part of the roast which could be eaten.  It’s not  a deliberately thought out thing, it’s just a thing she does.

And so it goes with french fries.  We find reasons in the things we see every day to believe we’re doing them for a valid reason.  And that we must continue doing those things hereafter because clearly they were well thought out.

It’s a form of superstition.  Just like wearing your team jersey on game day because you believe your team can’t win without it, continuing to do something without questioning why we do it at all is foolish. 

But it is also troubling.  LEAN thinking is a mindset to challenge the way things are done, and yet we find that it is our evolutionary misfortune to see cause where there is none.  To be leaner, you are going to have to fight against your urges.  While superstition may have saved us from being eaten by lions, it no longer serves the same purpose.  We have the luxury to be able to step back, think about the issue and make intelligent change.

The next time you look at something that needs fixing, you should be able to ask yourself “is this a thoroughly considered way of doing things, or just the way it evolved?”

Now is not the time to be sentimental

I was reading an article on CNN about some guy who received a postcard in the mail.  What was interesting about the postcard was that it was quite old.  The postal service had lost it somewhere and it was found.  They felt obligated to deliver to the address it was destined for and did so.

These stories are always fun for CNN because it’s odd that a postcard would show up that many years later.  And isn’t it a neat piece of history that we just discovered?  We like to look into the past and imagine what the sender and receiver of that postcard might have been like.  There’s an entire site (Found Magazine) dedicated to this ‘art’ of discovering stuff.

But the part of the article that inspired me was the short intro:

“When an Ohio man recently received a postcard sent 47 years earlier, he not only made a connection to Ohio’s history, but put a fresh spotlight on what a U.S. Postal Service spokesman calls “a lost art” that has fallen victim to e-mails and tweets”

‘…fallen victim to e-mails and tweets’?!?!?  OK, it’s a lost art, I’m willing to grant you that.  But a victim?

A victim of change, that is!  And what’s so wrong with that?  Things change all the time.  What is so wrong with this is the idea that clinging to an old thing when a new thing has been discovered that works better.  Email is faster, cheaper, very reliable (it doesn’t show up 40 years later) and conveys the same information that a letter did.  Even better, instead of a generic postcard in the mail you get a picture of the place a person is, right now, taken by their cell phone!  You can share in the experience to some degree.

And that’s the thing about change – change happens because people discover better ways of doing things.  Yet, rather than celebrate the change we mourn the loss of the old way?!?!  How stupid is that?

Change is going to happen.  Fighting it doesn’t make sense.  Regardless of how you loved the old way, were invested in the old way, are used to the old way.  Those that do not adapt die.

Single data-point testimonials

The justification for using a Knowledge Management solution went something like this:  there was a oil company who had a knowledge management community for their oil rigs.  One day an oil rig went down, and when an oil rig isn’t running it is very expensive.  The foreman on rig went out to the community looking for advice on how to get the rig back up, and a problem that would have taken weeks for him to figure out had been experienced by someone else.  They got the rig back up in just a few days instead!  KM is a huge success and everyone should be doing it!

::cough, cough:: bull#$%^!  The testimonial, the worst marketing garbage ever used to justify a business decision.  Now granted, perhaps the several weeks savings from that one oil rig paid for the price of having a KM solution many times over.  The stakes were very high and the cost of KM very low.  But one chance event does not a solution make.

You’d have to be able to show a pattern of improved results with and without knowledge management solutions.  And we cannot explore the alternate reality where this company didn’t have a KM solution in place and an oil rig went down with the same issue.  For all we know, the foreman would have called the most knowledgeable guy around and gotten the same answer regardless of whether there was a formal knowledge management system in place.

A single-data point testamonial is worthless.  One cannot attribute a chance event to something else without being able to show a pattern of causation.  And yet, companies come in all the time to sell us stuff and they always have that great story about how their product saved the life of 101 cute little dalmations, or what ever other compelling story might make you buy their product.

Now, I’d be OK if they had a testimonial which showed a pattern of changed behavior, but that story is boring.  The statistics are boring.  The 2 sample T test that goes along with it is boring.  The intervention analysis that goes along with it is boring.  Boring, boring, boring.

If you’re not a geek like me, you wouldn’t find any of that analysis interesting at all.  The treatment group, the control group… dull, dull, dull.  Despite how critically important all that analysis really is to making a decision, you will probably decide to buy a product, or at least look more closely, based on a great story that someone tells you.

What’s the latest diet fad … Hoodia Rush (it contains Acai… I don’t know what that is, I just type “diet pill” into google and clicked the first link).  “Hoodia Rush worked for me!”  OK, you took Hoodia Rush and you also dieted and exercised… um, what leads you to believe it was the pill?  Two other possible causes were introduced as well – diet AND exercise.  And yet, here’s a smiling handsome man or hot woman on TV telling you, with a smile, that it works.  It must work, right? 

By the way, in case you didn’t know, a friend of mine (I’m sorry to admit this) actually signed up for one of some company’s before and after picture campaign.  You know, the fat, flabby frowny picture on the left, the trim, muscled smiling picture on the right… anyway, the way they do that is they get people who are fit, take the picture for the “after” shot, then the person eats like a pig and lets themselves go to hell and THEN they take the “before” shot.  It’s much easier to do it backwards.  He’s still out of shape, by the way.  In the long run, while he got paid for the gig, I think it might have done longer term damage.

Resist the urge!  It isn’t about a single great story even if the story is true.  Which is to say – they did X and then Y happened.  Notice I didn’t say they did X which CAUSED Y to happen.  It isn’t about false causation.  It’s about patterns and changes in those patterns as the result of things we do.  No matter how many puppies lives were saved in this tear jerking story, it does not make a valid case to purchase new technology or implement a new process.

Don’t be a sucker!  If the testimonial is a single-data point story, you can almost bet that the company doesn’t have a solid, yet boring, story to tell based on sound research.  They have marketing.

Good to be unskilled?

Have you ever wanted someone to say this about your company “wow, we are really horrible at doing X”?  And I don’t mean in a thank-god-they-are-admitting-they-have-issues kind of way, but more in a “I’m really proud we can’t do that well” kind of way.  Up until recently, I thought the answer to my question was “are you crazy!?!?  Of course not!  I want us to do everything really well.”

Like many large companies, the one I work for is undergoing a tough time due to the economy.  And of course, that means layoffs.  I’ve been fortunate to have been unscathed as of yet, and particularly thankful since my well of new ideas would dry up quickly if I wasn’t actively involved in process work.

Anyway, unfortunately, people that I liked at work were not so lucky as I was.  You get around to talking with these folks about how the experience of being laid off is.  I mean, it can’t be fun, but you want to know if it went relatively well.

Of course, it doesn’t go well.  I realize there’s no good way to lay someone off, but there are less bad ways.  I’ve heard horrid rumors of other companies laying people off via email and simply just locking the doors to the building.  We were nowhere that far down on the scale.

But there are always things you can do better.  For example, the process of laying people off starts first thing in the morning and continues until everyone has been told.  But, since you have no warning as to whether you are going to be laid off or not, those of us who kept our jobs sit around in our offices panicking that we’re next.  At some point during the day it is over, and wouldn’t you want to know that?  We heard nothing until hours after the last layoff had been done.

Unnecessary hours, in my opinion, that I should not have had to spend worrying needlessly.  I know, I know, think of how the people who were laid off felt.  Was it really that bad of a thing to leave me wondering?  No, not really, but it could have been done better.

Later on that evening, I considered how lucky I was that our company is terrible at communicating during layoffs.  Why are they so terrible?  Well, it’s a rare occurrence.  If you don’t practice it, even if you learn from a prior experience you never get to apply those learnings.  If my company was expertly prepared to do layoffs, I’d be a little worried.

Sure, isn’t it great that they are super-capable?  No!  It’s awful!  It’s something they shouldn’t be doing, something that they have rarely had to do.  They should be god-awful at it.  Frankly, it hurt at the time, but now I’m downright pleased.

And not just communicating layoffs applies here.  Disaster recovery of all forms might be fair game.  I mean, if you’ve gotten your system, process, product, whatever it is, so reliable that you’re unprepared for when it  fails, that might actually be a good thing.

If you fail all the time, you’ll have the people and processes in place to deal with the failure.  You’ll be expert fire fighters, and that’s just not the place you want to be.

I’m not offering a free pass to companies for not being capable of dealing with a disaster that is likely to occur - like your servers or network going down – but at some point if you’ve really gotten good at something, I’d expect you’d be bad at dealing with the outlier.

Could it be good to be unskilled at something you shouldn’t be doing in the first place?  I think so.

When all else fails, communicate…

Sure, I’ve railed against communication as a solution to your process problems, and I stand by that position.  However, I have found an exception while sitting in the dark and cold.

In case you didn’t know, the northeastern United States was ravaged by a particularly nasty ice storm late last week.  I’ve never experienced anything like it in my life.  The lights went dark about 9pm on Thursday and then the noises began.  In the darkness outside, between the patter of freezing rain were horrific creaks and cracking noises followed by deafening crashes as ice snapped trees like toothpicks.

We live under a canopy of trees close to our house.  It is probably the closest I’ll ever come to being in a war.  I lay in bed, wide awake, still and quietly listening to a constant chorus of destruction.  I didn’t get a wink of sleep.  In the morning, I opened my front door and witnessed the destruction first hand.

Not knowing what else to do, and having been told after calling the local power company that it could be a week before we’d have power back, my family and I packed up and left for greener pastures – namely, family who had power.

For two days, I called my neighbors and the town looking for signs that power would be restored sooner rather than later.  By Sunday, I had found a generator near where we were staying and left my family behind to return home and care for our house. 

Each day, sometimes twice a day, I would call the power company and ask for updates on our street.  Every time I was met with useless answers like “we suggest you make alternate plans” or “everyone will have power by the end of the week.”  They might as well have told me to go hell.  They were useless.

On Tuesday morning, the National Guard showed up on our street to clear it.  By noon we had a crew on the street repairing downed lines.  I don’t live on a very long street, so it took them all of half an hour to get everything back where it belonged. 

Despite how much overtime those crews were putting in, when I went out to talk with them they were friendly, cheery and helpful.  We were told we’d have power back in an hour or two.  Then they left.   That was at 1pm.  I gave them the benefit of the doubt, but by 5pm, with the sun gone and a cold night setting in, I decided I wanted answers.  Since calling the power company yielded nothing, I decided to go to their office.  We have a local light department, so the office is right in town.

When I walked in, the place was abuzz with activity.  A steady stream of people came in and out asking about their streets.  Everyone was met with unspecific answers.  Nobody seemed to know anything.

Frustrated, I left and called the town manager.  I got his assistant, who while very nice, essentially informed me that even the town manager didn’t know what was going on.  There appeared to be no plan, no list of which streets were being worked on now and which would be worked on next. 

I had enough.  Sure, it’s useless, but I called back the light department and started yelling.  I wanted answers.  I wanted to know who had the answers.  Someone had to know something about my street!  I got another useless secretary on the phone.  I demanded to talk to the general foreman.  I was summarily denied.  I told her my phone number and name and said to have him call me with an answer.  I never got a call.

I emailed the town manager, the general foreman and the assistant town manager demanding someone respond with a clear straightforward answer as to what was happening, or not happening, with my street.  Silence.

Sometime during that night, the power came back on.  Yet nobody seemed to know that it would happen.  Nobody was able to say to me that power was just minutes or hours away.  I eventually found out because I had started a practice of randomly calling my house to see if the answering machine would pick up.  Sometime before 9:30pm that same night that I was totally stonewalled, I got power back.

I was glad to return home, but I was furious with the process.  There were so many things that could have been done differently.

First off, I have no complaint with the speed at which power was returned.  I do not blame the crews on the ground for anything.  With as much damage as there was, I understand almost 200 people were in town just trying to get power back.  I blame management.

There’s a process to restoring power to a street.  I haven’t the foggiest clue what it is.  But it’s that kind of information that would be useful.  Expectation setting is important. 

Correction.  GOOD expectation setting is important.  I was told “end of the week” but that was unlikely.  No, I don’t think it would take longer.  In fact, it was highly probably it would take less time.  Consider the situation.  A few major power lines distribute power to the rest of the secondary lines.  Then individual lines from the street to your house connect you to the grid.  Fix the major lines, restore a lot of power quickly.  The distribution is much more likely a heavily right skewed curve. 

Most people get fixed in the first few days because you go for the biggest bang for your buck when recovering from a disaster.  Then, you start dealing with the oddballs – the excessive damage to a single home, etc.  Sure, there are people who won’t get power until the end of the week, but the chances you will get power before then are much greater.

The only way end of the week would have been a reasonable expectation to set would be if it was heavily left skewed.  For example, if the process required that every downed line between the street and someone’s house had to be fixed before anyone got power, then most people wouldn’t get power until all the repairs are done.  But that simply wasn’t the case.

So, what could the town have done differently?

1.  Estimate.  You have to know how many downed lines and trees and etc you have in order to know how much help to request.  Someone must have surveyed the damage while crews got to work.  What’s the mean and standard deviation for fixing a downed line, broken transformer, etc.  Figure out that and you can estimate how much effort to fix a street.  Know that and you can prioritize the streets and start estimating when you’ll reach various streets.

2.  Inform.  What’s the process for fixing a street?  Be specific.  First a cleaning crew shows up.  Then one or more linesmen reconnect the lines.  Then what?  Had I known what happened next I might have understood why it took until late that night to get power back.  Maybe there’s a system imposed waiting period for safety reasons.  Maybe inspections are necessary.  Maybe someone just has to flip a switch.  I have no idea!  But someone knew, and if they shared it, and expectation would have been set!

3.  Provide relevant information.  The town website only said how much of the town had power.  Guess who isn’t looking at the town website – people with power!  Duh!  People with power don’t care anymore.  People without power don’t care that 55% of the town has power!  They care about when they are going to get power!

4.  Leverage appropriate channels.  Guess what?  Old people, and my town has lots of em, don’t use the Internet.  They’re not getting the input because they don’t know to look for it.  Thus, you get overwhelmed with phone calls because nobody even knows you are communicating anything at all.  Even if isn’t particularly useful.

Here’s the thing.  The town couldn’t control the speed at which repairs are made.  Ok, they probably could, but I’m not even going to examine how possibly poor their repair process is.  God knows if they even had a disaster plan.  It sure didn’t seem like it.  But let’s assume they did and let’s assume it was relatively optimized.

They had a lot of work to do.  It was going to take a lot of time.  If you can’t change that, then you need to communicate more than “end of the week.”  That’s not communication and that doesn’t help people whose lives are affected plan what they should do next.

The amount of time without power might determine: Do I pay for an extended stay in a hotel?  Do I buy a generator?  Do I just shiver?  Will I have to discard the contents of my fridge?  There are financial implications!

When disaster strikes, whatever process you have to deal with it may be adequate, but that’s hard to tell from the outside looking in.  If you’ve just got too much to deal with, communicate.  And good communication depends on a) knowing what your process is and b) knowing how your process performs so that you can set realistic expectations of the result.

But we’ve always done it that way

It’s another example of thinking that what you have is what you need.  This time it’s a story about priority and severity.

What the heck are priority and severity anyway and why should you care?  Well, if you’re a quality assurance person, apparently they’re both very important.  Priority is the order in which you as a tester want things fixed.  Severity is “if this defect made it to production without being fixed, how bad would it be.”  There is a difference in theory.  For example, let’s take the case of legal disclaimers. 

As a QA person, even if the legal disclaimer is wrong, it doesn’t block you from testing anything.  It’s just text on the screen.  So, as a tester that would have low priority for you.  However, if it went to production with inaccurate legal content the ramifications for your business could be quite dire indeed.

With that justification in mind, one could argue that priority and severity have very important and separate purposes.  Well, that is until you look at the data.  For some reason, probably just experience or insight or whatever, a senior manager said “do we really need both fields?”

Sure enough, the managers of the team jumped to the defense of the two fields.  Oh yes, they exclaimed, this is how we manage our tests.  Anyway, I pulled some data.  Some is probably an understatement, actually about 10,000 defects that had been logged over the past years.

And then we brainstormed some questions that we wanted answered.  Is priority or severity affecting how quickly bugs get fixed?  Do priority and severity move independently of each other?  Is priority or severity being downgraded in order to get things into production?

The answers were fascinating.   For one, neither priority nor severity affects either the median or interquartile range of duration it takes to fix a defect.  To clarify, if you rank something as a high severity item it takes about 5 days to get it fixed.  If you rank something as a normal severity, it takes about 5 days to get it fixed.  And the same goes for priority.  With one exception.  If you rank something as low priority it still takes a median of 5 days to get it fixed, but the interquartile range changes.  Instead of being from 1-10 days it becomes 1-30 days.

Secondly, we checked to see if priority or severity move independently.  We have two attribute variables – priority and severity.  Priority can be 1, 2, 3 or 4.  Severity can be 1, 2, 3, 4, 5 or 6.  It’s a simple test to do a chi-square table.  And what do you know, statistically significant evidence that priority predicts severity…

Finally, is priority or severity being changed in order to get things into production.  Honestly, this was a bit of tangent, but someone brought it up in defending the use of two values.  They pointed out that these values were so important that people would change them lest the release management gods find out that a high priority defect wasn’t fixed before the install.  It’s not true.  Of the 10,000+ defects we looked at, less than 2% ever had their severity revised at all.  Of those 2%, about 33% had their severity increased while the 66% had their severity decreased.  Yet, for the ones that did have the severity decreased, there was no evidence that the changes occurred in conjunction with install dates.  In fact, changes in severity were evenly distributed throughout the month.

The point is this.  All these people thought that having two values was an advantage to them.  They needed two values to get their jobs done, they claimed!  I admit, it’s a small victory for data analysis, but it points out something important.  Just because you’ve always done it that way doesn’t mean it’s right or sensible or even that you’re getting anything out of it.  Going with your gut, not such a wise choice.

By the way, it’s a good change management story since this new senior manager really likes data.  And convincing the most senior person that you’ve done your homework is an easy way to get the troops to fall in line.

The receiving end of bad change management

There’s nothing better (sarcasm alert) than being on the receiving end of bad change management, especially from the people who are supposed to know how to do it well.  Part of it that drives me crazy is being aware of why I am unhappy with a change and yet being unable to control how I feel about it.  On the other hand, if I was unable to empathize with people, change management skills might be completely absent for me.  So, let me take you through the situation, why it made me mad and what the better alternatives would have been.

It’s a standard affair of the corporate shuffle.  People come and go all the time, but this time it was my immediate manager.  My manager is off to a new role in the company, and while I am happy for my old manager, the process of change was still not well handled.  We’ll call my ‘old’ manager Bob (because I like the generic name) and my ‘new’ manager Joe (also another good generic name).

Let’s begin at the beginning.  Odds were good, and somewhere in the back of my mind I was aware, that Bob would be leaving.  But for some reason I just assumed Bob was just, what’s a good word for it, speculating when he said things like ‘there’s this new role out there’ and ‘this new initiative is coming.’  I don’t think I’m dumb, but you probably weigh friendly conversation with the likely occurrence of something really happening and dismiss it.  So, lesson one:  people dismiss things you try and say in a subtle manner.  If you want to tell your employees something, don’t be subtle.  This is a good time to prepare them for change if it might really happen – BEFORE THE CHANGE IS UPON US!

At some point between those ‘friendly conversations’ and now, Bob did take a job with the new team.  And then Bob set up the ‘vague’ meeting.  You know how those things go.  If EVER (and I mean ever) a meeting shows up on your calendar with a vague topic like ‘team updates’ and the body of the message says something like ‘I’d like to share with you some updates on goings-on’ you immediately know that someone is leaving.  Nobody sets up a meeting on short notice, with a vague subject and no real content.  I accepted the meeting invite and emailed Bob “are you leaving?”.  Bob didn’t respond, so the answer was clear.  By the way “pleading the fifth” in court, in my mind, is basically an admission of guilt.  So is “no comment”, and of course so is not responding.  Lesson two:  you can’t set up a vague meeting on people’s calendars and not start a rumor mill.  This is not the way to tell your team you are leaving.  No scheduled meetings are going to be acceptable.  You’re giving people time to stew.  Sit down with them one on one and tell them.

So anyway, Bob held his meeting with us.  Of course, the walk to the meeting room with him was like The Green Mile.  Can you say “awkward”?  We ended up in the cafeteria because the first - and second – conference room that Bob booked were occupied.  It was like watching the executioner fumble with the lever to the trap door.  Painful.  Lesson 2b:  If you’re going to schedule such a meeting, don’t drag the start of it out.

Bob put on a smile and told us he was leaving.  There was silence at first, and then Bob tried to fill the silence with a message about how good it was going to be.  Bob was taking some of his responsibilities with him, and isn’t it good for the company that those ideas would get new exposure at a new team?  Um, I could care less.  Lesson three:  Helloooooo…. the mantra of change management is ”what’s in it for me”, not “what’s in it for the company” for a reason.  You told me bad news and attempted to offset it with good news for the company?  I don’t care and you aren’t softening the blow.  Lesson four:  Following on the heels of lesson three, silence is not a bad thing.  Filling the silence is not helping.  This is a loss situation, so people need to go through the stages of grief – denial, anger, bargaining, sadness and eventually acceptance.  It isn’t a “big” loss, relatively speaking, but it is a loss.  If you spend your time talking instead of listening, you are keeping all of us from starting the process.  Lesson five:  (man, this was a bad meeting).  Don’t hold a half hour meeting to tell people you are leaving.  No coping is going to occur in the 10 minutes left after you’re done announcing.  If you’re going to hold a meeting (and I already said you shouldn’t do that in the first place), provide ample time. 

By the way, we all know the corporate game for change.  It doesn’t matter how happy or not happy we are about the change, the game is that we all feign that we’re OK with it.  It is ‘unprofessional’ to vent.  This is, of course, totally wrongheaded.  Venting is natural and should be encouraged (within limits).  At any rate, Bob tells us that our new boss will be Joe.  Time’s up!  I have another meeting to attend (see lesson five).

So at this point I’m mostly angry.  Denial?  That’s pretty easy to get over.  I’m not really angry at my old boss.  In fact, I really liked my old boss.  Personally, I can get paid decent money to work anywhere I want, which means that job satisfaction is a big part how I choose where to work.  A big part of that is choosing a boss who I’d like to work for.  I don’t know Joe.  I don’t know if I want to work for Joe.  I’m not pleased because I don’t like uncertainty.  Guess what, I’m not alone in feeling that way.

The work day ends.  I tell my wife the story because I want to vent.  I love my wife, but for some reason I often dread telling her about things that make me unhappy.  I think it’s because she attempts to sympathize.  It’s not her fault, but her communication style doesn’t work for me when I’m unhappy.  But I digress, my wife is not part of the change management strategy (or lack thereof) that was employed in this situation.

The next work day begins.  I’m still in the same state, since I haven’t got any outlet for my anger.  Bob ‘decides’ to not cancel our team’s weekly meeting.  Clearly, Bob wants out and by holding this now otherwise pointless meeting Bob can introduce Joe to the team.  I’m irritated again.  I still haven’t gone through the coping process and Bob is pushing Joe.  I’m still ambivalent about Joe.  I haven’t even had twenty four hours to consider the situation on my own.  Lesson six:  Don’t push your agenda.  Now that you’ve made the change, there has to be some lull for people to work through it.

Bob introduces Joe at the meeting.  I’m working from home so I call in.  Immediately irritated, I put the phone on mute and open up CNN.com.  Instant detachment.  I’m only half listening, but enough to get more frustrated.  Bob asks Joe for his vision.  Joe starts in on how wonderful it is that Bob is leaving and taking his responsibilities to the new team.  Lesson seven:  Joe’s vision!?!?  This is not the time for Joe’s vision.  You’ve already introduced one change.  How about another?  Don’t add insult to injury.  Lesson 7b:  Guess what, I’m still concerned about what’s in it for me, and don’t care about what’s in it for the company.  Joe’s vision is pretty irrelevant to me.

Bob attempts to praise a couple of us about past accomplishments and how that might lead to new roles.  Lesson seven continued:  Still talking about more change.  I’ve had enough change for one day.

I stop listening and start actively reading news stories on CNN.  Good thing I’m on the phone.  Lesson eight: don’t give people change news over the phone if you can at all avoid it.  You’re not seeing my body language so you can’t react to it.

The meeting ends.  I open up careerbuilder.com to see what else is out there.  I don’t really want a new job, but bad change management does that to people.

The point is this.  If you’re doing process work you’re going to have lots of situations like this where you are the bearer of bad news.  In my case, it was my boss leaving, but you might be changing their job responsibilities or even just the way they get things done.  Get it right, and people will have ample time to internalize the change without it being forced upon them.  They’ll have time to go through the coping process and be ready to take on the change.

But, if you do it wrong, you’ll have employees opening up careerbuilder.com looking for a new opportunity.  For some people it’ll pass, but there’s a chance that someone you really wanted to keep on the team will find something and take it.  At least if that happens you’ll be on the receiving end of bad change management for a change.  Maybe you’ll learn from it.

If you’re going to ask for feedback…

So I did something today that I shouldn’t have done.  See, a peer of mine asked me to present on the project I’m working on.  I’ve given similar presentations a few times now, mostly to senior executives, so it’s a bit old hat for me.  Bored with the idea of rehashing yet the same presentation to my peers, I decided I’d come up with a new presentation.  One that covered a different topic than the usual. 

Typically the presentation is about what we’re working on and how it’s going.  Instead, I decided I’d give a presentation on the team organization and how it was working.  This isn’t your typical team at all, which would be a really boring presentation.  This team is a process design team, and they’re one of the first in the company.

But I digress, the point is, I made up a very brief, four slide presentation.  The first slide was ‘how does the process work?’, the second slide ‘what works well about it,’ the third slide ‘what doesn’t work,’ and the final slide is ‘what have I done about the things that don’t work.’

Anyway, I cobbled this together in an hour or so and then sent it off to the requester for inclusion in the larger slide deck.  Foolishly, I put in the email message “feedback welcome” or something like that.  I really was just being polite.  But, of course, the recipient of my email took it as a real invitation and sent me feedback.  Minor stuff, really, but since I had no expectations of having to make edits my initial reaction was to ignore him.  In fact, I was kind of irritated that he nit picked at my work!  I mean really, what is the point of telling me that “starbursts look better than rectangles” for the little overlays I did?  Honestly!

And fortunately, that’s when my better judgement kicked in.  Now, in this case, if I had just ignored him, there probably would have been few ill effects.  But, generally speaking, it’s a change management disaster to ask someone what they think and then ignore them.  People want to be heard, and in fact, a powerful change management tool is to do just that.  And the best way for them to know that they’ve been heard is to incorporate their feedback into your work.

Guess what, most people really don’t have a lot more than nitpicks, at least until you start ignoring them.  Then they get mad and nitpicks turn into finding major issues with your work.  You really, really don’t want to get to that stage.

How do I know?  I’ve done it to people.  They’ll be giving a presentation for review and I’ll suggest some minor wording change on the first couple slides because I think it’ll read better and the presenter will say something like “I like it as is.”  Suddenly I’m finding myself very annoyed.  I’m not being listened to!  So when they finally get to the meat of their presentation, then I rail on them about the quality of their data, their lack of hypothesis testing, lack of measurement system analysis, and so on.  I will rip the rest of the presentation apart.  And I won’t stop there.  I will get my hands on their data, and I will run my own tests on it and I will publicly present my findings.  Oh yes, I’ve done it.  And then how will you feel having to explain my conflicting (but correct) assertions about your data?  And you could’ve just changed the few words on the first slide, now couldn’t you?

Hey, at least I’m self-aware enough to recognize my behavior and admit to it.  Most people aren’t and that means you ignore them at your own peril.  Frankly, even ignoring people who are aware of their frustration is a bad idea.  Asking for feedback is good, except if you don’t act on it.  Then it’d be better if you hadn’t asked at all.  Nobody likes to be ignored.