Discover more from Data Operations
How to Build a RevOps Change Log
What would happen if every department had only one place to look for changes?
A familiar story, started in Tweet
As a RevOps professional, how many times have you seen a field in a sales or marketing system and wondered:
what is that and who made it? Why is it there? And more importantly, if I got rid of it, what other systems would it break?
The conversation goes kind of like this when you talk to other people about it:
What is that field? You must know.
The core of the problem is that no one took the time to document what the field does, why it’s important, and who owns it. That person might no longer be at the company, or they might have just created the field to fill a near-term need. You don’t know, you just need to find out what’s going on with the field in your sales system.
At this point you have a few choices:
Interview enough people until you get the answer
Dive into the system and document everything that’s there
Wonder if this is the last question you’ll have about this system and how it connects to the other pieces of your Revenue Operations world
None of these choices are particularly great. Interviewing people until you get the answer might work once, but isn’t really scalable. You might not have time at this moment to document the whole system. And this definitely won’t be the last time you need to know what a field does in a RevOps system.
What do you usually do? Get the answer through any means necessary and move on. Until you hit this problem again.
How do you solve this problem?
You can keep having circular arguments or working in the dark when you make changes, or you can build a system to document cross-system and in-system changes, or a Change Log To Rule Them All.
Before you worry about the challenges of creating an all powerful change management system, consider where you are today. You are probably documenting some things and not others, and not always writing down when changes happen. When other people make changes, you find out when things break and maybe not before.
The net effect is that you have a low bar today. Doing almost anything will be better than the base state, and will save you time and effort every time you reference this resource in the future.
Why is it important to have a change log?
Understanding a system landscape - especially in a Revenue Ops organization where you need to know the impact of change - is a precursor to being able to approve changes and find early indicators of problems. Organizations that are better and faster at implementing change are better at incremental improvement everywhere.
Change logs are the manifestation of the work we do. If we don’t write things down, the water cooler (or Virtual Zoom) conversation is the only chance to find out things have changed until they break.
What the heck is a change log, anyway?
A change log is a record of the things that changed. It’s a template that you follow to let someone else know what happened in the past. The basic idea is to have a single point of reference for all changes that happen in a system so that you can read through a history of changes and see what changed since the system was started.
You might even consider having “releases”, or groups of changes that launch around the same time and are themed with a “version” or “label” to indicate a particular body of work. But really what we’re talking about are the smaller changes that happen more frequently, like adding a value to a picklist, adding a field to a system, or changing a basic configuration for a user.
One way to do this is to become ITSM certified and learn everything there is to know about Information Technology Service Management. If you’re not an IT professional, you might not want to go that route because all you want to do is record a change that you made to a system, identify the scope of the change, indicate whether it impacts another system, and note when that change will next be reviewed. So just write down then.
One way to do this is to post to a shared Slack channel every time you make a change to an operational system, e.g.
An example of a change might be:
This gives you a date stamp for the change, a change originator, what changed, and where that change happened. Which is great! Except when the person who makes the change forgets to post to the shared Slack channel, changelog text file, or whatever other artifact you use to identify a change.
If no one follows this process, what’s the big deal?
Process is great until it’s no longer automatic. If you are the type of person who follows a process even when there are no guardrails, then huzzah! If you are the rest of us, who would follow a process almost all the time if it were easy to comply, the idea of someone automatically tracking changes sounds pretty great.
And if it doesn’t, consider the last time you had to determine when a change was made. It might have looked a little like this:
What do we want in a Change Log?
We want a change log that makes it really easy to create change log entries. We also want the systems that we use to produce these entries, so that they are reviewed by humans who manage the combined systems. And we’d also like it if the change log actively warned us about changes that might cause problems.
(courtesy of https://unsplash.com/photos/l3r5Et4YhIs)
Why is building a change log hard today?
Building a change log in Revenue Operations is hard today for a few different reasons:
People forget to (or don’t want to) log their changes
Vendors would prefer that you log into their system to see the changes in that system
Vendors don’t track changes and haven’t built that feature yet
The person making the changes doesn’t have the full scope of the impact of that change when it touches other systems.
Let’s unpack each one of these objections to get a better idea of the problem.
Here’s a summary of each one, describing both the reason and the positive and negative outcomes.
If you centralize change making, then the person reading the change log or making the change may have a full view of what’s going on. As the team grows or as new systems are added, it’s less likely that any one person has the full picture of the importance of a change. Small organizations don’t have this problem. It’s just one person making all the changes. As organizations grow, this problem becomes more acute.
What would a perfect change log look like?
Change logs are not great today. If we were to imagine (or re-imagine) a change log that worked across products and was more visible to the whole organization, what would it look like?
It might share these principles:
Logging a change always happens, consistently and with a standard template
Change logging is visible to other systems and broadcasts a change to any subscribers who want to listen
There is a history of past changes to demonstrate how we got here
Changes are owned by a particular person and you can view a person’s changes across systems
Changes are rated in terms of the systems they affect - if a system is not connected to any others, it should be a lower impact change than a system connected to multiple other systems.
Changes that affect multiple systems require approval by stakeholders of that system
A report can be derived of the changes that happened between one date and another date, including labels to indicate important changes in the business that happened at that time
This change log is consumable by a standard log format and is output in a .csv format
That sounds like a better world.
What can we do today until better things emerge?
We’re not in a better change log world yet. So what can do today that represents incremental improvement?
Here are a few ideas:
Commit to posting to a shared slack channel every time you make a change to an operational system; periodically, archive the information from Slack (perhaps with a bot) so you have a time stamped record that exists outside of a system.
Use JIRA or a similar bug tracking system to log operational changes and align with the owner of that change, indicating the change, the impact, and the date.
In Salesforce, use the Change Data Capture API to broadcast changes to another system that catches those changes
Catch all of the changes from all systems using a webhook and write to a common log format
In a team, use the team meeting/ sprint planning / retro to review the log and catch some of the changes that have not been logged (h/t @copypastaa); document in wiki or Confluence
It’s a low bar if you’re not doing anything today. Start by starting.
How are you solving this problem?
Change logs, like other systems, are representative of the people, process, and tools that manage that system. This quote by Jason Fried sums it up well. Make the systems better, and productivity will be easier to find.
If this post sounded good to you, please share it …
If you like writing like this, consider subscribing …