One More Reason Change is Hard

A great portion of my career has involved working with rapidly changing groups. As a consultant, I'm typically brought in to work with some specific area that is undergoing great change. As an employee, I am often part of a massive hiring initiative to grow or split a company.

Many of us who do this type of work speak and write often about the details about how hard change really is. It's stressful for the people going through it, some people won't make it to the end of the process, and many more reasons.

Today, though, I want to specifically talk about the fact that it's challenging to know what has changed and what hasn't. Sometimes, the "tribal knowledge" you might depend on has gaps.

When Tribal Knowledge Fails

One day in the past few years, I was assigned to a new project. That project was taking place in the middle of extraordinary change in the company it was in. It was designated as something the labs needed and we had to move forward and make it work.

As part of the project plan, the project team began to include a company policy that required specific and detailed oversight, and tasks that didn't seem to fit with the type of project.

One project team member came to me and asked why we were including this policy. He suggested this policy didn't apply and would basically kill this project, a project not meant to use this policy. Let me add that this was a person I knew to be diligent and knowledgeable. I took their pushback seriously. Yet, when I pushed back on him to question why this policy was in place yet he was asking why we had to follow it, he could not put his finger on why we didn't need to include it. He just "knew." He had convinced me but I had no reason to call out an exception to the policy.

As such, I went on a small networking campaign to talk about our project with a variety of groups and leaders. In each case, I brought up the new project and mentioned we would be following that company policy, in each case looking to see that the person I was speaking to gravely nodded to indicate this seemed the right thing to say to them. But I soon started asking the purpose of the policy, how long it had been around, and whether it really made sense. I asked if we could request an exception.

This caused great concern and many responses of, "Yes, that's our policy, Gloria, you must ensure we follow it. That's your job, by the way!!! NO, YOU CAN'T HAVE AN EXCEPTION!!!!!" And, indeed, it is part of my job to ensure we were following policies.

One Day Not Far Into the Future

At one point, I had come almost to the conclusion of this exercise. The project was about to begin and I had almost exhausted the list of people I should speak with. I had been doing my due diligence on this issue when something new happened.

I spoke to the final person, another person who had a great deal of policy knowledge. I had the same conversation with him. Lo and behold, his eyes widened, he stopped for a minute, and he said this to me. "Yes, that's our policy. Yes, we have to follow it." But he then continued with this, "But here is why that policy doesn't and never would apply to the project you're speaking about."

An Entirely Different Example

It might seem like I'm changing the subject but this is related and I will tie these together in the next section.

Years ago, I had a customer who had a multitude of spreadsheets they wanted me to turn into a LIMS feature. In collating all their spreadsheets, I made a detailed proposal to the team including a prototype demo. During that demo, I discovered that one of their fields was changing in use due to a change in their product lines. The spreadsheets didn't show this because they hadn't yet been in the new situation, but the field would have significantly different features in the future of it's use.

Something Similar Happened In Both Cases

In the case of the policy, here is what happened: The people in that group had so many projects that were exactly the same while they were onboarding new people that the new people thought the policy was meant to be used on every project. The tribal knowledge was continuously passed along in a single way because that was the situation that was common.

The new people were so convinced the policy was meant to be used in every situation that some of the people who had been around from before the influx of people even now thought that the rules had changed on that policy to now be used in EVERY case. It turned out that the policy was not what changed but the "tribal knowledge" around it had begun to change.

In the case of the spreadsheets, no-one realized what the one field change would look like to someone analyzing it. Even though it came from a change in their product line, a significant change, they saw it on their spreadsheet as "just another field." They did not think to mention the change to me. It was a good thing we did our due diligence of a general demo before I spent lots of their money developing something that wasn't going to work for them.

I should stress that that one field change had a significant impact on some of the other features being proposed.

Back to the Changes

So, here we have two places where there is ongoing change. In these two very different examples, we can say there was no harm done because there was someone to question this. It all worked-out. In fact, there are those who would say it wouldn't have been the end of the world if no-one had noticed.

In the case of the software change, I know that particular customer's habits well-enough to say that they probably would have agreed it was their mistake not to mention this and would have agreed to pay me a stack of extra money to fix it. Some skeptics will say it would have worked out BETTER to have missed it because the customer would have learned a lesson AND I would have made more money. I'm not quite that skeptical, by the way...

But where we go back to the policy issue, the initial person pushing back was correct that this policy would have harmed the project. I agree that the project would have failed. In addition, I feel certain that there would not have been more time nor money given to the project. The business users would not have received something they had justified to be a priority to them. They would have lost out.

What To Do?

How did I know to keep questioning the policy? How did I know to insist on a mini-demo of the features and fields of the software I was about to develop?

The answer to those questions is this: Experience. I have been doing this long-enough to remain skeptical. In addition, I can occasionally get someone I respect to weigh-in on what I'm doing just to see if they can poke some holes in it, too.

Now, how you can go about this is another issue to consider. Who do you ask and what questions do you pose to them? Think strategically about this.

Here is what I mean: I am known for having something of a lack of boundaries. If I have to jump a few levels to ask someone truly high-up in the company, I'll do it. But I do not do this, casually. I am looking for information and to disrupt when necessary but I am not there to burn bridges.

To put this in a slightly different way, I know that I am present on this type of work in order to get information but I am not present in a situation to aggravate people to the extent that they stop speaking to me or others I am working with, either. There is a difference in being a disruptor and in causing significant harm.

For you reading this, you will get experience in doing this by doing it. You can read books on it, take classes on it, but at a certain point, you have to start doing it.

When you come up with your plan on how to go about this, you will not know the outcome, even if you suspect what it will be. Going back to the beginning, the point is that you're in the middle of change. Whatever you start might change when you're in the middle of your plan and suddenly you realize you have to pivot.