Change management checklist

The change management checklist outlines the steps that folks on the team are required to work through in conceiving, proposing and implementing a change. These steps have been grouped into three distinct stages to align with Sourcegraph’s decision making framework and our use of RFCs to frame problems and propose solutions.

  • Thinking about the idea (Pre-RFC)
  • Aligning with those affected (RFC)
  • Following through (Post-RFC)

Thinking about the idea (Pre-RFC)

  • What problem does it solve?
    • Frame the problem that needs to be solved before trying to brainstorm a solution.
    • Identify if/why the problem needs to be solved now. This helps us determine whether the time, effort and resources required are justified by the benefit of implementing the change or the cost of not doing so.
  • Is this currently covered by our OKRs?
    • If yes, pause and allow ongoing projects/initiatives to run their course first so as to avoid duplication of effort and confusion within the team.
    • If no, prioritize when to start against work already in-progress (to honor our work to constrain how much we have in-progress/try to do at once).
  • Is this something that everyone else feels like we need?
    • Validate that the problem to be solved is one that impacts the team versus one that affects a single individual.
      • For leaders, this means aligning with the rest of CS leadership on the idea before facilitating a convo with the rest of the team.
      • For ICs, this means validating with a few peers (or your manager if you find this helpful) then facilitating a wider convo.
  • Who is impacted by this change?
    • Identify who would be impacted by this change both within CS and across the organization.
    • Identify who needs to be involved and in what capacity. This includes everyone on the team, others within prod/eng, and anyone cross-functionally.
    • Seek consent for the capacity you identified someone for – not everyone may have time/desire to participate, so ask first.
  • For leaders, will those impacted benefit more from us working privately at first and eventually publicly or publicly all the way through?

Aligning with those affected (RFC)

  • How much (if any) impact this change would have on current operations?
    • Proposal should clearly communicate:
    • How change would impact current operations
    • Why it is necessary
    • Measures to mitigate impact and manage transition
  • Is this a change that just needs to be communicated or one that requires enablement/coaching?
    • Think through “roll out” – How do we want those impacted to become aware? What about those who just need to be aware, but are not impacted? Is a Slack post enough? Is a live meeting, discussion, enablement, etc beneficial?
  • Are you prepared to receive input from others?
    • Acknowledge input from others and recognize feedback as a gift. Do your best to address concerns raised and appreciate other perspectives that may be different from yours.
    • Ultimately, you get to make the call. Decide on the best way forward based on the information at your disposal and explain the rationale behind the course of action that you have chosen to others as clearly as possible.

Following through (Post-RFC)

  • Does everyone understand what action needs to be taken, by who and when?
    • Create an implementation plan that clearly specifies responsible parties, assigned tasks and delivery timelines.
    • Everytime something is ready for someone to take action, make the request clear and to who and why (for example, @mention folks who have action vs those who can see it but don’t; this may require asking another team who would be folks to review)
    • Everytime there is a need to communicate to a new person/group, communicate contextually (you will always be many steps ahead so give others the story) – start with why, be succinct and to the point, then include all the context for whomever needs it to understand/process.
  • Is there a plan to measure success and reinforce the change?
    • Put a system in place to track change adoption. This could be check-ins, surveys, routine observation or reports.
    • Change is hard so put a plan in place to regularly remind folks of things until the new solution/practice sticks.
    • Schedule a team retro to keep track of how things are going and collect feedback for possible future iterations.
    • Find ways to publicly celebrate successes (even small ones) during implementation. This could be milestone announcements in the #customer-support-internal channel (for changes within CS) or callouts for individuals in the #thanks channel (for changes with wider impact).
    • To close the loop, do a self-retro of the change to determine that the problem as originally identified/framed has been solved.