I'm an E5 at a big tech company. I've been on multiple projects where stakeholders waited until the very end of the projects to say, "That's not what I wanted." What can I do to prevent this from happening? I got feedback that I "need to navigate ambiguity". Does "navigating ambiguity" mean somehow predicting that stakeholders want something besides what they sign off on? If so, how do I develop this skill? This seems to only happen on projects led by E6+ engineers or an M2. I have not had this experience when working with other E5's or more junior engineers. Examples: Misaligned OKRs: At the beginning of the quarter, my M2 told me that it was okay to have a multi-quarter effort, so I planned to do an analysis and roadmap in the first quarter, then execute on improving metrics in subsequent quarters. My M2 signed off on my OKRs for the first quarter. When I provided my deliverables at the end of the quarter, the M2 said, "That's not what I wanted." Then he told me that he wanted metrics moved, even though my OKRs clearly said it was just an analysis & roadmap. I asked 2 mentors (a Director & an M2 - both not in my management chain) for a 3rd party opinion and they both agreed that there was no way to read my OKRs as moving any metrics. I'm confused why the M2 signed off on it and didn't say anything about it in our team's weekly OKR review meetings if that's not what he wanted. He gave me feedback that I need to "navigate ambiguity." When I asked him for concrete, actionable steps to navigate ambiguity, he said, "If you need to ask that, then clearly you don't know how to navigate ambiguity." I'm so confused! Please help! Low-level design missing on a cross-functional project: The DRI (an E6 backend engineer on a different team) kept talking in circles & refused to answer questions whenever the other mobile engineer and I asked about the low-level design for our project. The other mobile engineer tried escalating to our EM, but our EM did not help us. As a last resort, the other mobile engineer and I aligned on the mobile implementations and built that. During end-to-end testing, the DRI said, "That's not what I wanted." He did the same thing to the data scientist. The project was initially scoped for 6 weeks, but ended up taking 2.5 quarters due to all the churn around "late findings". My EM gave me feedback that I need to have a low-level design before starting implementation. Wrong requirements on a cross-functional project: The DRI (E8 web on a different team) provided a requirements doc that was confusing, meandering/disorganized, and hard to follow/understand. An E7 mobile engineer flagged that the doc is not a proper requirements doc at a TSG (Tech Steering Group), but the DRI ignored him and forced me to implement it. I asked for requirements clarification, acceptance criteria, and end-to-end test cases, but he refused to provide any of them. He told me that the requirements doc was all I needed. I escalated this to 3 EMs (my EM, the project's EM, and the DRI's EM) due to my bad experience from the previous project, but none of them helped me. When I asked my EM point-blank how to avoid building the wrong thing, he told me to just make sure I get sign-off on the low-level design in my mobile RFC. I made sure to get sign-off from the DRI before implementation. I also provided TestFlights every 2 weeks for the duration of the project. On the final day that I was allocated to the project, the DRI asked what happens in an error scenario. I said, "Exactly what was documented and signed off in the low-level design of the mobile RFC. Why would it be any different?" Sure enough, he said, "Oh, that's not what I wanted." When I asked why he signed off on the low-level design, he said he missed the flowchart that described the error handling. This happened even though I explicitly tagged him on that flowchart in the Google Doc. So the overall mobile design was about 80% wrong. Turns out his requirements doc said the opposite of what he wanted and that's why the wrong thing got built. The TestFlights had the wrong behavior starting with the initial build, but he missed this as well. His feedback for me: "needs to make sure we build the right thing". How do I avoid this in the future? My EM was unable to provide any advice on how to avoid this in the future. All 3 EMs resigned towards the end of the project.