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
|
|
|
|
|
departures under my belt already, I know a bit on what will come next. I know one part of it is that 99%
|
|
|
|
|
of the details of what happened during my tenure at the company will completely disappear 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>
|
|
|
|
|
<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
|
|
|
|
|
retrospect in an intelligent way, 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.
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
If you're in a B2B business where customers will have a long term relationship with you, and you
|
|
|
|
|
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
|
|
|
|
|
customer needs.(no matter if they're a good fit).</li>
|
|
|
|
|
<li>Cut corners, surely do and say thing that are in moral gray areas. If you're unlucky, cross
|
|
|
|
|
moral red lines.</li>
|
|
|
|
|
<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>
|
|
|
|
|
I think many of these issues get solved by structuring compensation so that they 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.
|
|
|
|
|
</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>
|
|
|
|
|
<li>Non-technical founders need CTOs with strong characters nearby to protect them from themselves.</li>
|
|
|
|
|
<li>I managed to deliver astonishing amounts of value with extremely simple tooling. This had many
|
|
|
|
|
advantages and was a silent win. It's not sexy, but I think it should be.</li>
|
|
|
|
|
<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
|
|
|
|
|
by
|
|
|
|
|
Jason Fried and DHH, and 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 now even more of a
|
|
|
|
|
believe of it.</li>
|
|
|
|
|
<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>
|
|
|
|
|
<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
|
|
|
|
|
non-tech colleagues, etc, the rest of engineers will do it as well. 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 and work
|
|
|
|
|
things into a way of working 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, 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
|
|
|
|
|
ability to allow terrible things to happen precisely because stepping up would require courage and
|
|
|
|
|
they have none. Basically the way <a href="https://www.youtube.com/watch?v=uW9Q1cm_Tnw"
|
|
|
|
|
target="_blank" rel="noopener noreferrer">Upham gets Mellish killed in Saving Private Ryan</a>.
|
|
|
|
|
The attrocities that can be tolarated or even supported by cowards in this manner can be terrible,
|
|
|
|
|
and even more depressing that the loud acts of bold, evil men. Plus, group thinking will create
|
|
|
|
|
comfort and normalize the behaviour in the fashion of the bystander effect.
|
|
|
|
|
</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
|
|
|
|
|
of magnitude less of an issue to organizational data literacy that 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 SAYS he will reward/punish.
|
|
|
|
|
</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
|
|
|
|
|
scratch. But I guess you could also do a better job working yourself out incrementally from the
|
|
|
|
|
fucked up situation you failed yourself into.</li>
|
|
|
|
|
<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-07 10:53:51 +02:00
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
<hr>
|
|
|
|
|
<p><a href="../index.html">back to home</a></p>
|
|
|
|
|
</section>
|
|
|
|
|
</main>
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
|
|
|
|
|
|
</html>
|
