Great article! A few points that I would highlight.
First, I am glad you mentioned "measuring the change". It took me a while to learn how to leverage the use of measuring a baseline and showing how the change impacted the baseline over time. I find that bringing the data into the conversation helps to give us a visual understanding of the impact of the change, rather than just "feeling like it was resolved". It also helps get buy-in from the teammates that maybe more entrenched in the "way we always do it" or those that are more data-driven.
Second point, is around ownership, which is key to the success of any change. I think we can all agree that no one appreciates someone coming in and telling a team "how they will work best". As a Program Manager, I am often approaching a new engineering team as an outsider and I rely heavily on ensuring that the team owns their changes. My process involves gathering the issues from all stakeholders perspectives, then bringing the team together to review the issues and brainstorm a solution. Once the team has agreed on what they believe will fix the issue, we discuss it often, and revisit the issue as a set later date to see if the issue has been resolved. When the team owns the change, they are more engaged in resolving it and more likely to succeed in making a change stick.
Finally, when it comes to large organizational process changes. I think you can provide vision, great data, and proposed plans, but without engaged and attentive leadership, who are invested in the outcome, you are less likely to get multiple teams to make the leap. Often when it comes to performance, what leader wouldn't want to see improvement, but as you point out above, timing and buy-in must be there first.
I think you did a great job in breaking this important subject down and will be saving this article and applying some of your suggestions in the future.
Hi Emilio,
Great article! A few points that I would highlight.
First, I am glad you mentioned "measuring the change". It took me a while to learn how to leverage the use of measuring a baseline and showing how the change impacted the baseline over time. I find that bringing the data into the conversation helps to give us a visual understanding of the impact of the change, rather than just "feeling like it was resolved". It also helps get buy-in from the teammates that maybe more entrenched in the "way we always do it" or those that are more data-driven.
Second point, is around ownership, which is key to the success of any change. I think we can all agree that no one appreciates someone coming in and telling a team "how they will work best". As a Program Manager, I am often approaching a new engineering team as an outsider and I rely heavily on ensuring that the team owns their changes. My process involves gathering the issues from all stakeholders perspectives, then bringing the team together to review the issues and brainstorm a solution. Once the team has agreed on what they believe will fix the issue, we discuss it often, and revisit the issue as a set later date to see if the issue has been resolved. When the team owns the change, they are more engaged in resolving it and more likely to succeed in making a change stick.
Finally, when it comes to large organizational process changes. I think you can provide vision, great data, and proposed plans, but without engaged and attentive leadership, who are invested in the outcome, you are less likely to get multiple teams to make the leap. Often when it comes to performance, what leader wouldn't want to see improvement, but as you point out above, timing and buy-in must be there first.
I think you did a great job in breaking this important subject down and will be saving this article and applying some of your suggestions in the future.