How often?

How often do you make changes to your code, reports, or databases?

It’s likely a daily activity. A SQL update here. A visualization adjustment here. A new index on a table there.

This is the work of a data team. Daily building, updating, and refining.

———

How do you make a change?

How could you undo a change?

What’s your process for making a change?

How do your teammates make changes?

How do you know who made the change?

What if the change isn’t the right change?

What if the change breaks something else?

How do you know if your change breaks something else?

Who knows about the change you made?

Who cares about the change you made?

Do you know what changes you made last month or last year?

How were the changes you made tested?

What if you and your teammate want to make contradictory changes?

What if you don’t know that your teammate is making a contradictory change?

———

For something as central to our daily work as “changes”, we spend very little time talking about these questions.

Most data teams I talk with spend little time building frameworks and processes for doing changes well.

But if quality, consistency, speed, and scalability are a priority for your data team, it’s time to start asking these questions.

And taking steps to answer them.

I’m here,

Sawyer

from The Data Shop​

p.s. hit reply and tell me about your process for “changes”.