# Stage 4: When People Push Back, Show Them

> **Summary:** The technology was not the hardest part. People were. How we got through pushback and red tape, by showing value in action, and how a crisis became our best argument.

- **Author:** Thabang Mashinini-Sekgoto
- **Published:** 2026-11-03
- **Reading time:** 6 min read
- **Topics:** leadership, data science
- **Canonical URL:** https://www.tmashininisekgoto.com/blog/data-team-when-they-push-back
- **Markdown source:** https://www.tmashininisekgoto.com/blog/data-team-when-they-push-back.md

---

*Part six of [Building a Data Team](https://www.tmashininisekgoto.com/blog/series/building-a-data-team). [Part four](https://www.tmashininisekgoto.com/blog/data-team-clear-path-for-work) gave the work a clear path.*

> **The principle.** Do not argue for change. Show it working, on a real problem, at the moment people most need it.

**You are at this stage from your first week.** It runs alongside every other stage. Expect it, and do not take it personally.

The hardest part of the whole build was not technical.

When you arrive with a new way of working, you are telling people that the way they have worked for years must change. Even when you say it kindly, that is hard to hear. I understand that better now than I did at the start.

So there was pushback, and a lot of red tape. Requests stalled. We were escalated many times. Management also wanted results they could count this quarter, while most of what I was building would only pay off later.

## Why arguing does not work

I could explain why data needed governing, and why we needed a better platform. People could listen, nod, and carry on as before. They had their own pressures, and my slides were only a promise.

Promises do not change much. Saved time does. So we changed our approach: show value by action, not by words. In plain terms, that means three things:

- Have the better way ready before anyone asks for it.
- Prove it on a real problem, not in a demo.
- Show it to the people who feel the pain.

## The day the fire came

Then a major system change went wrong for us, and one of our main workflows fell behind. About a million records were arriving every day, and the old systems could handle only about 100,000. We fell further behind every day, until the backlog reached around 100 million.

Here is what most people miss about a backlog: new work does not stop arriving while you catch up. Try it yourself below.

<BacklogTank />

Clearing a backlog like that would normally take about three months. Meanwhile, clients were complaining and cancelling, people were under real stress, and the problem was escalated all the way to the top.

We already had an alternative in progress. I had piloted it on our own work, so we did not arrive with a complaint. We arrived with a plan.

We worked on two tracks at the same time. Track one was today: get enough data onto the new platform to support the business right now. Track two was slower: turn that emergency measure into something the whole team could rely on.

It worked. We cleared the backlog, and we kept up with everything arriving each day. Today, our platform can process more than 100 million records a day, so the same kind of backlog can be dealt with in under a day. That is about 99% less time, or about 90 times faster.

Nobody argued about the platform after that. Results ended the argument.

## You do not get budget for infrastructure. You get budget for pain.

This is the most useful lesson I can pass on. Nobody wants to pay for foundations when everything looks fine. When something is on fire and the chief executive is asking questions, the conversation is very different.

That does not mean you should wish for a crisis. It means you should prepare for one. You can usually see where things will break. Do the work quietly, so that you are ready when it happens.

Each change we made was proven this way:

| What we wanted | What proved it |
|---|---|
| **A platform that can scale** | Clearing the backlog |
| **Governed data** | Catching bad data before it caused costly mistakes |
| **Security checks** | Reviews of the outside services and software we depended on |
| **Documentation** | Audits and new people joining the team |

## Build on what exists

Be careful with the word "new". Many of the processes we needed already existed in some form. Audits and security reviews were there long before me. We did not throw them away. We connected them to a faster way of working.

That made a big difference. People who have built something are far more likely to help you if you improve it than if you call it useless. Going around them also rarely works, because you will need the same people next month.

## The mistake I would not repeat

Our biggest mistake was how we moved. Most of the initiatives we took had no plan shared with the business, and we did not engage the business first. We just went ahead, and the whole business had to catch up afterwards. That included the teams that support us, such as technology, and we are still aligning with them today.

That speed helped us get results. I also believe it caused some of the pushback we met.

So do both. You do not need permission to prove something on a small, real problem. But before you roll it out, tell the people it will affect, share your plan and give them time to prepare. Showing beats arguing. Surprising people does not.

## The long game has a price

I must be honest about this part. Sometimes I held my position when management wanted something else, because I could see what a lasting capability would need. That can end well or badly, and you should know that before you choose it.

If the long game pays off, you were a builder. If it does not, you were difficult.

We were escalated. We were told no. We kept our heads up, kept delivering what the business needed in the meantime, and kept building.

## What to do on Monday

1. Write down the next crisis you can see coming. What will break first?
2. Build a small version of the fix now, using a real problem.
3. Measure it in words the business understands: time, money and customers.
4. Find out who owns the current process. Go and speak to them before you change anything.
5. Find someone senior who feels this pain, and show them your result.

## You are through the worst of this stage when

- You have a result that people outside your team talk about.
- Someone senior speaks up for the work when you are not in the room.
- The teams you depend on know how to work with you.
- People start asking for your way of working.

Next comes the hardest test of a leader: [Stage 5, trust your people, then let go.](https://www.tmashininisekgoto.com/blog/data-team-trust-and-let-go)