In my eyes, this is not TOO much different than the kind of radical reorg that might take place at a company like Twitter anyway (although ofc I've never seen it first-hand), just weird that it's playing out entirely in public.
That said, I think the public strategy is potentially interesting, as the engineers who remain at the company will probably feel like they're a part of a very exciting moment, will feel more aligned with leadership, etc.
Exactly. It seems that EM overpaid for a dud, and now wants to compensate any way possible.
But could he please let us know what percentage of users is bots?
Promoting engineers into managers loses you a good engineer and creates a poor (and unhappy) manager.
If the person wants to be a manager, great! But otherwise, don't do it.
The best managers I had were helping me debug things when I get stuck. When there's a seg fault in a multithreaded program, or the project just doesn't seem to go anywhere for some time because I don't really know what to do or I'm going in a bad direction with my local improvements, somebody more mature than me / person with more experience just knows what to do.
Raise your hand if you're a "Senior Software Engineer" or "Staff Software Engineer" and there is no other next level for your career to go besides management. It's a common problem.
Perhaps it's different when you have the resources to attract top-tier talent.
1. Manager needs to be the most knowledgeable, and steer the team with the correct decisions.
2. Manager cannot be close to the code due to other responsibilities, and so needs to trust their team for the technical things.
Personally I have the following opinion: a lot of companies can follow 1, since once you know how to flip burgers, you know. The smarter people rise and can have more influence. However in knowledge work, the people most knowledgeable are close to the code. When you move up, you will know less and less (code evolves quickly).
I'm 20 years in the software development business, and I only work for managers that understand they don't know, and trust & empower their team to take the right technical decisions. It really surprises me that some developers here think differently.
Where before there were teams of QA people, project managers, IT administrators and support personnel, it has all been subsumed into the various "agile" DevOps methodologies. I now hear devs complain that they have to do everything.
Promoting devs to do all the things that devs don't do is not the solution. It shows a deep lack of awareness of all the boring things (to devs anyway) that have to happen so that devs can get on with writing code.
This is not to say that all managers are great; there are many bad or mediocre managers, just as there are many bad or mediocre devs. They are different skill sets though.