Not all conflicts are unhealthy posted on 13 April 2024

I recently caught up with an old coworker. While I don’t remember all the details on what they were working on, I remember two things

  • We had a lot conflicts/tensions because of our responsibilities and how product, legal and other aspects of the business were pulling us in different directions
  • It was a pleasure working with them – even with the escalations. This is what I ultimately remember from working with them.

This is where you can have conflicts with coworkers, but these should never be personal. You work in the same company so the problem is something you both should figure out how to tackle. Sometimes they happen because the balance you have to achieve is tough – you have to perform difficult trade offs. This is nobody’s fault (besides maybe leadership, but the conflicts might exist just because of the industry/space you are working in).

So work with people when conflicts happen, position everyone involved on the same side trying to solve the problem. If you can’t agree on a solution, work with your coworkers to paint a fair picture of the problem and escalate to your common leadership.

It also helps to remember that:

  • People are trying their best in non toxic environments – don’t assume evil intent by default
  • What’s best for the company might not be what’s best for your team mission/charter. For example that’s why Legal doesn’t run a company but a CEO – things don’t always go their way, sometimes the risks are worth taking
  • It’s ultimately a job and people matter more than companies. I personally don’t remember many technical details about projects I worked at Google, but I still vividly remember the people I enjoyed working with.

Last but not least, if you worked with me in the past and had conflicts (e.g. because of privacy restrictions that I used to be responsible for), please don’t assume I didn’t enjoy working with you :)

LinkedIn post

Finding a good manager is the most important posted on 12 April 2024

When I started managing people at Google, the main thing I remember from the class for new managers was that people leave their job first and foremost because of their manager – not because of compensation, peers or better opportunities outside.

The truth is that many aspects of your job are paired with having a good manager:

  • A good manager will argue for your compensation/promotion
  • A good manager will find ways to expand your scope and to stimulate your growth by pushing you (at the right pace) out of your comfort zone
  • A good manager will attract and retain talent – your peers

I personally have/had amazing managers at Google/Databricks (e.g. Karthik Lakshminarayanan, Mainak Sen – who both happen to be at Databricks if you’re looking for a job). They are the reason for my past/current growth – my experience with them is vastly different than every time I was temporarily reporting to VPs.

From my personal experience, here are the qualities I’ve found in good managers:

  • Being Honest and transparent – the best feedback is straightforward and fresh feedback
  • Having empathy and being supportive – little things can go a long way, e.g. letting me work slightly off hours when I became a dad, or supporting my move to Amsterdam
  • Having the skills you are lacking (and vice versa) and adjusting to yours – you form a pair with your manager, and if you can both adjust to maximize your combined impact, it will do marvels
  • Having both a good vision and people skills – this is what allows you to work on stable/important projects. It is also in my opinion the best way to retain talents

What skills/qualities are you looking for in a manager when considering changing jobs?

Illustration: A happy and relax software engineer because that’s what your job looks like when you have a good manager

LinkedIn post

Good leadership is flexible posted on 11 April 2024

There are so many articles about what being a good leader is – e.g. being a “servant leader”, a “strongly opinionated leader” etc. The truth is being a good leader just boils down to helping your team strive and maximize its impact.

This also means that your type of leadership has to change based on the team you are leading and the environment you are working in:

  • You don’t lead a very senior team the same way you lead a team of new grads, for the same reason as you can’t lead a 500 person org the same way you lead a 10 person team.
  • You should adapt your leadership based on the current gaps – e.g. if what’s missing in your team is technical leadership, it’s more important to fill this gap than try to provide additional leadership around people management/processes.
  • Even within a team, you should adapt based on the needs of every individual. While you must strive to be fair to every team member, some coworkers may need more hand holding/traditional leadership while others may need more support/being pushed out of their comfort zone.

If you are in a position of leadership, one of the most important habits you can develop is to constantly step back and assess where your leadership is actually needed – this also implies that you should constantly gather feedback from your team to understand pain points, difficult dynamics and rising issues.

This is very similar to how I believe good senior ICs must be able to write code if they have to – e.g. if they move to a smaller company where they won’t have an “army” of junior engineers to execute their design/vision.

This makes being a leader a constant struggle where whatever mental framework you built in the past should be revisited every now and then – this is also what makes the role interesting in my opinion.

LinkedIn post

You shouldn't use third party software posted on 10 April 2024

When you use a third party library to save yourself a bit of time and ship a feature a bit faster, you very likely ignore the cost of using such a library.

Libraries can have security vulnerabilities (CVE, GHSA etc.) and at this time you have to update them either for security purposes (so you won’t get breached) or for compliance purposes (so you don’t lose your certification). In practice updating libraries only when they have security issues is a terrible choice – if you are 10 major versions from the earliest one that’s vulnerability free, you won’t be able to upgrade quickly. At the end of the day, you have to constantly keep your libraries up to date and this takes time (because not every update is backward compatible).

Third party libraries also come with all sorts of quality issues – even if they are backed by a company or open source foundations (like Apache). I’ve seen silly bugs (e.g. “null” return than “” for getPath() with the path is not set) and some more complex ones that happen only when you stress the library to its limits (e.g. when the max number of opened files is reached) – and the truth is very few of these libraries have been pushed to their limits.

A mental framework/questions that may help you decide if you should use third party libraries is along the lines:

  • Do you have to? There are cases where you don’t have a choice (e.g. integrating with another company service)

Is the library backed by a company/open source organization? Is the library going to be maintained well for the foreseeable future?

  • Does the library have bugs? Is the code of good quality? Would you hire the author to work in your company? Note that the issue might not necessarily be how good the author is but more how invested the author is in this library.
  • Does the library support your use case/environment? E.g. is it known to support your QPS, your type of workloads etc.
  • Do you need the whole library or just a subset? How much time would it be for you to implement the feature you need?
  • Is the library well maintained and free of security issues? Are the upgrades backward compatible? How much time would it be for you to keep this library up to date? Compare this cost with the time to implement it yourself.

Using third party libraries in many cases is like doing business with a loan shark – you may have to, but the costs are higher in the long term. So if you can, don’t use them.

LinkedIn post