counterweight/pablohere
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

finished

Browse source
This commit is contained in:
counterweight 2025-02-04 21:48:35 +01:00
parent 0e7711771d
commit a6471f5baa
Signed by: counterweight
GPG key ID: 883EDBAA726BD96C
2 changed files with 120 additions and 32 deletions
Download patch file Download diff file Expand all files Collapse all files

BIN
public/static/data-alley-oop.jpeg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 246 KiB

152
public/writings/if-i-started-a-data-team-again.html
View file

@ -19,38 +19,126 @@
<section>
<h2>If I started a Data team again</h2>
<p>
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 <a href="https://truvi.com/">Truvi</a> (<a
href="https://truvi.com/blog/superhog-becomes-truvi/">back then called Superhog</a>) 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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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 <a
href="https://es.linkedin.com/in/oriol-roqu%C3%A9-paniagua-708946158" target="_blank"
rel="noopener noreferrer">Uri</a> and <a href="https://es.linkedin.com/in/joaquin-ossa"
target="_blank" rel="noopener noreferrer">Joaquín</a>, which are still with us today doing a
terrific job.
</p>
<p>
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.
</p>
<p>
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, <a
href="https://retrospectivewiki.org/index.php?title=The_Prime_Directive" target="_blank"
rel="noopener noreferrer">I assume they did the best they could given the circumstances.</a>
</p>
<p>
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 <a href="i-want-code-defined-dashboards-so-badly.html"
target="_blank" rel="noopener noreferrer">how badly I want to have code defined dashboards</a>.
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<figure>
<img src="../static/data-alley-oop.jpeg" width="75%">
</figure>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<hr>
<p><a href="../index.html">back to home</a></p>