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

more notes

Browse source
This commit is contained in:
counterweight 2025-07-10 23:52:38 +02:00
parent 59b20ecda8
commit b7918b1916
Signed by: counterweight
GPG key ID: 883EDBAA726BD96C
1 changed files with 59 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

72
public/writings/notes-and-lessons-from-my-departure-from-superhog.html
View file

@ -17,7 +17,7 @@
<p><a href="../index.html">back to home</a></p>
<hr>
<section>
<h2>Notes and lessons from my departure from Superhog</h2>
<h2>Notes for myself during my departure from Superhog</h2>
<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
@ -107,23 +107,69 @@
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
with them. Even if you're not working together every day 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 up will
disappoint them.
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.
</li>
<li>
Engineering leadership is quite a bit like parenting when it comes to mirroring. Regadless of what
Engineering leadership is quite a bit like parenting when it comes to mirroring. Regardless of what
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
properly, submit to absurd requests instead of collaborting 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.
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.
</li>
<li>People care little about having an office on the beach.</li>
<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>
</ul>
<hr>