diff --git a/public/writings/notes-and-lessons-from-my-departure-from-superhog.html b/public/writings/notes-and-lessons-from-my-departure-from-superhog.html index 1eeb16a..5b7f96e 100644 --- a/public/writings/notes-and-lessons-from-my-departure-from-superhog.html +++ b/public/writings/notes-and-lessons-from-my-departure-from-superhog.html @@ -17,7 +17,7 @@

back to home

-

Notes and lessons from my departure from Superhog

+

Notes for myself during my departure from Superhog

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.

  • 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.
  • - 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.
    • -
  • People care little about having an office on the beach.
    • +
  • People care little about having an office on the beachfront.
    • +
  • 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.
    • +
  • 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 Upham gets Mellish killed in Saving Private Ryan. + 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. +
    • +
  • + 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. +
    • +
  • + 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. +
    • +
  • Joel Spolsky wrote this thing + you should never do. The company decided to do it anyway. We fucked up and we paid for the + consequences exactly as Spolsky lays out.
    • +
  • Employees with little retrospective capacity are dangerous. Partly related to the previous point. + This quote from Spolsky hits right on the nail: 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. 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.
    • +
  • 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.