Hi, Pablo here
If I started a Data team again
In November 2023, I joined Truvi (back then called Superhog) as the first member of its new Data team, effectively making my hiring and the team's birth the same thing. The CEO and COO brought me in to help a young, upcoming and quite chaotic UK SaaS company make it out of the void of Data darkness, where no one knew shit, figures came in with three months of delay and VLOOKUP was the closest thing there was to integrating data from two systems.
The team is nowadays very much established and critical for the business. We've built our spot within the org, and many colleagues wonder how life could ever exist before. We can tell many tales on delivering value to Truvi, and we have ambitious plans to keep doing more and better. And I'm having a blast leading it.
For me, it was quite a journey: it was the first time I started a Data team from a greenfield situation. Some day I'll make a longish writing on the whole experience, but today, I wanted to focus on a few regrets I have. I personally think I've done a good work, I'm proud of where the team is at today, and the words (and actions) of the company board show that they are aligned with this. But still, there's always room to fuck up, and I do have a few parts of the story where, looking back in retrospective, I think I took the wrong turn.
The first thing I regret is not hiring faster which, taking personal responsibility, means I didn't focus enough on it and I wasn't as effective as I should have been. When I started the team, I quickly secured consensus from the founders to go hire two more members for it, and we all agreed it made sense to spend those bullets to find two Data Analysts. We found Uri and Joaquín, which are still with us today doing a terrific job.
The bad news is they joined in May 2024, which means it took a whopping ~6 months from decision to result. It didn't feel terrible at that moment. I was very much busy with the onslaught of work that comes with kickstarting the team (meeting everyone, aligning with other teams, designing and starting out infra, doing basic, urgent starting deliveries, etc.). But now I realise some of those things would have been easier to do with the guys already around. So there goes regret number one. Lesson: if you have agreement to get more hands on the team, make it priority #1.
The second thing I'm not happy about is not completely dropping and rebuilding a few legacy bits I inherited when joining. Truvi had an insane amount of unmet needs in data and reporting right before I joined, so a bit of capacity from the development teams was derailed at some point to create a couple of basic reporting and data exporting tools to support other teams. Those were small and done in a rather crude way, as a result of (1) being done by backend guys with no previous experience in the Data domain, and (2) in parallel to other very important product development work. I don't blame them, I assume they did the best they could given the circumstances.
My mistake was to decide early to inherit and continue those, instead of bulldozering them and building things from scratch with better tools and practices. It would have been quite easy to do at the time given that those data products were rather small (and coming back to my first regret, it would probably have been even easier to bulldozer them if the new hires would have been around already). At the time, I traded off leaving those be and have a continuist approach to building incrementally in order to get going with some other fresh new scopes faster. I'm not fully sure that the call was wrong (perhaps in a parallel universe, I would think we shouldn't have rebuild those from scratch because it delayed delivering other important things). But I do feel it was wrong right now. As a consequence, today we have several data products and architectural constraints which are a royal pain in the ass to maintain and grow with the company. For example, we're currently stuck with a lot of reporting in Power BI, which I hate for multiple reasons, one of them being how badly I want to have code defined dashboards. Bulldozering and replacing now will be much more painful than it would have been back then, so the velocity of the team is now paying for this mistake.
There goes another lesson: if you're inheriting a few, small legacy products that don't fit in your view and you can afford to remove or re-build them to allow your plans to be pristine, do it now. Don't wait.
A third thing I would have done differently is to start working on Data literacy across the company earlier and more intensely. In part of the work we do in the Data team, we come in with a very polished, mature result: this is exactly what you need to know, or the exact pristine, read-only grade data you had to check, or the informed decision you are after. But in many other cases, our delivery ends at the start of what I like to call the analytical last-mile: we produce some curated piece of insight and/or data that a colleague will grab and work a bit more before getting to the final business outcome. For example, I might export a set of KPIs around certain client accounts, and an account manager will pivot and fuck around with them to decide certain things around how he will handle some comms with his accounts.
This kind of two-step deliveries sometimes are insanely valuable: there are some analysis where the final user of the data is the most capable of juicing the right way, such as when someone takes the data to use it in real time in a negotiation meeting.
The bad news is that, if John from Marketing fucking sucks at Power BI, Excel, or whatever tooling you rely on to interact with your colleagues, the whole plot falls down. I'm not expecting John to crank out a monster workbook with thirty layers of business logic and seven modules of VBA, but pivoting a bit, filtering, multiply this col by that row, etc. You get the gist. If you're thinking to yourself: "anyone can do such basic things!", I would kindly invite you to sit down 15 min with some rando in your company and see them use Excel live, potentially having chunked some tranquilizer down.
Training more colleagues outside the Data team to be more proficient working with data (let it be working on Excel, writing SQL or just reasoning) is something we're actively working on now, but I think we should have started out earlier. I think this because of two reasons: the first, the ROI, measured in time, is tremendous. 5 hours of working with Jane from Finance to skill her up from 0 to Excel basics are probably much more impactful than that extra dashboard you are building, which you already sense won't be that used or valuable. The second is, this is one of the things that has a capped max pace to it, and won't happen faster than that no matter how hard you would like it to, or how many resources and money you want to throw at it. People learn at a certain pace, so it's better to start early and slow, than to trick yourself into believing you'll be able to turn Jimmy into a Power BI God in 2 days if you try hard enough when the time comes.
So, final lesson: I would start running Data literacy initiatives early. It doesn't need to take a big chunk of your capacity: sprinkling a few open sessions here and there, and running some 1:1 or small group ones with bright people, should be more than enough. It will compound over time, leading to the company better leveraging your data and tools, and the central Data team having more capacity to keep building since more end-users will be more independent.
There goes my non-exhaustive list of things I would do differently when starting a Data team from scratch. I hope it serves you if you are in a similar spot. I'm personally delighted with the idea of not screwing up in these ways if I ever find myself starting another team from scratch. I would very much rather screw up in new ways.