Your data stack in a crisis: what to cut, what to hold
When teams shrink and projects freeze, you still need data. How to prioritise your data infrastructure during an unstable period.
In spring 2020, many companies went through the same sequence at once. Projects frozen, teams shifted to remote or cut down, budgets revised downward. And at the same time the need for information - for real numbers, for a clear picture of what is happening - grew sharply.
This creates an odd contradiction. Fewer resources, but more decisions needed, faster. In that situation data work does not become less important - it becomes more important, but what changes is how you need to approach it.
I saw several companies make decisions during this period that ended up costing them more than the savings they were chasing. Here is what I took from that.
What happens to data during a crisis
The first reaction is usually ad-hoc exports. Leadership wants a daily picture, analysts build new tables, dashboards get rewritten for new metrics. At the same time, some of the people who "knew how to count correctly" leave or shift to other things.
The result: after three months the company has accumulated a layer of situational analytics - files that were "temporary", queries nobody documented, metrics that everyone understands differently.
This is not a disaster. But it is debt that will have to be paid later.
What you cannot stop
There are a few things that should not be touched during instability, even when the pressure to cut is strong.
Continuous data collection. If you stop collecting now, you will have no baseline to analyse when things stabilise. A gap of several months is a gap forever. Storage is cheaper than reconstruction.
Critical system integrations. If sales data does not flow into the finance system automatically, that is not just inconvenience. It is manual work that scales with transaction volume.
Access rights and audit logs. In a crisis, people change roles, contractors get temporary access, everything moves fast. Six months later nobody remembers who was given access or why. That becomes a security problem.
What can be deferred
If something has to slow down, slow down development, not maintenance.
New dashboards, new data sources, nicer visualisations, ML experiments - all of this can wait. Supporting what already runs and what operational decisions depend on - it cannot.
A useful rule: ask what would happen if this stopped working tomorrow. If the answer is "nothing critical" - it can be deferred. If the answer is "we would have to count by hand" - do not touch it.
How to document what gets built on the fly
In a crisis there is no time for proper documentation. That is fine. But there is a minimum worth keeping.
Every new query or export that gets used regularly - at least one sentence: where the data comes from, who asked for it, what is being measured. Two minutes now saves hours later when someone else inherits it.
Three questions for right now
If you are managing a team or a data project during an unstable period:
- What data is being collected continuously, and who is making sure it does not disappear?
- Which decisions are actually being made on the basis of data - and could we make them without loss tomorrow?
- What was built "temporarily" in the last three months and has already become permanent?
The last question is usually the most uncomfortable.