The successful projects I've worked on, the technical staff have been given autonomy, responsibility and full insight into the problem space. This requires managers putting a lot of trust in the engineers, but it works.

Large projects I've worked on failed simply because nobody wanted the solution in the first place.

In government I've seen many millions spent on projects that were either forgotten about or the politician that requested it lost office.

You’ll notice that more senior engineers are often much better at giving useful review comments, and they will do it faster than you, thats just a skill that seems to come with experience reading other peoples code(or your own code you wrote two years prior). It can’t be taught, only practiced, same goes for reading other types of technical/academic works.

Not GP, but the general idea is the skill to take a piece of code and understand what it does by reading the code itself (probably in an IDE that can help navigate it meaningfully), not relying on docs or explanations or anything else. Surprisingly few people are comfortable in doing this, and yet it's very common in any large software project that lots of parts of the code are undocumented and no one remembers the details of how they were written.