2025-07-07 10:53:51 +02:00
|
|
|
<!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>
|
2025-07-10 23:52:38 +02:00
|
|
|
<h2>Notes for myself during my departure from Superhog</h2>
|
2025-07-07 10:53:51 +02:00
|
|
|
<p>I'm writing this a few days before my last day at Superhog (now called Truvi). Having a few company
|
2025-07-16 09:52:11 +02:00
|
|
|
departures under my belt already, I know a bit on what will come next. I know one part of the drill is
|
|
|
|
|
that 99% of the details of what happened during my tenure at the company will completely disappear from
|
|
|
|
|
my memory for the most part, only triggered by eerily coincidental cues here and there every few years.
|
|
|
|
|
I will remember clearly a few crucial, exciting days and situations. I will also hold well the names and
|
|
|
|
|
faces of those with who I worked closely, as well as my personal impression and judgement of them. I
|
|
|
|
|
will remember the office, and some details of how my daily life was when I went there.</p>
|
2025-07-07 10:53:51 +02:00
|
|
|
<p>But most other things will be gone from my brain, surprisingly fast.</p>
|
|
|
|
|
<p>Knowing that experience is a great teacher, and regretting not doing this in the past, I've decided to
|
|
|
|
|
collect a few notes from my time at Superhog, hoping they will serve me in making the lessons I've
|
|
|
|
|
learnt here stick properly.</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>Growing really fast an organization without an incredibly solid vision you're going to stick to is
|
|
|
|
|
terrible. Time, money and effort will be wasted left and right, and unless you have some magic tric
|
|
|
|
|
up your sleeve, you'll run out of money and panic. Growth is about having a great vision, going for
|
|
|
|
|
it and hoping for the best, not about collecting resources and hoping that they will somehow align
|
|
|
|
|
themselves towards making money.</li>
|
|
|
|
|
<li>
|
|
|
|
|
If you're in the leadership of a company, you make decisions, and then things go badly because of
|
|
|
|
|
them, people are going to think you've fucked up and won't be happy about it. Should you publicly
|
2025-07-16 09:52:11 +02:00
|
|
|
retrospect in an intelligent way and clearly show you've learnt the lesson, you have a chance at
|
|
|
|
|
some degree of redemption, and you might even make some of the employees hopeful again that there's
|
|
|
|
|
still a second chance to go for success. If you don't retrospect at all and pretend the mishaps have
|
|
|
|
|
nothing to do with your management, they won't just think you're incompentent: they simply won't
|
|
|
|
|
take you seriously anymore, and won't be honest to you because smart people don't invest calories in
|
|
|
|
|
arguing with people who they consider idiots.
|
2025-07-07 10:53:51 +02:00
|
|
|
</li>
|
|
|
|
|
<li>
|
2025-07-16 09:52:11 +02:00
|
|
|
If you're in a B2B business where customers will have a long-term relationship with you, and you
|
2025-07-07 10:53:51 +02:00
|
|
|
have sales people, giving them incentives that are all about getting people onboard, and not about
|
|
|
|
|
long term performance, might be an expensive mistake. I've observed sales people who only care about
|
|
|
|
|
scoring deals engage in undesirable behaviours such as:
|
|
|
|
|
<ul>
|
|
|
|
|
<li>Sell to anyone, regardless of whether there's a good fit between your offering and the
|
2025-07-16 09:52:11 +02:00
|
|
|
customer needs.</li>
|
|
|
|
|
<li>Cut corners, surely do and say things that are in moral gray areas. If you're unlucky, even
|
|
|
|
|
clearly cross moral red lines.</li>
|
2025-07-07 10:53:51 +02:00
|
|
|
<li>
|
|
|
|
|
Drive the people who build and deliver your offering crazy. Since they have no incentive to
|
|
|
|
|
care about what happens after a deal is signed, they don't care if their actions in the
|
|
|
|
|
sales pipeline turn into landmines during the long-term business relationship and execution
|
|
|
|
|
of the service.
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
2025-07-16 09:52:11 +02:00
|
|
|
I think many of these issues get solved by structuring compensation so that sales people do well
|
|
|
|
|
once the leads they convert have been doing well for some time, however you want to measure that.
|
|
|
|
|
Not only nasty behaviour can be avoided, but even new, good and constructive actions might arise.
|
|
|
|
|
For example, your sales people will care more about building a great product, and so they'll
|
|
|
|
|
regularly feedback to engineers and operations and care deeply about collaborating in improving
|
|
|
|
|
things.
|
2025-07-07 10:53:51 +02:00
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
If you're lucky to find talented employees, go crazy about retaining them.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
The unexpected death of collegues can be a great blow to the business.
|
|
|
|
|
</li>
|
2025-07-16 09:52:11 +02:00
|
|
|
<li>Non-technical founders need CTOs with strong characters nearby to protect them from themselves.
|
|
|
|
|
Soft-hearted CTOs with a pleasing attitude and aversion to conflict will feel sweet at first, but
|
|
|
|
|
their lack of fightning back on certain topics will lead to sour consequences down the line.</li>
|
|
|
|
|
<li>During my tenure, my team and I managed to deliver astonishing amounts of value with extremely
|
|
|
|
|
simple tooling that was just enough for what we needed. This had many advantages and was a silent
|
|
|
|
|
win. It's not sexy, but I think it should be.</li>
|
2025-07-07 10:53:51 +02:00
|
|
|
<li>If you are silently efficient budget wise, as in you manage to achieve something consuming way less
|
|
|
|
|
money than whatever is average for your context, but you don't explain it are notably noisy about
|
|
|
|
|
it, nobody will give a damn. Even worse, your levels of efficiency may be taken for granted and you
|
|
|
|
|
might encounter trouble when asking for more bucks, even if you're still way below average.</li>
|
|
|
|
|
<li>When there's a feeling that a ship is going down, I've observed there's a direct correlation between
|
|
|
|
|
how talented an employee is and the chances he departs early. The less gifted will stay until the
|
|
|
|
|
end.</li>
|
|
|
|
|
<li>
|
|
|
|
|
If you're a SaaS and want to scale, don't leave your Finance team orphan of IT resources. Invoicing,
|
|
|
|
|
gathering customer payment details, the most frequent accounting journals, etc. should be treated as
|
|
|
|
|
first class requirements of your architecture, not as an afterthought. Your finance team needs to
|
|
|
|
|
grow in engineers, not accountants. And if you have the feeling that the number of accountants is
|
|
|
|
|
growing linearly with the volume of the business, you are in serious trouble and need to do
|
|
|
|
|
something. Failing to do this will lead to some very nasty tech debt that will kill your speed and
|
|
|
|
|
potentially make you lose a lot of money.
|
|
|
|
|
</li>
|
|
|
|
|
<li>If you've had employees rotating through various departments in your org, doing very different jobs,
|
|
|
|
|
their views and opinions are worth solid gold and should be valued as such.</li>
|
|
|
|
|
<li>Right befores starting in this company, I had just read the book It doesn't have to be crazy at work
|
2025-07-16 09:52:11 +02:00
|
|
|
by Jason Fried and DHH. At that time I thought I believed by then that it's worth creating a calm
|
|
|
|
|
environment to think clearly, since doing the right thing is way more important than executing fast,
|
|
|
|
|
and fast paced environments are not great to keep your head clear. After my time here, I'm a x100
|
|
|
|
|
times more of a believer.</li>
|
2025-07-07 10:53:51 +02:00
|
|
|
<li>Giving people in the business some basics on SQL is really useful, but that usefulness gets
|
|
|
|
|
multiplied by the tidyness and documentation of your DWH. If they need to call you up every time
|
|
|
|
|
because there's no way they can find and understand what they need in the DWH, teaching them SQL is
|
|
|
|
|
pointless and only leads to frustration.</li>
|
|
|
|
|
<li>
|
|
|
|
|
If you were part of the decision to hire someone, and then they decide to leave, you should talk
|
2025-07-10 23:52:38 +02:00
|
|
|
with them. Even if you're not working together every day anymore and the org has changed quite a
|
|
|
|
|
bit. You had a stake in this person's entrance, they remember it vividly, and not calling them to
|
|
|
|
|
grab a coffee and say bye properly will disappoint them.
|
2025-07-07 10:53:51 +02:00
|
|
|
</li>
|
2025-07-16 09:52:11 +02:00
|
|
|
<li>If a manager gets fired and you get their direct reports now reporting to you, and you know they had
|
|
|
|
|
strong respect for him, make sure to recognize that feeling the first thing. Saying something along
|
|
|
|
|
the lines of "Guys, I know you respected X and were fond of working with him, and that you might not
|
|
|
|
|
be happy with his departure and having to report to me instead. I understand that and think it's
|
|
|
|
|
natural", will go a long way in helping with the grieving and making them feel more comfortable.
|
|
|
|
|
</li>
|
2025-07-07 10:53:51 +02:00
|
|
|
<li>
|
2025-07-10 23:52:38 +02:00
|
|
|
Engineering leadership is quite a bit like parenting when it comes to mirroring. Regardless of what
|
2025-07-07 10:53:51 +02:00
|
|
|
you say should be done, people will ignore that a lot and tend to do what you do. If senior
|
|
|
|
|
engineers do patchy shit on the database, don't document a thing, cut corners instead of building
|
2025-07-10 23:52:38 +02:00
|
|
|
properly, mindlessly submit to absurd requests instead of collaborating productively with their
|
2025-07-16 09:52:11 +02:00
|
|
|
non-tech colleagues, etc, the rest of engineers will do it as well, regardless on how many training
|
|
|
|
|
sessions on best practices you run. Conversely, if you focus on quality, give time and room to do
|
|
|
|
|
things right, reward ingenious solutions to problems, treat incidents in professional and serious
|
|
|
|
|
ways, push back from stupid managerial situations to work things out in a way that is good
|
|
|
|
|
for everyone, document your work properly, etc. you will soon find the rest of your colleagues
|
|
|
|
|
(specially, the most junior ones) following your lead, often times without you even needing to
|
|
|
|
|
insist on good practices.
|
2025-07-07 10:53:51 +02:00
|
|
|
</li>
|
2025-07-10 23:52:38 +02:00
|
|
|
<li>People care little about having an office on the beachfront.</li>
|
|
|
|
|
<li>If you manage to raise a team to have team-ownership mentality (as in, they know what's their high
|
|
|
|
|
level goal and will always strive for it, even if you don't provide strict guidance or are not
|
|
|
|
|
around at all), you might get an ego hit because it suddenly feels like you are not needed. Rest
|
|
|
|
|
assured, even if you're not immediately needed, your team values you, and other managers and
|
|
|
|
|
executives will notice the work you've done with the team, even if they don't voice it.
|
|
|
|
|
Unfortunately, it's likely that the appreciation for your achievement only becomes visible when you
|
|
|
|
|
decide to leave and people panic.</li>
|
|
|
|
|
<li>People with cowardly and anxious characters might seem harmless. But don't undersestimate their
|
2025-07-16 09:52:11 +02:00
|
|
|
ability to allow terrible things to happen precisely because stepping up and acting would require
|
|
|
|
|
courage and they have none. Basically the way <a href="https://www.youtube.com/watch?v=uW9Q1cm_Tnw"
|
2025-07-10 23:52:38 +02:00
|
|
|
target="_blank" rel="noopener noreferrer">Upham gets Mellish killed in Saving Private Ryan</a>.
|
2025-07-16 09:52:11 +02:00
|
|
|
The attrocities that can be tolerated or even supported by cowards in this manner can be terrible,
|
|
|
|
|
and even more depressing that the loud acts of bold, evil men. Plus, if there are many cowards
|
|
|
|
|
clustered together, group thinking will give them comfort and normalize the behaviour in the fashion
|
|
|
|
|
of the bystander effect.
|
2025-07-10 23:52:38 +02:00
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
Only badmouth a colleague in front of others if you are going to eventually raise the issue to
|
|
|
|
|
either him or his superiors. Don't ever pointlessly complain with third parties if you will never
|
|
|
|
|
act on the issue. Specially with your direct reports. It generates a nasty victim culture, and once
|
|
|
|
|
you get it started, it's hard to stop.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
I have found that the lack of easy access to data and skills like SQL and data analysis are orders
|
2025-07-16 09:52:11 +02:00
|
|
|
of magnitude less of an issue to organizational data literacy compared to managers who don't expect
|
|
|
|
|
a data-driven approach from their reports. People start caring about data when their boss demands
|
|
|
|
|
they do their work using data. People continue ignoring data when their boss tolerates the lack of
|
|
|
|
|
data. And when observing this, it's vital to also keep in mind that reports adjust their behaviour
|
|
|
|
|
to what their manager actually rewards/punishes, not what their manager <em>says</em> he will
|
|
|
|
|
reward/punish.
|
2025-07-10 23:52:38 +02:00
|
|
|
</li>
|
|
|
|
|
<li>Joel Spolsky wrote <a
|
|
|
|
|
href="https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/">this thing
|
|
|
|
|
you should never do</a>. The company decided to do it anyway. We fucked up and we paid for the
|
|
|
|
|
consequences exactly as Spolsky lays out.</li>
|
|
|
|
|
<li>Employees with little retrospective capacity are dangerous. Partly related to the previous point.
|
|
|
|
|
This quote from Spolsky hits right on the nail: <em>It's important to remember that when you start
|
|
|
|
|
from scratch there is absolutely no reason to believe that you are going to do a better job than
|
|
|
|
|
you did the first time. First of all, you probably don't even have the same programming team
|
|
|
|
|
that worked on version one, so you don't actually have “more experience”. You're just going to
|
|
|
|
|
make most of the old mistakes again, and introduce some new problems that weren't in the
|
|
|
|
|
original version.</em> I would only nuance that if you can retrospect deeply and learn from the
|
|
|
|
|
mistakes you made on the first run, perhaps there's some hope you may do a better job starting from
|
2025-07-16 09:52:11 +02:00
|
|
|
scratch. But I guess if you manage to retrospect and learn properly, you could also do a better job
|
|
|
|
|
working yourself out incrementally from the fucked up situation you failed yourself into.</li>
|
2025-07-10 23:52:38 +02:00
|
|
|
<li>If you set up a variable/bonus scheme, refrain from changing the structure frequently, even if you
|
|
|
|
|
are not really making it more stingy. Too much shuffling on that area will get employees thinking
|
|
|
|
|
you're playing games on them, even if it's not the case.</li>
|
2025-07-16 09:52:11 +02:00
|
|
|
<li>When an engineer who designed, deployed, and since then operated a non-trivial production system is
|
|
|
|
|
about to leave, ask him to finish his handover and lock himself out days before his actual last
|
|
|
|
|
working day. Challenge him to a nice treat by making it clear that, once he's locked out, he doesn't
|
|
|
|
|
have any other duties other than help his colleagues should something not work after his departure.
|
|
|
|
|
This way, you provide him with an incentive to handover as perfect and fast as possible (paid
|
|
|
|
|
holidays), and you make sure that you get a chance to try to operate the system without him
|
|
|
|
|
<em>before</em> he leaves. Not doing this, and instead simply waiting for his last day to remove his
|
|
|
|
|
creds and users from the infra, is dangerous.
|
|
|
|
|
</li>
|
2025-07-07 10:53:51 +02:00
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
<hr>
|
|
|
|
|
<p><a href="../index.html">back to home</a></p>
|
|
|
|
|
</section>
|
|
|
|
|
</main>
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
|
|
|
|
|
|
</html>
|
