diff --git a/public/static/data-alley-oop.jpeg b/public/static/data-alley-oop.jpeg new file mode 100644 index 0000000..3eb5709 Binary files /dev/null and b/public/static/data-alley-oop.jpeg differ diff --git a/public/writings/if-i-started-a-data-team-again.html b/public/writings/if-i-started-a-data-team-again.html index a110675..7c0473f 100644 --- a/public/writings/if-i-started-a-data-team-again.html +++ b/public/writings/if-i-started-a-data-team-again.html @@ -19,38 +19,126 @@

If I started a Data team again

- When starting a data team at a startup, there are several key considerations that can make or break the - team's success. One crucial aspect is the existing reporting and dashboard setup. If there are any - issues with the current system, it is essential to address them immediately. In my experience, leaving - existing problems unattended can lead to significant headaches down the line. For instance, when I - joined SuperHawk, the company already had a few reports in Power BI, which had been developed by the - development team. However, I was not satisfied with the way these reports were built, as they exhibited - bad patterns, were not scalable, and were too closely tied to the application. Despite my reservations, - I chose to focus on other tasks, leaving the Power BI reports as they were. This decision ultimately - proved to be a mistake, as we continued to build upon the existing system, making it much more - challenging to transition to a new platform later on. - - Another critical factor in the success of a data team is hiring. I joined SuperHawk in November, and it - took approximately seven months to bring our first data analyst on board. Although we had aligned with - the C-level team on the need for additional personnel within the first few weeks, I prioritized other - tasks, such as infrastructure setup, team planning, and getting to know the company. In hindsight, I - realize that I should have focused more on hiring, as having the right people on board would have - significantly improved our efficiency and speed. With the budget and resources available, it would have - been feasible to hire talented individuals earlier, potentially within two or three months. - - Involving people from other teams in the data analysis process is also vital. Our setup is fairly - standard, with the data team owning a data warehouse and providing reports to other departments. - However, there is often a need for additional analysis, which can be time-consuming for the data team. - To mitigate this, I would have benefited from identifying and training "domain analysts" or "satellite - analysts" within other teams. These individuals would have been capable of working with data, providing - insights to their own teams, and potentially even owning certain aspects of data analysis. By empowering - these employees, we could have delivered more value and avoided becoming a bottleneck. - - In retrospect, there are three key things I would have done differently. Firstly, I would have addressed - any issues with the existing reporting and dashboard setup immediately. Secondly, I would have - prioritized hiring and focused on bringing the right people on board as early as possible. Thirdly, I - would have involved people from other teams in the data analysis process earlier, by identifying and - training domain analysts or satellite analysts. + 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.

back to home