# Stage 1: Find Out What Is True > **Summary:** The first stage of building a data function is not technology. Write down what you have and create a rhythm. When we did, we found models that were simply wrong. - **Author:** Thabang Mashinini-Sekgoto - **Published:** 2026-11-03 - **Reading time:** 5 min read - **Topics:** leadership, data science - **Canonical URL:** https://www.tmashininisekgoto.com/blog/data-team-find-out-what-is-true - **Markdown source:** https://www.tmashininisekgoto.com/blog/data-team-find-out-what-is-true.md --- *Part three of [Building a Data Team](https://www.tmashininisekgoto.com/blog/series/building-a-data-team). [Part one](https://www.tmashininisekgoto.com/blog/building-a-data-science-team-from-scratch) shows the whole road.* > **The principle.** You cannot fix what you cannot see. Before you change any technology, write down what you have and make the work visible. **You are at this stage if** nobody can list what the team runs, and answering simple questions means finding the one person who remembers. Where does this run? Who uses it? How do I get access? That was my team when I joined. In a small team, it is a serious risk. One resignation and a system nobody understands is still running. ## Write it down, as if you might leave tomorrow We started using a shared team website called Confluence. Any similar tool would do. What matters is that everyone can find everything in one place. I wrote the first page myself. It was the guide I wished someone had given me: every tool we use, where to find it, how to get access, and what a new person must do in their first week. Then comes the harder job. Go through every model already in use and write down the same things for each one: - What does it do? - What data goes in, and what comes out? - How often does it run? - Who uses the result, and for what decision? Nobody could hand us those answers, so we read the code and worked them out. Expect to do the same. ## What you may find This is the part I did not expect. Writing things down did more than record our work. It showed us the truth about it. Some models did not follow accepted methods. Some added numbers up incorrectly. A few were not really models at all: the numbers they produced had nothing sound behind them. And the business was using them to make decisions. Nobody had hidden this. Nobody had been able to see it, because nobody had ever written down how these things worked. Think about that before you plan your first big project. You could spend a year making a wrong model run faster. Until you look, you do not know which of your numbers deserve to be trusted. ## Give the team a rhythm Documentation showed us our systems. We also needed to see our work. People were busy, but the team could not say what it was working on or where things were stuck. So we set up a simple rhythm, using an approach called agile. It means working in short cycles and checking often: - **Two week sprints.** We chose what to finish next. - **Stand ups.** A short meeting to ask what is done and who is stuck. - **Sprint reviews.** We looked honestly at what got done, what did not, and why. - **Show and tell.** Every Friday, anyone could share a model, a new skill or a new technology. The show and tell became one of the best things we did. It cost nothing, and it trained the whole team. Over time, people from across the business started coming too. We also agreed how to work with the teams we depended on: who to speak to, how to ask, and what each side could expect. Without that, every request depended on knowing the right person. ## It paid off in ways we did not plan The written guides soon helped new people get started without weeks of asking around. Other teams began using our notes to understand our models. Then the auditors came. They wanted to know what our models did, what data they used and what controls existed. Writing things down did not make any model compliant, and I am not claiming it did. But when somebody asked us to explain what was running, we were not starting from zero. Months earlier, documentation had felt like extra work. During the audit, it became evidence. ## What it will cost For me it was my evenings. Nobody asks for documentation, and nobody thanks you for it at first. Expect some people to see it as a waste of time, and some to be uneasy about what it uncovers. Do it anyway, because you are building something that must not depend on you. If something only works because one particular person is available that day, you do not have a system. You have a favour. ## What to do on Monday 1. List everything your team runs, including anything that lives on someone's laptop. 2. For each one, answer the four questions above. Start with whatever affects customers or money. 3. Check the results of your most important model by hand. Do the numbers make sense? 4. Write the guide you wish you had received on your first day. 5. Start a Friday show and tell. Half an hour is enough. ## You are ready for Stage 2 when - Everything your team runs is written down, with an owner. - You know which of your important numbers can be trusted. - A new person could find their way using the guide. - The team has a rhythm, and anyone can see what is being worked on. Next: [Stage 2, give your data one safe home.](https://www.tmashininisekgoto.com/blog/data-team-safe-home-for-data)