Live data from Hacker News

Meta Layoffs

brandur.org

261–270 of 282 posts

Re: Meta Layoffs

#261

Earlier quoted context omitted.

A couple of well-known ones are Automattic (WordPress.com) and Gitlab. Gitlab even has its employee handbook publicly available https://about.gitlab.com/handbook/

I have no problem admitting GitLab is doing a better job than we are, but they also have orders of magnitude more investment and have been doing it since their inception vs. since the pandemic. Any examples from a) non-unicorns, b) who have successfully transitioned to remote work?

That last example is the tough one. IMHO most companies that tried to transition to remote work during the pandemic did so half-heartedly and then blamed the failure on remote work instead of their own decisions. It'd be like deciding to open an office in another country and then not bothering to learn the culture, language, work habits, etc. Or opening an office in another city that was completely inadequate compared to your other offices and then blaming the new city.

To make remote work function you really need to follow a model like GitLab has provided with their handbook. You need to document everything and use practices that favor asynchronous work. You need to adjust your training, benefits, communications tools, management techniques, etc. You can't just "allow" half of your people to work remotely and expect things to work out. In fact, the hybrid model is often said to be the worst of all worlds as the people who work in the office often ignore the remote workers and make everyone's job more difficult.

Re: Meta Layoffs

#262
post #261

Earlier quoted context omitted.

I have no problem admitting GitLab is doing a better job than we are, but they also have orders of magnitude more investment and have been doing it since their inception vs. since the pandemic. Any examples from a) non-unicorns, b) who have successfully transitioned to remote work?

That last example is the tough one. IMHO most companies that tried to transition to remote work during the pandemic did so half-heartedly and then blamed the failure on remote work instead of their own decisions. It'd be like deciding to open an office in another country and then not bothering to learn the culture, language, work habits, etc. Or opening an office in another city that was completely inadequate compare…

> To make remote work function you really need to follow a model like GitLab has provided with their handbook.

Right, and this requires resources (time and money) that VC hyperscalers maybe can afford to blow but the 8yo+ 50-100 person company whose HR "department" consists of maybe three people and whose non-technical sides don't understand the need to change everything because they don't need such intensive education, is going to grind to a halt for months if you try to roll this out.

I don't "blame remote work" or anything, but it seems practically impossible to steer a mid-sized ship in this direction - big enough you've got fiefdoms and you'll never get 100% buy-in from the comfortable ones without a CEO going in and knocking a few heads, small enough you can't put together a task force specifically to eat the shit to manage the transition. So either we go back to the office a significant amount of the time, or we slowly die.

Re: Meta Layoffs

#263
post #246
post #212

Earlier quoted context omitted.

> The company is just unstable Minimum net income of $10 billion a year for the past 7 years is now apparently unstable

$10 billion annually sounds pretty good until you consider that they've spent close to $40b on a Second Life clone. Blackberry profits were looking good in 2009 as well, it wasn't until 2012 that the wheels came off.

IBM has spent billions on Watson with very little return. I don't think anyone is calling IBM unstable.

Re: Meta Layoffs

#265
post #236

Earlier quoted context omitted.

> But after a period of time, I got it. Sure it took longer, but I got there. And then you leave the company. So it's not really at all in the best interest of the company for you to take longer to get up to speed. Average tenure of a SWE is still low across the entire market, at Meta it's probably even lower given who they hire for.

> And then you leave the company. So it's not really at all in the best interest of the company for you to take longer to get up to speed. Maybe it would be in their interest to pay more, so you don't leave. If average tenure of a SWE is low, they are probably switching jobs for better pay. In that case, paying them more to stay makes more sense than having to pay to get a cheaper but unproductive new hire up to spee…

> Maybe it would be in their interest to pay more, so you don't leave.

I think that would have limited effectiveness. In my experience, people usually don't leave because of pay reasons, and more pay wouldn't get most of them to stay.

They usually leave because they want to learn something new, or work on something different, or there are things about their working conditions or company that makes them very unhappy.

Offering more money would keep some of them around, sure, but not most of them. And those that it keeps around will still have those problems, but they'll no longer be able to address them. That can't be good for them or for the company they work for.

Re: Meta Layoffs

#266
post #109

Earlier quoted context omitted.

> mob programming That sounds... horrendous. I really enjoy "pairing" when chasing down bugs, but doing that when trying to write new features would be nigh-on impossible.

I'm thinking of it more like team practice in a sport - it sounds like a way to get some team cohesion and pass around some knowledge in a group setting. You aren't going to be doing this all the time but it doesn't sound like the worse thing to do for an hour - people aren't exactly going to lunch together when remote.

For an hour, sure. But it sounds like the GP was saying this is how they work 9-5.

Re: Meta Layoffs

#267
post #82

Earlier quoted context omitted.

Manager in my parlance is heavily working on growing me and the others in my team as well as managing or product portfolio. As others said that sounds like a director. Who runs the day to day off the team. Or do you only sync once a week?

i guess its situational. I'm not clear what "the day to day off the team" actually means in concrete terms. I dont mean it in a dismissive way, genuinely curious You need to work with someone or get feedback, then you go talk to the relevant person..? If you really need you could go run something by the manager. Again i dont really see that being a full time daily job (for just one team). Just a few hours here and th…

Who's running the sprints, dealing with Hr issues, doing evaluations, sorting out interpersonal issues, talking with product, etc. Or is someone on the team like the team lead doing all of that, or a TPM, project manager, etc.

Who makes the long term tradeoff decisions on staffing, maintenance, product priorities, etc.

That's the day to day of a team.

Re: Meta Layoffs

#268

> > Our early analysis of performance data suggests that engineers who either joined Meta in-person and then transferred to remote or remained in-person performed better on average than people who joined remotely. This analysis also shows that engineers earlier in their career perform better on average when they work in-person with teammates at least three days a week. This requires further study, but our hypothesis…

[deleted]

Re: Meta Layoffs

#269
post #109

Earlier quoted context omitted.

I'm thinking of it more like team practice in a sport - it sounds like a way to get some team cohesion and pass around some knowledge in a group setting. You aren't going to be doing this all the time but it doesn't sound like the worse thing to do for an hour - people aren't exactly going to lunch together when remote.

For an hour, sure. But it sounds like the GP was saying this is how they work 9-5.

Ohhhh. Interesting.

Re: Meta Layoffs

#270
post #13

I was a PM at Meta from 2016-2022. I work at a startup now and have to write detailed specs and deal with lots of small details —- something I was discouraged from doing as I rose in rank at Meta and scarcely did after the first year. Looking back, I don’t even remember what it was that I did if not that —- lots of strategy docs, aligning other teams, but no specs. I am having to unlearn a lot of bad attitudes and ha…

Are you excited to be writing lots of detailed specs? Especially in a startup, that seems terrible to me. When I've done startups, one of the best things for me about them was close collaboration with the product/design side of the house. Detailed specs would have slowed that down significantly for us.

Amazing. Love PMs who can dive into details and clarify edge cases.

That’s half the battle of writing code.

At our startup, the philosophy is to “first write code without writing code”.

This gives clarity of problem and proposed solution to weed out edge cases, before going too deep into implementation phase.

Post reply on HN