Even more so when that person later loudly proclaims that they never made such a request, even when provided with written proof.
I can of course not say whether the people currently working at Twitter did warn that the recent measures could have such major side effects, but I would not be surprised in the slightest, considering their leadership's mode of operation.
Even as someone who very much detests what Twitter has become over the last few months and in fact did not like Twitter before the acquisition, partly due to short format making nuance impossible, but mostly for the effect Tweets easy embeddability had on reporting (3 Tweets from random people should not serve as the main basis for an article in my opinion), I must say, I feel very sorry for the people forced to work at that company under that management.
I worked in the games industry for a while, and came to understand how they could spend so much money and so much time, and yet release a game where even basic functionality was broken. It's exactly this sort of extreme schedule pressure that, ironically, makes a huge morass where changing one thing breaks 10 other things, so progress grinds to a halt.
Are you saying the engineers who are now at Twitter don’t have the right skills?
The tweet reads: "Twitter is firing off about 10 requests a second to itself to try and fetch content that never arrives because Elon's latest genius innovation is to block people from being able to read Twitter without logging in."
Does that strike you as complex? I mean, surely they had the context (need to log in) because it was all over the news
Twitter serves their service to the entire world, with multiple layers of systems working in conjunction in order to make things work smoothly. A new engineer that has not been working on it for no more than a couple months would likely be unaware of how the different systems communicate and interact. A change like this will have have a lot of unintended consequences, and not having a senior engineer with lots of context leading the change will undoubtedly cause these kinds of issues.
Having a senior engineer with a lot of context is worthless if the work environment does not promote open communication. You don't want to be the senior engineer or leader who shows "poor judgement" by opposing the mercurial owner "for no reason" if you're overridden and the feature launch succeeds without a glitch; no one gets fired for implementing a request that came straight from the top.
This is why non-rushed, scaled roll-outs are essential for large system: had they tried this on 1% / 5% / 10% of random traffic first, they could have caught this. Yet again, if the directive to roll it out to production came from the very top, you set that gate to 100% immediately.