Happy People Know What's Going On

TLDR;

Change is disruptive, even a minor change. You should minimize that disruption while maximizing its beneficial impact. Optimize for accomplishing the goal instead of throwing out a list of steps.

• Be thoughtful about organizational changes and implement change intentionally
• Get buy-in from the individuals affected by the changes you are introducing
• Introduce change at a rate that will be minimally impactful and maximally effective.
• Measure Change in reference to the goals for that change.
• Revisit the change as necessary to accomplish its goals.

You Are Missing an Opportunity

You need to implement changes intentionally. The ADKAR Model is a well thought out approach to change management. If your organization has the culture and maturity to follow a process like that, you should. The process doesn't have to be complicated. For most organizations, a minimal process is more likely to be followed than a more heavyweight process, and a process you follow is better than one you don't.

The most minimal and pragmatic approach that has been effective for me is this one.

1. Define the proposed change
2. Find metrics that you will use to gauge success
3. Write down the proposed change and metrics
4. Socialize and get feedback on the document
5. Set a date for implementation
6. Schedule retrospectives on the change
7. Schedule a kickoff meeting
8. Roll out the change on the date specified

In some cases, you may not be able to ask for feedback on the Change. That may be due to sensitive issues around people management or other privacy concerns. Where that occurs, cut the process down as follows.

1. Write down the change and metrics
2. Set a date for implementation
3. Roll out the Change on the date specified

In this case, all of these steps may happen at the same hour. The key is that you wrote it down and shared it with the team. They have something they can read and use as a reference.

Define the Proposed Change

Often, you have an epiphany about something in your organization. In the course of a few seconds or a few minutes, your idea becomes fully formed. That may be the right change to make, but it probably isn't. In your mind, back off from the change and think about the goal you expect that change to effect. Think through other ways to accomplish that same goal. Think through which lever you will use to achieve your goal. Is that the best lever? Is there a longer lever that you can use? In effect, be intentional about your change.

Find Metrics That You Will Use to Gauge Success

Change isn't useful if it doesn't accomplish a goal. We often define a change, and the result we expect is that things will get 'better' without understanding what 'better' means. 'Better' is too ambiguous. We can't measure 'better.' Be specific about the goal. If you expect a change to reduce the time the team spends waiting on other groups, then 'wait time' is your metric. If you expect a change to affect your team's ability to deliver software consistently, then velocity or the standard deviation in delivery days might be your metric. Defining a metric allows you to hold yourself accountable. It enables you to refine the change over time. It also forces you to be concrete about what you want out of the change. Too often, we let ourselves slide on that.

Write Down the Proposed Change and Metrics

Use writing as a tool to force you to think through things. Writing is a forcing function that helps you articulate Change in a way that is understandable to the people affected by the change you are proposing. It also gives you a way to iterate on the message before you communicate it more broadly. A document is also the best tool available to communicate Change in an organization.

The document should be short, around one page for the body of the work. Otherwise, people are probably not going to read it. Add appendices as needed. The document should define what the change is,  why the change is required, how you will implement it, and the metrics you will use to measure it. Remember that your audience probably does not have the same knowledge you do. Metrics provide a shared organizational vocabulary for understanding what's going on in the organization.

Socialize and Get Feedback on the Document

If you want a team of effective, empowered people with a strong sense of ownership, they need to be part of the Change. Change needs to be something that they are deciding to do, rather than something you do to them. One of the ways you can accomplish that is to include them in defining the change. If the team is large, have the primary non-management leaders on the team involved.

This editing process is an opportunity to leverage smart people to improve the document. It also serves as a pre-pitch to the team, allowing them to see the document and while you iterate on it and further aligns them with your goal. Involving people improves their sense of ownership and helps prevent or mitigate any feeling of having the change imposed on them.

Be pragmatic about sharing the document. Do it when it makes sense. That said, you should be transparent unless there is a good reason not to be.

Set a Date for Implementation

A significant change that comes out of the blue is much more disruptive than a significant change that the team has a chance to think through and digest. When you make changes, give a date for when the change takes effect and publish it ahead of time.

Schedule Retrospectives on the Change

When you schedule the roll-out of the Change, also plan the first set of retrospective meetings. Those retrospective meetings are the organization's opportunity to gauge progress via metrics, tweak things, and improve the process. They need to happen regularly until the Change is cemented in the organization and working well.

Be as intentional about changes to the process as you are about the original Change. Update the process doc with the changes, highlight those changes, assure everyone knows about the new changes, why they are essential, and what you expect to accomplish.

Schedule a Kickoff Meeting

Schedule a meeting to introduce the change, invite everyone affected by the Change. Include the document in the invite. Talk through the change during the session, encourage people to ask questions. Don't be afraid of those questions. Your back and forth with the thought leaders while editing the document will have prepared you well. If you get items that you can't answer, say that, write it down and follow up later. If someone highlights a potential challenge that you haven't thought of, let them know that you still need to figure that out and that during implementation, they will be crucial in solving that problem. The venue for those discussions will be the retrospective meetings.

If it is unlikely that people will read the document ahead of time, you can take the first ten or fifteen minutes of the meeting and have people read it. While it may not be a cultural norm for your company, it's a practical approach to creating a shared context around the change.

The kickoff meeting is another opportunity to include the affected people and bring them into the fold. Make them champions of the change as much as you are.

Roll Out Change on the Date Specified

On the morning of roll-out day, send out another email or schedule a small meeting. Remind everyone of what you are doing and why. Include the document again.

Summary

When managing change, stay focused on your overarching goal: to reduce the amount of time your organization spends in a period of reduced productivity due to that Change. Do this by actively managing perceptions of that change. Involve others in this process. Mitigate the disruption of the Change by diligently scheduling a kickoff meeting, roll-out date, and a retrospective. Always win over individuals by finding ways to make them champions of the Change, rather than its subjects. Wherever possible, use data in your rationale for Change and provide means for measuring the effectiveness of Change.