As a software engineer, I find that there is always some major learning every few months. Some of these learnings are not specific to software engineering. Here are some non-obvious things I wish I knew when I started out:
1. Misaligned incentives are the root of all evil
At a previous company, here is how promotions worked: the manager writes a doc explaining the contributions of one of their reports and puts them up for promotion with the final decision made by a panel of other managers within the same org. The most common reason why promotions get rejected:
Engineer X has not built anything that demonstrates that they are operating at the next level. Someone on my team built this system Y which I consider to be technically challenging and what I would expect an engineer to have built before promoting them to this level.
You are X’s manager. What do you do? You try to find a project that will allow X to do that. Seems reasonable. But if it is not possible to find such a project, what do you do? You can do one of the following:
- Explain to X that he/she will have to wait 6 months for some new opportunity to build a complex system. Possible downside: X decides that’s too long and thinks about leaving the team/company
- Ask X to join another team where there is such an opportunity. Possible downside: Getting a replacement engineer is not easy and your team does not meet it’s goals which reflects poorly on you.
- Ask X to build a complex system for a problem with a simple solution so they can get promoted. Possible downside: The complex system causes issues for the team but that maybe months down the line and possibly someone else’s problem.
In my experience, most managers ended up choosing the last option which made sense given their position. This became so common that we even had a derogatory term for it – promotion service. Here is the lifecycle of a promotion service:
Identify business problem -> Come up with a complex technical solution -> Write technical design doc -> Manager puts engineer for promotion -> Engineer gets promoted -> Engineer leaves the team -> Other engineers on team realize that this service isn’t needed -> Deprecate the service
I have seen this happen multiple times and on multiple teams to know that this isn’t an isolated phenomenon.
So, who do you blame for this? Would you blame the engineer who worked hard to build this system which he believes to be a value add? Would you blame the manager who cared about the career growth of the engineer? At a local level, everyone has good intentions but that’s not always enough to make the right global decisions. This is why you need incentives that are aligned with what is good for the company long-term. The role of leaders is to think carefully about the incentives that they create since that will shape the culture more than fancy company values that are shared during new-hire orientation. (If you think this doesn’t happen at your company, that’s great but you should be mindful of insider bias which blinds you to things happening at your current company)
2. Everyone has a bias
Here is the definition of bias:
Bias: prejudice in favor of or against one thing, person, or group compared with another, usually in a way considered to be unfair.
This may sound controversial but we are all biased. What this means is that we all have a natural tendency to lean one way or another on different topics and those tendencies have been shaped by our prior experiences. Given that we all have different life experiences, it is quite natural for us to be biased a certain way. In practice, this means that given the same information, we would come to different conclusions on different topics. This is the reason why diversity is key and it allows us to balance out each others’ biases.
Why is this important to know? This is useful for a couple of reasons:
- Be aware of your own biases so you can effectively correct for it through input from someone else who thinks differently from you. For instance, if your tendency is to move quickly and build things scrappily, you should consider talking to someone who has a different approach to engineering and who fundamentally believes your approach is flawed. This can be very difficult to do (I am personally not very good at this) since you are more inclined to seek out opinions which are similar to your own (commonly known as confirmation bias)
- Be aware of others’ biases to facilitate good decision making. If you are putting together a project team, take a minute to think about what each of them bring to the table. Maybe the engineer on the team has built a very similar system and has certain strong beliefs on what to do and what not to do. If so, it maybe helpful to pair that engineer with another engineer who has experience working on a different domain and will bring a fresh perspective. In other contexts, when seeking feedback from peers, it is best to include folks who think very differently from you and will help reveal your own blind spots. On the flip side, when receiving advice, think about the bias that the other person has and weigh the advice appropriately. (I have fallen into the trap of blindly taking advice from others, applying it and then wondering why it didn’t work for me when it worked for them)
3. Successful people find a way to say “yes”
How many times have you worked with someone from another team and felt like banging your head against the wall? I don’t even keep track of this anymore. But on some rare occasions, you meet someone who goes out of their way to help you with nothing to gain in return. I have seen some people even take on more work for their team to help me/my team achieve it’s goal. Yes, these people do exist! And they are very successful too.
So why do these people exist? From observing them (a few product managers I know fall into this category), it becomes clear that they are always invested in solving the problem. They seek to understand and brainstorm with you on how to solve the problem. It doesn’t seem to matter that this your problem and not theirs. These people are able to think beyond petty team politics/priorities in the short-term and do the right thing for the company long-term. If the incentives are setup correctly, such people get rewarded appropriately. The amount of goodwill that they generate by being helpful is very valuable and that social capital can help them achieve greater heights.
What about the people who are in the other camp? I have worked with several managers who gave the impression that their role was to guard the status quo. They fail to realize that things change and they will end up needing something from my team. This lack of awareness and a general bias for transactional thinking leads to their downfall.
So if you want to be successful, try to say “yes” more often without thinking about what you gain in return. (Of course, there is always the risk of saying “yes” too often. Adam Grant’s Give and Take is a very relevant read on how to say “yes” sustainably)