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

draft

Browse source
This commit is contained in:
counterweight 2025-02-03 16:22:51 +01:00
parent adf2b80fba
commit 4de1436ade
Signed by: counterweight
GPG key ID: 883EDBAA726BD96C
1 changed files with 132 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

132
public/writings/valuing-data-teams-output.html Normal file
View file

@ -0,0 +1,132 @@
<!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>Valuating data teams output</h2>
<p>
- Freedom and fucking up
- How work looks like
- This is an economics problem
- Fairy tail organizational designs
</p>
<p>
In 2023, I had the chance to do something not a lot of people get to do: I started a Data team in a
startup (<a href="https://truvi.com/">Truvi, formerly Superhog</a>) from scratch.
</p>
<p>
Being in a greenfield situation, both in organization and technical terms, was equally challenging and
rewarding. It gave me the right space and craving to spend time thinking on stuff I hadn't before. This
included very foundational questions such as... what should the Data team do? The kind of stuff you
don't think about much when you land in a cruise ship that's already been rolling for a while, and you
get told your job is to pull that lever up and down when the light tells you to. Ever since, I've had
the
chance to learn and think a lot about embedding a Data team in a small SaaS company.
</p>
<p>
One of the hard and interesting topics is how do you measure the success of the team. How do you look at
what the team has done and answer the following questions:
</p>
<ul>
<li>How valuable is this thing we delivered?</li>
<li>Was it the most valuable think we could have done?</li>
</ul>
<p>
These are not trivial questions. Because it's easy to fuck up. Being a nimble team in a small company,
the amount of flexibility you enjoy is ecstatic. You can (and usually need to) pivot a lot, very fast.
But with freedom comes responsibility, and the pleasure of having many choices comes with the pain of
wondering if you're screwing up in what you choose.
</p>
<h2>
How work looks like
</h2>
<p>
I find experience and real situations make abstract rants like this one much more interesting, so let me
explain a bit what the Data team at Truvi faces on a daily basis to give some context.
</p>
<p>
Truvi is a SaaS company that services short-term rentals (STR) hosts and guests. Our goal is to help
both parties reduce and manage risk in their bookings. Risk here means, for the other part, the other
party doing something nasty to you (e.g. your guest burns down your BnBs kitchen, or your host let's you
know the property you booked is flooded right when you show up at the door on a Monday night at
11:30PM). We offer multiple services, like screening and protection, to help both parties manage this,
and we charge fees for it.
</p>
<p>
We deliver our services through a couple of in-house developed applications and some API integrations
with <a href="https://en.wikipedia.org/wiki/Property_management_system">PMSs</a>, <a
href="https://en.wikipedia.org/wiki/Online_travel_agency">OTAs</a> and other funky acronym-named
types of companies involved in the STR industry.
</p>
<p>
The Data team's main responsibility, as defined by me, is to ensure people in the company know what they
need to know. We deliver this in multiple ways:
</p>
<ul>
<li>We maintain a lot of reporting. Some of it might be company-wide KPIs all management looks at,
some others are more operational detail that only affect certain teams or functions.</li>
<li>
We keep ourselves available for adhoc, quick and dirty, one off requests. We rotate this through the
different members of the team since it's quite disruptive for one's agenda and focus.
</li>
<li>
We deliver adhoc, slow and steady, brainy reports whenever people not only need Data, but someone
who knows what he's doing because the analysis requires above average data literacy.
</li>
<li>
We support data heavy projects, such as A/B testing or the acquisition of external data sources.
</li>
</ul>
<p>
Even if this categorization looks neat, the reality is more of a barrage of a million different things,
coming through the door all at once without any order.
</p>
<p>
Given our humble capacity for delivering and our colleagues heavy appetite for asking, only a sliver
of what gets requested will be done soon. One of my jobs is to decide, together with the company
leadership, what makes it in. It's a tough job at Truvi, and it's been a tough job at previous companies
I've been at. I think that is the case because of poor organizational design. And I think we have a lot
to learn from economics.
</p>
<h2>Economic calculation</h2>
<p>
The situation we have in my team is an economical one. We have lots of needs and we can't satisfy all
of them.
</p>
<p>
This is the same situation society faces at scale: there's plenty of capital and man hours we can put up
to good use, but we have infinite options. What do we do more, hospitals, more schools or more beers?
</p>
<p>
In society, despite what statists and bureacrats would like, these decisions are not made by a bunch of
all knowing intellectuals in their parties office. They are made on the streets, by individuals that
decide how to spend their own money and time.
</p>
<p>
People spend their own very wisely. Even if it might look like they do stupid stuff, they don't. They do
what's good for them, with their resources and preferences. Even if we don't share their choices. Even
if we think we know better than them.
</p>
<hr>
<p><a href="../index.html">back to home</a></p>
</section>
</main>
</body>
</html>