Hello, This is a low-quality comment due to circumstances such as SBF having stolen a lot of my funds and my lack of experience at higher levels than senior IC

Hello, This is a low-quality comment due to circumstances such as SBF having stolen a lot of my funds and my lack of experience at higher levels than senior IC in industry (other than startup CEO, I guess). I hope that some people who have worked in management, technical/management, or staff IC roles can give their thoughts soon. In a small team with not many outside commitments, or with outside commitments that do not take up all of our time, we have enjoyed outsized productivity compared to my experience in industry, because we basically know what everyone is good at and we can get the right work to the right people, and because for the most part everyone feels some sense of professional responsibility, steps up, owns the whole problem, and gets things done. This may be rare even among startups though, because you know, even if you don't deliver you still get six figures of VC funding in your checking account. In larger companies, it seems like several things happen: - Many people are hired who basically cannot do some important parts of the process of designing, writing, and deploying software. That's not morally bad or anything! This stuff is hard. They don't teach it in school. Ideally we would provide them with mentorship. Basically no company provides them with mentorship. - Processes are created to attempt to hold these people's hands and ensure software can be delivered according to any schedule at all, which ultimately prevent people who are actually able to ship things from shipping things, since they must instead create 20 page google docs about 100 LOC subcomponents, then go to several meetings about these google docs, then go to meetings with other teams about how to integrate the components between teams (this part is technically superfluous but perf and promo criteria say if you're senior and you want to get promoted instead of PIPed you have to make everything involve other teams even if it doesn't need to) - Commitments are made between teams, to customers, or to management that exceed the capacity of teams to deliver, especially when it is impossible to create a staging-like environment, when problems from production come with truncated stack traces because the document size for elasticsearch is much smaller than the length of a Java stack trace, when none of anybody's time can ever be allocated to fixing these things because that would not deliver any features, when all of one's time must be spent in meetings or updating JIRA tickets or talking to PMs who pretend to be customers but have never talked to a customer in their life, etc. - Because of the difficulty meeting these commitments, more processes must be implemented in an attempt to standardize the output of the team. - Maybe continue by reading The Gervais Principle? - It's possible that this isn't "Agile" and it's just "Micromanagement" but it certainly seems like 99% of people who say they are doing "Agile" are doing this stuff, and at some point one has to give up on linguistic prescriptivism. Aside about Elon Musk and Twitter: It's correct that Twitter was run in a grossly incompetent manner up until now, and that Parag Agrawal is probably the worst tech CEO ever, but a lot of Elon Musk's changes so far have been to destroy the institutional knowledge needed to keep the site running at all by firing the ICs who have that knowledge. This does not seems like a great approach to say the least.