How do I sell the vision behind a large, org-level project?

Making A Strong Case

1. It's much easier to get buy-in on something with momentum - Roadmaps are crammed enough already in a big company like Uber, and introducing something completely new is a big lift. It's way easier getting buy-in on expanding an existing project to have org-level scope, generally something you are working on for your team already. If you are going to create scope, I recommend getting the ball rolling yourself as a sort of "side project" and then getting buy-in after it's clearly showing its value. For the latter, I think Rahul did a great job of this with the internal debug tool he built for Portal. He just sort of built it on his own, saw it be useful to him, and organically spread it to dozens of other engineers. Once he had that momentum, it was easy for him to snowball it to have more and more impact across the org.
2. Back-up your case with data - Generally what happens with bigger, mature companies like Uber is that there's going to be a million projects that can be worked on and it will be hard to sift through the noise. Data is one way orgs sift through that noise and figure out what to prioritize. This is different from startups where there's generally some obvious new features that need to be added, which you don't need data to back up.
3. Understand the values of your org and reference them - Data isn't the only thing that makes orgs tick, and in fact, some orgs (even those at large companies), don't value data too much. I actually came from a background like that - I feel like Instagram was more design-driven than it was metrics-driven (though metrics were still important). What this meant for Instagram is that you needed to convince people that your proposed new feature or whatever was aesthetically beautiful and met Instagram's design guidelines. You should push to understand what the equivalent of Instagram being design-driven is for your org and pitch your ideas while incorporating those principles. This understanding is gained over time, and of course, you can always just ask tenured engineers on your team what they think it is.

Who To Win Over

1. It would be nice to win over the director, but I don't think it's necessary - They should probably be aware of the project, but I've seen a lot of Staff-level projects be done without the engineer behind it getting an explicit director-level stamp of approval themselves.
2. In terms of who to win over, I have the following list - Other senior+ engineers (including a couple Staff engineers), tech leads (will overlap with prior group), managers (of all levels, probably want some senior managers in there)