Lessons Learnt Implementing Process Change
In my blog 10 step recipe for implementing process change I had written that implementing a process change was one of the toughest things I had to do in my career so far. It was tough because it included building a tool to aid with the process, I had to play multiple roles, justify the business need, build consensus amongst several teams, and in the process of building consensus I let the scope creep way beyond what I had originally planned. I got a lot of push back and at the same time got a lot of help. Here are some valuable lessons I learnt along the way:
Lesson 1: You cannot rush through building consensus
I had to get alignment from several teams and in order to expedite building consensus on the proposal, I scheduled one meeting per team for 30 minutes, with all the managers in those teams (~10 to ~15 people where I was at the bottom of the totem pole). This was a bad idea. 30 minutes is not enough to present a proposal with the aim of getting buy-in. I should have asked for representatives for each of the teams, got their buy-in before trying to get consensus from the larger group.
For one of the teams, I got alignment from the Senior Management but did not discuss the proposal with anyone else on that team. When I presented it to the whole team, the team did not buy-in even though I had alignment from Management. If you don’t want to impose a process but want to implement by gaining consensus you have to align with Senior Management on the high level principles of the process change and get consensus from bottom up.
These are the reasons why I suggested that the second step in the 10 step recipe is to form both a core working group and an extended working group with representatives from each of the impacted teams. Once you have buy-in from the extended working group, leverage their help to get consensus from the rest of their team. Since they are part of the process creation, they will be supportive and will evangelize the process with their teams. You don’t have to do it all by yourself.
What would I do differently next time?
Form a core working group and an extended working group. Align on the high level principles with the management and build consensus from bottom up.
Lesson 2: You cannot control the outcome of meetings
Couple of the meetings where I was supposed to get buy-in, went completely south. In one meeting, I could hardly go through a couple of slides when I had ~10 slides to cover. Because of the time pressure that I cannot implement the process without their buy-in I was not reading the sentiment of the room and was trying to push my agenda through.
I was very upset that those meetings did not go well and shared with a confidante. He advised that I should not judge whether a meeting went well or not well and that I cannot control the outcome of the meetings. It is our duty to be well prepared, present it to the audience. Then have the presence of mind to read the audience and steer the meeting accordingly. I never thought about meetings this way.
Having the presence of mind to read a room and steering the meeting accordingly is a very valuable skill to have.
What would I do differently next time?
Actively listen to the audience and not let time pressure dictate how I handle meetings.
Lesson 3: Know when to push back and when to back off
I got a lot of feature requests for the tool that we were building as part of the process rollout. While it was great to see that there was a lot of interest, it was a huge scope creep. What started out as a simple tool to aid with the process, took shape of a full-on product. I started saying yes to all the feature requests with the intention of getting buy-in and a few of my colleagues helped me realize that there was a lot of scope creep and that I should push back. I took a step back, got buy-in for a minimal viable product (MVP) for the initial process rollout.
Once I had agreement on the MVP, and everything was all set to rollout, one of the key stakeholders proposed a couple of must-have features. I lost valuable time pushing back on it multiple times, that I could have instead spent on figuring out what needed to be done to make it happen. Lesson learnt here is that if you have already made your point then you should back off instead of continuing to make the same point over and over again.
Knowing when to push back and when to back off is a very important skill. Lots of factors come into play. It would be worthwhile discussing with your manager, colleague or mentor for guidance in such situations. Here is an article that provides some good guidance on this.
What would I do differently next time?
Evaluate the rationale for a particular feature request, how they align with overall objectives and determine whether to push back or back off.
Lesson 4: Use existing tools/processes as much as possible
There was an existing tool and a process for the problem I was trying to solve however, it had some shortcomings. Because of that, I proposed a different tool and a process. This worked fine for pilot but when I tried to scale the pilot to all the teams it was not feasible and I ended up with a tool and a process very similar to the existing one but with several changes. When I was rolling it out to wider teams several of them asked me about why we are not using the existing tool/process? Because the final tool and process is based on the existing one, I was able to respond to that question that it is based on the existing process. That helped a lot with gaining consensus. It is much easier to convince team members to use an existing tool and process with changes, rather than inventing a new one. It reduces time to get consensus and also reduces time to train the teams.
What would I do differently next time?
With the help of core and the extended working groups, evaluate existing tools/processes and make changes to those if possible instead of re-inventing the wheel.
Lesson 5: Apply product mindset for a process
It did not occur to me until very late that if I were to treat process as a type of product, it would have reduced some of the churn I experienced in the design. I would have created a process vision; prioritized backlog of process changes; identified the priority of the teams that we need to roll out the process to; would have defined Minimum Viable Process etc.
What would I do differently next time?
Think of process implementation as a type of product and create some of the artifacts we would create for a product.
Lesson 6: People change their stance. Don’t hold it against them.
Some people behave differently when they are in front of their managers. They might be aligned with you when you talk to them one on one but will change their stance if their manager disagrees. Similarly even if a manager is aligned with you on the proposal but senses that his/her team is not for it, they will not be supportive of the proposal. This means that the manager is looking out for the team. And some people might agree with you privately but will oppose you in a group setting.
I have encountered such scenarios during this process and in retrospect I don’t think I handled some of these situations well. It is not that I never encountered this before. It is just that several of these things happened in succession and so it made a strong impression in my mind.
How other people behave is not something anyone else can control. What we can control is how we choose to handle such situations.
What would I do differently next time?
Anticipate that people will change their stance and be prepared to handle such situations gracefully.
In summary
- You cannot rush through building consensus
- You cannot control the outcome of meetings
- Know when to push back and when to back off
- Use existing tools/processes as much as possible
- Apply product mindset for a process
- People change their stance. Don’t hold it against them.
“Learn from the mistakes of others. You can’t live long enough to make them all yourself.” ― Eleanor Roosevelt
I wrote this blog so that you can learn from my mistakes 🙂 Hope you would find these lessons helpful!
Thanks to all my supportive colleagues that helped me through this journey. You know who you are 🙂
