Timing Matters in Managing Change

When I was a kid, there was a list going around that itemized twenty-five common life changes: loss of a job, death of a loved one, a new sibling, a move to a new home or school, and so on. Each change had points associated with it, varying from ten points for minor changes to 200 for the biggies. The scuttlebutt was that if the sum of the points for the changes you were coping with exceeded 300, you were over the edge. The edge of what, I didn't know. I just knew it sounded ominous.

That list, kid-oriented though it was, turns out to be strikingly relevant in the grownup world. Too many changes at one time can significantly increase the intensity and duration of the chaos people experience, resulting in more than they can handle and delaying their adjustment to any given change. It follows logically that how receptive people are to a given change depends at least in part on where they are in terms of their adjustment to other changes. Therefore, the timing of a change is worth considering.

For example, the transition to agile methods among people with strong emotional ties to their current methods may be more prolonged and turbulent if they are still reeling from the fallout from a messy merger, a major reorganization, or a massive layoff. In general, if you plan to introduce a new tool, begin a complex project, or undertake any other major initiative, and team members are still topsy-turvy from other recent changes, it may be wise to delay the planned change if you can. On the other hand, if team members have adjusted to recent changes or are well on the path towards adjusting, they may be able to tolerate-or even welcome-the next change.

Obviously, you don't always have a say about the timing. Some changes are dictated by business cycles, seasonal variations, regulatory mandates, or other factors (such as the current economy) over which you have no control. And, sometimes, the timing is driven by when the change must be completed, such as by the end of the fiscal year or in time for the peak selling season.

Of course, even when you can control the timing, you can't exactly defer all change efforts until the team or company has reached a state of serenity-especially these days, when upheaval is the norm. Obviously, work must go on. But by being sensitive to the matter of timing, you may be able to minimize the turbulence people experience, and that will be to your benefit as well as theirs.

A question that often comes up regarding timing is the wisdom of introducing several changes at one time if they are related. Might it not be better to cope with one bout of monumental chaos than to wait for the turbulence triggered by each new initiative to subside before tackling the next one? Indeed, it's sometimes better to work through one big episode of upheaval than several smaller episodes which, though less stressful, can lead to chaos fatigue.
Unfortunately, there's no set of timing criteria (or 300-point scale) that will positively determine which approach is best. You have to rely on your judgment, experience, and knowledge of the people who will be affected. However, involving the affected people where feasible-such as by giving them a say over when and how the changes will take place-can be an important contributor to the success of whichever approach you select. Involving them confers a sense of control at a time when they feel a loss of control and can accelerate the adjustment to the change.

A related timing issue concerns the optimal time to tell employees about a change they'll find distressing. Sometimes, of course, you're forced to sit on the information until you're given the go ahead from above to share it, such as when its premature disclosure could send customers straight to the competition. Too often, however, managers who know about a potentially upsetting change refrain from informing employees because they want to spare these employees any unnecessary pain-or at least that's what these managers tell themselves. Actually, many managers withhold bad news to spare themselves any unnecessary pain-in particular, the pain of dealing with employees' reactions.

In any case, withholding information about an upcoming change in the name of kindness usually backfires, because it amounts to treating adults like children. From the employees' perspective, such withholding is dishonest, thoughtless, and inconsiderate. And, a manager withholding bad news because he never thought that the information would matter to others (as I've encountered in a few companies) is an outrageous sign of disrespect.

Of course, it's natural to want to withhold bad news. But most people would prefer to hear bad news sooner rather than later if it will affect their ability to do their jobs properly, and this is as true of customers as the software professionals who serve them. More than a few customers I've interviewed while consulting to IT organizations have mentioned their frustration over not being kept informed about changes in IT's ability to deliver as agreed. As vociferously stated by one such customer, "IT needs to understand that we have responsibilities and accountabilities just as they do. We need to know what's happening so we can make adjustments at our end."

An interesting ethical aspect of this issue surfaced during my presentation on managing change at a recent software conference. One member of the audience questioned whether it's not only dishonest, but also unethical, for a manager to refrain from giving employees news that affects them and that she's free to disclose. In a lively exchange, audience members debated the issue. When I then polled the group, the majority felt that the ethical thing to do, almost always, is to disclose the information, even it means contending with the resulting reactions. This is certainly easier to agree with than to do in practice, but I like to think that managers will give this issue serious consideration when the situation arises.