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.

What would I discuss in the regular weekly 1:1s, in case I run into this problem in the future? I'd treat these as somewhat similar to your manager 1:1s. You're not looking for approval on your work, or for what to do next. Instead: Discuss your interpretation on the project, and what concerns you might have. Invite feedback. Ask for guidance / mentorship where appropriate. Discuss higher-level things beyond the project, things like how the team is operating, or what other priorities each of you have. I'd keep a running 1:1 doc for each of these -- your purpose is to build a longer-term relationship that is bigger than the project.

How to avoid building the wrong thing when navigating ambiguity?

Anonymous User at Taro Community2 years ago

Big Tech

Communication

Senior Engineer

Working With Your Manager

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.

184184 Views

33 Comments

Discussion

(3 comments)

3
Rahul Pandey
•Tech Lead/Manager at Meta, Pinterest, Kosei
2 years ago
What would I discuss in the regular weekly 1:1s, in case I run into this problem in the future?

I'd treat these as somewhat similar to your manager 1:1s. You're not looking for approval on your work, or for what to do next. Instead:

Discuss your interpretation on the project, and what concerns you might have. Invite feedback.

Ask for guidance / mentorship where appropriate.

Discuss higher-level things beyond the project, things like how the team is operating, or what other priorities each of you have.

I'd keep a running 1:1 doc for each of these -- your purpose is to build a longer-term relationship that is bigger than the project.
2
Rahul Pandey
•Tech Lead/Manager at Meta, Pinterest, Kosei
2 years ago
In the last example, it's clearly documented that the E8 engineer was just flat-out wrong, right? They simply weren't careful enough in the earlier sign-offs.

It's unfortunate that all 3 of the EMs you escalated to ended up resigning, that's just bad luck. But you still have a paper trail of what happened here for whoever does end up advocating for you in calibration.

I have two meta-points:

Position yourself to work on projects that don't have as much ambiguity. You probably have a sense now of which projects are prone to having changes (or, perhaps more accurately, which people are prone to causing changes). When you do your half/quarterly planning, orient yourself toward projects where you have a pretty good idea of what's required / don't need approvals from mercurial people.

It sounds like you don't have great relationships with these senior folks, which is not good. You don't want to deliver a completed project despite the others -- you need to do it with their blessing if you want to get promoted. Can you schedule regular weekly 1:1s with the people who have given you headaches in the past to avoid miscommunications?
1
Anonymous User [OP]
•Taro Community
2 years ago
Thanks for the response, Rahul.

Position yourself to work on projects that don't have as much ambiguity.

I was told that I need to learn to navigate ambiguity to get to E6, so that last EM kept putting me on these types of cross-functional projects. I begged that EM to get off the project because I could tell that the E8 did not know how to run projects, but the EM refused to honor that request. Since these are cross-functional projects, I did not know the DRIs prior to joining their projects. However, I could quickly tell that they struggled to communicate requirements and low-level designs (I suspect it's because it wasn't even clear in their own heads what we were building).

How do I position myself for projects? That last EM just assigned me to projects without discussing with me first.

Can you schedule regular weekly 1:1s with the people who have given you headaches in the past to avoid miscommunications?

The M2 resigned and the E8 got laid off (I suspect it's because the latter couldn't execute and caused severe incidents). The E6 backend is still around, but he's in a different org so I don't need to work with him.

What would I discuss in the regular weekly 1:1s, in case I run into this problem in the future? The relationships were fine until I asked for clarity on the requirements and low-level designs. The other mobile engineer on the project just kept their head down to avoid ruffling feathers, but also built the wrong thing. Should I adopt that strategy going forward? Seems like a no-win situation to me, but I'm hoping I'm missing something?

Fortunately, I have a new EM and skip level and they're both fantastic. I've delivered 2 projects successfully under this new leadership. However, I did not work with E6+ engineers on those projects. Did I just have a streak of bad luck? Or was there something I could have done differently? Or is this a normal experience when working with E6+ engineers?