> it is important to be aware of what projects employees work on (with much less detail)
In my experience, employees get told which project to work on by management, usually through a formal budget / roadmap process which allocates resources to the initiatives being pushed by different stakeholders such as marketing, sales, IT (e.g. for maintenance projects), etc.
So the need is not so much to know what the employees are working on but rather how the projects are going. This is usually handled by steering committees or similar governance bodies, where each successive hierarchical level gets a broader (but necessarily more concise) overview of all the projects they are involved in.
What makes it through these different sieves depends on the company culture and what is considered the "right" level of information. In the worst cases, bad news will be edulcorated, then removed, until every line on the dashboard is green. In more result-driven companies, what makes it to the top is what is susceptible to impact business, so it's going to be the project delays and other bad news. But this process is like the "auto-summarize" feature in Word: a lot of nuance gets lost in the different layers and there's alsways a risk of ending up with nonsense. There's also a lot of mediation being done by middle management.
The closest I've come to direct feedback from the junior employees to the execs at large (>10k FTE) companies is when execs tour the office and come take a look at the grunts in the trenches (this will happen once or twice a year). Inevitably there's an awkward roundtable with a chosen team (usually the one working on the most visible project) where the exec asks each person in the room "what is blocking you and what can I do to help you" while that person's boss and grand-boss glare at them from the back of the room, silently promising retribution to anyone who raises any actual issue.