121–130 of 292 posts
Earlier quoted context omitted.
This reads like "get rid of the old experienced people so I can get promoted".
If your position has no upward mobility juniors will change jobs, likely change companies, once they have the experience and all the effort you spent training them will be wasted.
Im convinced the big tech firms are so overly bloated simply because they do not possess high-quality leadership at the top who are able to clearly distill a vision of where they want their sub-ordinates to go. That's not to say it's easy - its absolutely not. But Apple is living off of Steve Job's visionary prowess and continues to do so.
I never really understood the concept of small teams. Managing a small team really does not provide the scale and benefit that a medium to large team does. Lost bandwidth of manager of said small team or extra salary of the same manager seem like something the company could use in other places. But often such teams in faang come up as a by product of someone’s empire building and that is unfortunate for others involv…
I could even see there being a 1-person team, but their slow tooling and red tape creates the need for extra headcount.
I wonder what Google will do about TVCs now. TLMs usually also had a squad of TVCs.
Earlier quoted context omitted.
TLM role has always sounded like a trap to me, I would never say yes to it personally. I’m sure it’s sold as an expected 50% code, 50% management but everyone I’ve talked to who has been near it says the expectation is more like 80% code 80% management.
TLM roles are a trap, but not in that sense. There's no expectation that you do two jobs at once. It's just a way to ease unsuspecting engineers into management. If you don't suck at management, your team inevitably grows (or you're handed over other teams), and before long, you're managing full-time. Which means that there are three type of people who remain TLMs in the long haul: those who suck at management; those…
Earlier quoted context omitted.
If your position has no upward mobility juniors will change jobs, likely change companies, once they have the experience and all the effort you spent training them will be wasted.
If your position has no authority seniors will change jobs, likely change companies, and all the effort you spent on them will be wasted.
Earlier quoted context omitted.
The original ethos was that you didn't want the company ran by MBAs, so you wanted to build your management team by tapping into talented engineers. Of course, this can backfire in many ways. You end up wasting engineering talent, and as the organization grows, managers spend more time on paper-pushing than on creative work. And there's no shortage of engineers who are just bad at reading, talking to, and managing pe…
> But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given. There are three levers of power in an organization - relationship, expertise and role. Role power is by far the least effective. If you can’t get team buy in for your ideas or they believe you’re an…
To be frank: it sounds nice, but I don't think that's really true. It's the power of "who's going to decide my promotions", "who is going to advocate for my team and get us more resources", "who approves my expenses", "who is going to protect me if something goes wrong", etc.
This doesn't give the manager a pass if their ideas are objectionable, but if they're credible, it's a huge advantage. Small disagreements disappear and people fall in line behind your vision, get excited about it, and make things happen.
In contrast, in an IC role, you can successfully push for initiatives, but you're always working against that dynamic. The merit of your idea aside, folks might simply feel that you're pushing them in a direction that's less likely to get them rewarded or recognized within their reporting chain. That takes extra effort to overcome.
Being very visibly anointed by some VP helps, but that's tapping into the exec's leverage, not yours. And that approach has downsides; I worked with more than one architect / uber-TL person who were universally disliked and feared. The perception was that they showed up to make your life worse by putting extra work on your plate, without having much skin in the game.
This was called the TLM role at google. Technical Lead/Manager. You were expected to code and manage a couple of more junior engineers. It’s part of an effort to have dedicated managers and dedicated engineers instead of hybrid roles. This is being sold as an efficiency win for the sake of the stock price but it’s really just moved a few people around with the TLMs now 100% focused on programming.
TLM role has always sounded like a trap to me, I would never say yes to it personally. I’m sure it’s sold as an expected 50% code, 50% management but everyone I’ve talked to who has been near it says the expectation is more like 80% code 80% management.
Earlier quoted context omitted.
This reads like "get rid of the old experienced people so I can get promoted".
only if you're cynical, google found a much better solution though, make them IC's again and redistribute the junior talent to places they can grow and offer buyouts for anyone who feels like they're not into it anymore.
The 35% reduction refers to the number of managers who oversee fewer than three people, according to a person familiar with the matter. If you oversee 0-2 people, in most cases that’s probably not an efficient ratio. How did Google get so many folks in that position in the first place? And I assume the other 65% take up the slack to fluff their teams? Or what? Leave the other 65% managing 0-2 people?
When I started, I was told that one of the easier ways to get promo at L5 was to become a manager. I don't know how true that was at the time, but I think this could be a consequence of that sort of local optimizing. I think now they don't even allow you to be a manager at L5 unless you're grandfathered in?