I've found when juniors lead a project, the biggest thing missing from their decision making is rationale. Even when provide an opinion that does have a rationale, but they fail to communicate and document said rationale.
Rationale (or justification) is crucial in the success of a project, and software engineering in general. You can't make decisions based on vibes. In an ideal world, the rationale remains constant, even as the derived decision may change due to new requirements, evidence, facts, etc.
When rationale isn't given, a project can easily flip flop from one direction to the other, or get stuck in a spiral. A junior will ask for feedback, and they'll take feedback or questions as a new requirements or decisions, changing the decision/plan without much thought. A suggestion from a senior is never a demand, it's a jumping off point. Ideas should be constructively debated, and being as objective as possible (while looking at the rationale), you come to the best conclusion. If a different senior engineer has a different suggestion or opinion, the plan can change again, as rationale is discarded, and opinions are ruling supreme.
Note: I've found to help with the above to keep suggestions to a minimum, and instead tease out the reasoning with more vague questions. Similar to [[20231006045323-five-whys]].
Similarly, the decision can actually miss addressing the root problem or requirements, as the rationale isn't tied to it. This risks creating a suboptimal solution, and further slowing down work as iterations will be guided by being tied to a subjective initial experience, rather than a more objective rationale. This quickly compounds and can lead to a negative spiral or 'rabbit hole', where you're trying to solve problems in a particular way (or given particular arbitrary restrictions), rather than stepping back to think about how this solves the original problem.
When this is the case, often the best ideas come when someone looks at things with fresh eyes and thinks of an entirely new solution, questioning everything that has been done prior. You should have reasons for doing the proposed solution, and reasons for not doing the alternative solutions.
You should always have a good answer for 'why'. A large part of this kind of thinking is similar to [[rootcauseanalysis]], where stepping back to truly understand the problem is so important.
Going further, ideally the rationale is tied to business value, but that's starting to think more senior [[20220509010256-engineers-business-value]].
[[20220916120725-documenting-decisions]]
[[career]] [[decisions]] [[documentation]] [[engineering]] [[product]] [[rootcauseanalysis]]