150 lines
No EOL
11 KiB
HTML
150 lines
No EOL
11 KiB
HTML
<!DOCTYPE HTML>
|
|
<html>
|
|
|
|
<head>
|
|
<title>Pablo here</title>
|
|
<meta charset="utf-8">
|
|
<meta viewport="width=device-width, initial-scale=1">
|
|
<link rel="stylesheet" href="../styles.css">
|
|
</head>
|
|
|
|
|
|
<body>
|
|
<main>
|
|
<h1>
|
|
Hi, Pablo here
|
|
</h1>
|
|
<p><a href="../index.html">back to home</a></p>
|
|
<hr>
|
|
<section>
|
|
<h2>If I started a Data team again</h2>
|
|
<p>
|
|
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>
|
|
</section>
|
|
</main>
|
|
|
|
</body>
|
|
|
|
</html> |