Skip to content

Change Management#

How we deal with changes and communicate accordingly

Problem#

A couple of people discuss a topic, they decide to change something, and implement it straight away. They may mention it to a couple of people, or test it, but not everyone who needs to know, is informed. A lot of the time, no one really knows who needs to be informed - or whether the change they have made will even impact anyone else.

When a change is not communicated widely enough, someone may lose hours in a day trying to fix something or find something that no longer exists. With our global spread, it may also mean that those who made the change may be offline already for the day, and the answer may only come when the sun comes back up in their respective time zone.

Additionally we would like to have every process, policy or any other specification documented, but we are still far away from having this done. When something changes, it is the perfect time to document it! Either in the Internal Handbook or the Public Handbook (if you are not sure where it goes, use the Internal Handbook. Better documented internally than not at all!). This gives existing employees the knowledge of what has changed and new employees the possibility to know what is in place.

Solution (Utopian)#

Every change made everywhere is first documented and then communicated to everyone, so that all know what’s where. _(Creating a lot of noise for a lot of people who don’t need to know everything in detail).

Solution (Current)#

There is Slack Channel called #team-changes , which everyone is added to.

Each time a significant change is made to something, a comment is added to the channel. With a link to the relevant documentation that describes it. While it is also possible for a change to not have documentation, it is really discouraged, as anything that could be changed should also be documented. Please use the time to document it properly - you will thank your future self.

The main comment should contain enough such that the change is searchable.

Hint

The purpose of the channel, is

a) to broadcast messages to those paying attention, and

b) be a resource for anyone looking for help when they come across something broken or lost.

  • It should not be a call to action, but a statement of change
  • If we think the change comment is relevant to somebody specific, then "cc" them on the change for higher visibility.
  • It would be super useful, if team members can react to the message with a thumbs up emoji 👍, if they found that the change communication was useful to them. This reinforces the value in having communicated the change, which should encourage this to become a habit.

Is this a change which should be communicated?

If you answer yes to any of these statements, then it should be documented and communicated:

  • A change occurred in our documentation that goes beyond a typo or restructuring of content
  • We did a thing that involved people from more than one workstream
  • We did a thing that we know will affect at least one other workstream
  • I discovered a change* that impacted me, which was not yet documented and/or communicated
  • It involved a change to an access (e.g in Okta or LastPass)
  • It involved a possible URL change
  • It involved a possible system/tooling change
  • It involved a process change
  • We added something
  • We removed something
  • New people were included in a thing - or excluded

Note the point on discovering a change - it should be important that if someone discovers a change, that they felt was of interest to them or might have an impact on them, then it is worth communicating. There should be no hard feelings or stigma attached to doing so, and no guilt felt on the parties that made the change without a communication - we don’t always know what is important to others to know. It might be, that the change discovered is still being finalized and was intended to be communicated - in which case, the person/people involved, should just pop a short message to that effect and update once the documentation is ready.

In general,

  • No hard feelings

  • Rather too much than too little

  • Make it searchable

Future#

As we are moving more and more into documenting everything via our two Handbooks (Internal and Public) we can leverage Gitlab Webhooks and Merge Requests to communicate changes. Our vision is that every change is proposed as a Merge Request to the Handbook, discussed, approved and then merged. Merging will automatically create a message in the Change Slack Channel where people can find short description to what has changed and a link to the Merge Request. Inside Merge Request people can then find the discussion and reasoning for the change, this is even better than just a change log as it tells people not only what has changed, but also why.

As this Handbook process will take some time (check out the IC Handbook) this will all be implemented at a later stage and we are doing Changelog messages manually for now.

Change management is an ever-evolving topic, that will develop over time. If you have any suggestions on how change can be better communicated, please add a comment to this page, or contact BizOps.