11–20 of 613 posts
Basically, turn it into a marathon not a sprint.
Most promotions I've seen are when someone has a huge amount of tribal knowledge about some system and the company cannot afford to have them leave. So they get promoted. This is even within FAANG, where this narrative about impact or 10x developers is common. Not saying promotions dont happen for those reasons, just that huge systems that few people understand lead to promotions for those who do understand them
The other perverse incentive is that you will end up with engineers trying to extract as much value from other engineers as possible, because it becomes part of leveling up: how much you make other people deliver. Even as an IC. The other problem is that it becomes this game where nobody dares giving bad feedback to one another, because you know they could retaliate which could damage your chances to get a promotion.…
Were strict hierarchies really that bad? It seems that just about anything else devolves into an ontological mess of Byzantine proportions. At one stage in my career I was reporting to 4 different bosses in this weird interleaved hypercube topology. I spent most of my time giving status updates
There's a limit I guess, but sometimes having multiple people to report to can lead to checks and balances.
The other perverse incentive is that you will end up with engineers trying to extract as much value from other engineers as possible, because it becomes part of leveling up: how much you make other people deliver. Even as an IC. The other problem is that it becomes this game where nobody dares giving bad feedback to one another, because you know they could retaliate which could damage your chances to get a promotion.…
Were strict hierarchies really that bad? It seems that just about anything else devolves into an ontological mess of Byzantine proportions. At one stage in my career I was reporting to 4 different bosses in this weird interleaved hypercube topology. I spent most of my time giving status updates
Recently we had a chat with a lead from another team. Their product has a lot of similarities with ours so we sync up every now and then to bounce ideas off each other. They recently release a big change that we thought didn't provide much value, so we asked him about it.
His candid answer was "you know how it works, we have a service running in production, so we need to make changes". This sounds simple, but the implications are deep. Unlike individual engineers, moving entire teams around is difficult. If you have a team, you need to "justify" their existence. Is not enough to keep the lights on or slowly polish the product, you need grand roadmaps to keep yourself busy the next year or two. Ideally you want to justify that you need extra headcount to keep the product expanding.
All founders/execs/early employees are easily aligned on compabt success. But how do you align incentive of later hires?
In order to reduce time spent on perf, you'd have to rely on a few people who knows an employee's work instead of a larger peer group and committee. The person entrusted with this decision (typically the manager) now wields tremendous amount of power over others. This leads to a different set of problems, like "B player hires C player", yes-man culture, ICs spending effort brown nosing instead of creating value, etc.
Building a culture is all about incentives, it's easy to identify and reward user/company impact when the team is small. But as number grows, it becomes harder to do that, and the declared core values gets ignored as the reward system departs from that.
The other perverse incentive is that you will end up with engineers trying to extract as much value from other engineers as possible, because it becomes part of leveling up: how much you make other people deliver. Even as an IC. The other problem is that it becomes this game where nobody dares giving bad feedback to one another, because you know they could retaliate which could damage your chances to get a promotion.…
It's complaining to managers/directors instead of talking to the person themselves (the recipient wont get to read your feedback for a couple months after). Even if you want to talk to a manager about some performance concerns, you should do that directly, instead of putting it in a record that sticks around for a persons whole employment
It's a bureaucracy game, and people who give bad feedback don't know how to play.
(I'm not endorsing the system at all, just rejecting the idea of it being retaliation-based. Anybody giving bad feedback doesn't understand what is going on)
The other perverse incentive is that you will end up with engineers trying to extract as much value from other engineers as possible, because it becomes part of leveling up: how much you make other people deliver. Even as an IC. The other problem is that it becomes this game where nobody dares giving bad feedback to one another, because you know they could retaliate which could damage your chances to get a promotion.…
Raising up and increasing the productivity of your peers sounds like a good thing. I think I'm missing how this is a bad outcome due to a perverse incentive. Are you saying the value extracted from peers is not real value or that the focus on your raising your peers detracts from more important business goals?
I work like 20 hours a week at my job, I almost quit because it's extremely boring and dysfunctional, but then I realized I can just disengage and enjoy my extra free time instead of pushing to exceed expectations. And I still get paid the same.