Hi, Pablo here

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 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.

But most other things will be gone from my brain, surprisingly fast.

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.

• 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.
• 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 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.
• 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:
  • Sell to anyone, regardless of whether there's a good fit between your offering and the customer needs.
  • Cut corners, surely do and say things that are in moral gray areas. If you're unlucky, even clearly cross moral red lines.
  • 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.
  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.
• If you're lucky to find talented employees, go crazy about retaining them.
• The unexpected death of collegues can be a great blow to the business.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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. 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.
• 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.
• 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 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.
• 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.
• 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, mindlessly submit to absurd requests instead of collaborating productively with their 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.
• 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 and acting would require courage and they have none. Basically the way Upham gets Mellish killed in Saving Private Ryan. 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.
• 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 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 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 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.
• 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.
• 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 before he leaves. Not doing this, and instead simply waiting for his last day to remove his creds and users from the infra, is dangerous.

back to home