How does bottom-top works in big tech?

I highly recommend checking out this playlist (it's full of examples and tactics): [Taro Top 10] How To Create Scope As An Engineer

How does it happen?

It's generally through these steps (oversimplified):

1. You identify a problem that's worth solving
2. You come up with a solution to the problem
3. You get buy-in for the solution and expand the effort across multiple engineers

These steps are oversimplified because:

1. You don't necessarily need to identify the problem - That's often the easy point. A lot of good instances of creating scope are engineers solving problems that were previously thought to be impossible/not worth solving (check out my oncall revamp case study from the Top 10 playlist for an example of that).
2. There is often a very important "hidden" step between #2 and #3 - You bootstrap an initial solution on your own to show the feasibility and prove the value of the solution. Rahul's debugging internal tool (also in the Top 10 playlist) is a stellar example of this. It is much easier to convince people to hop onto a rocket ship that's already lifted off compared to one that's grounded on the tarmac and waiting for fuel.

Is there any management involved here?

In order to get full credit, you generally should involve management, at least in terms of making them aware of what you're doing (visibility is very important for growth).

How much you need management will vary from company to company as you alluded too. Some companies are slow, bureaucratic messes where you need permission to breathe (I recommend not working for those) and others give much more power to ICs (e.g. Meta and hyper-growth startups).

Lastly - For future reference, the terms are "bottom up" and "top down" culture from my experience. But I feel like your inverted terms are more intuitive.

I went 2/2 for projects that better defined the direction my team and made it onto my org's 2024 roadmap. Both projects are E5+ scope (imo) and require a significant time investment. The process was really simple:

• I complained a bunch to my manager and my skip manager
• I sent out some 1 pagers proposals once I knew I had rough manager buy-in
• Months later, I saw both projects on my org's 2024 roadmap

While the process is simple, getting to that point was not.

• I have the longest tenure at Robinhood out of anyone in my org. That meant the initial baseline of implicit trust new teammates would have in me is higher.
• I'm senior level. Similar to tenure, that also increased the baseline of implicit trust people would initially have for me.
• I have strong domain knowledge: I at least roughly know how every product my org owns works. This meant that I was more capable of working backwards from product/business gaps. I knew the direction we wanted to go as an org, but also felt that there were gaps around how we were to move in that direction. So from my view, I just simply tried to fill those gaps (and didn't optimize for flashy cool kid points by being "revolutionary").
• I approached things incrementally and made sure I put the least amount of effort needed to move my suggestions forwards. A common trap more junior enginers fall into (my younger self included) is assuming there's a positive correlation between effort put in and the resulting impact. Unfortunately, life doesn't work that way: there's a certain point in which the proposal gets insta-rejected by everyone because it's taking too much of their time. My process was strategic around making sure that if a proposal got rejected, I would only lose at most a day of work. Since the time loss is low, I could easily just go back to whatever "normal" work management wants me to do and I didn't have to worry about getting dinged on perf for wasting everyone's time