Like, the part about making your co-workers feel like they're bottlenecking you; can't imagine working in an environment where everyone tries that number on everyone else. It's extremely adversarial. Is that really standard management advice? Maybe on Wall Street?
This source is pure gold: techniques to manipulate people into consuming your product - which they otherwise wouldn't be. All so you can make money on poisoning their minds (advertising, which is how you convert views to money). You can easily imagine this came out from a drug cartel boss, I'd expect the best and most ruthless one to operate just like that, with same level of cultishness.
And if that's who Mr Beast is, and that's how he thinks of other people - because believe it or not, viewers are other people too, not some cattle to be milked and slaughtered - then I'm glad I don't watch his videos. Not going to, and I'm happy to pass this document around to dissuade others from viewing his channel.
--
[0] - I mean, that's kind of obvious in anything social media, but rarely do you get it spelled out without any qualms.
I think you're misunderstanding that part. The goal isn't to accuse the coworker. The goal is to explain to the coworker that what they need to do for the project is important to the point where any delays is going to cause a delay for the entire project. This isn't intended to be a negative statement; many projects do rely heavily on certain members getting things in by a particular timeline, and if that isn't communicated and followed up on, projects will fail. The dudebro speech in the document lacks tact, but the underlying principal is sound. The excerpt:
> DO NOT just go to them and say “I need creative, let me know when it’s done” and “I need a thumbnail, let me know when it’s done”. This is what most people do and it’s one of the reasons why we fail so much. I want you to look them in the eyes and tell them they are the bottleneck and take it a step further and explain why they are the bottleneck so you both are on the same page. “Tyler, you are my bottleneck. I have 45 days to make this video happen and I can not begin to work on it until I know what the contents of the video is. I need you to confirm you understand this is important and we need to set a date on when the creative will be done.” Now this person who also has tons of shit going on is aware of how important this discussion is and you guys can prio it accordingly. Now let’s say Tyler and you agree it will be done in 5 days. YOU DON’T GET TO SET A REMINDER FOR 5 DAYS AND NOT TALK TO HIM FOR 5 DAYS! Every single day you must check in on Tyler and make sure he is still on track to hit the target date. I want less excuses in this company. Take ownership and don’t give your project a chance to fail. Dumping your bottleneck on someone and then just walking away until it’s done is lazy and it gives room for error and I want you to have a mindset that God himself couldn’t stop you from making this video on time. Check. In. Daily. Leave. No. Room. For. Error.
See I didn’t read it that way at all. I read that as a statement of a concept I’ve always heard about when coordinating between groups. Effectively “pick a person in the other group to be your liaison and your counterpart and coordinate directly, don’t just throw stuff over the wall and hope someone picks it up”. It’s the same basic psychological concept as “in an emergency situation pick one person in the crowd, point them out and tell them personally to go call 911”. Diffusion of responsibility means people will delay or stuff will get dropped. To make things happen you have to make sure things are assigned. Surely this isn’t particularly surprising or controversial right? It’s why large teams often appoint “interrupt” workers who are appointed to specifically answer out of band requests coming in. It’s why you have an on call rotation instead of just paging the entire company if something goes down. It’s why agile appoints a “scrum master” whose singular mission is to clear up blocking issues for the team. It’s why if you don’t assign people to work on maintenance, maintenance won’t get done.
I read that part of the document as saying “if you’re in charge of producing a video due in 45 days, don’t just send a general request for someone to make a script to the writing department, pick a person and get on the same page about what needs to be done and when”
In an emergency situation you single out random person precisely because there are no set processes who should be doing that, so you create responsibility impromptu.
In any half-functional organization work item with a deadline accepted by someone means THEY take responsibility to deliver in time and communicate any blockers. Having to constantly prod counterparty in another team signals totally broken and/or inexistent project management. It fits a lean startup where everyone is responsible for everything and everything is a fire you distinguish right there and move on. It does not fit organization where exponential growth of communication channels means communication becomes the bottleneck.
That's what the document was about though. The audience of the document is quite clearly people who will be given the responsibility to deliver a video or product. It's quite literally communicating to them the exact concept you're pointing out here, that you need to establish clear roles and responsibilities. And what's being conveyed is that there isn't a single "one size fits all" responsibility chain. You can't just throw a request over the wall and assume and hope someone on the other side of that wall will come through for you. Most of this document is quite clearly "project management 101". If you're hiring people for a business that is largely centered around having multiple one shot projects in flight at any given time, "project management 101" is exactly the sort of document you want to be handing to new hires. It might be obvious to you, but spend time in any large organization and you quickly come across people for whom taking ownership and responsibility for something and what that entails isn't obvious. Heck I see this on software development teams all the time, where PR requests get thrown "over the wall" at the whole team and the turn around time is delayed as people assume someone else will get to it before they will and forget about it. Most teams I've worked on eventually land on some sort of interrupt or direct assignment system for PRs for exactly this reason, because you need to assign clear responsibility in order to get results turned around faster.