The ambiguity tolerance threshold
"Which path do you intend to take, Nell?" said the Constable, sounding very interested. "Conformity or rebellion?" "Neither one. Both ways are simple-minded - they are only for people who cannot cope with contradiction and ambiguity."
Neal Stephenson, The Diamond Age
We were in the middle of an incident and it looked like we were going to have to do the worst: ask customers to take action on our behalf. This is a worst-case scenario for several reasons: it means you have to draw your customer's attention to the issue at the same time you're indicating you cannot fix it themselves without their help. Generally, customers prefer to pay you so they don't have to think about these things. We had communication ready to go and were just about it to send it out. Just before we pushed the button, one of our senior engineers took a second look, stopped us all, rewrote the entire thing, then sent it out.
The changes were subtle, but powerful. The cause was better described and called attention to the fact that while this was our problem to deal with, it wasn't prompted by our code, and we had done everything possible to avoid the customer having to do anything at all. The action was clear, and the engineer had added some screenshots showing precisely what the customer would see and how they'd know they had done something correctly. And the new communication provided a clear path to get in touch with a human in a way that would bypass the standard support flow. Customers were happy, and we got zero complaints about the required action.
My core "metric" for moving up in an engineering career is an individual's Ambiguity Tolerance Threshold. This metric measures how much "stuff" a person needs to have completely spelled out for them before they can get moving on an initiative. A person with a low Ambiguity Tolerance Threshold needs to have every little piece nailed down before they can proceed, and a person with a high Threshold can be given a general direction and be trusted to still be successful.
Consider a simple leveling guide:
- L1: Your basic college hire. Chances are this person will need active coaching on simple tasks before they can get moving.
- L2: A base level engineer. This person can get through most tasks, but a larger project might be beyond them.
- L3: A senior engineer. Can get through an average project with a reasonable set of subtasks without much fuss.
- L4: A staff engineer. A recognized leader in the organization who is entrusted with the most complex of initiatives.
- L5: A principal engineer. A person involved in things that ripple through organizations, impacting many developers. The kind of person whose work is regularly published as examples of best practices.
Projects carry more ambiguity than tasks. With a task, you're looking at a basic to-do, something that's reasonably easy to estimate time on and the definition of done is crystal clear. With a project, where there are multiple tasks and potentially multiple people involved, there are more opportunities for misinterpretation and miscommunication and more chances for those things to throw off the project. A project with multiple engineers carries the risk that one engineer might have a power outage and can't finish work. Or perhaps a new product manager doesn't know how to properly think through scope with the team. So much can go wrong when there are multiple moving parts.
At the director level, I see lots of questions like "should we even do this at all?" or "should Project X come before Project Y?" or "should we move Person A from Team B to Team C?" And those kinds of questions carry tons of ambiguity. Project X might be easier than Project Y, but Project Y might be more important for an at-risk customer. Person A might be a better skills fit on Team C, but they don't get along with that manager. The decisions become less clear. It can be tempting to think about logical, evidence-based decision frameworks - so which one of those frameworks should we pick?
Entire textbooks have been written about decision-making in areas of high ambiguity, and I won't try to re-hash those here. That's not the point. The point is that ambiguity exists, and as you level up in your career, it becomes increasingly critical to not only cope with that ambiguity but turn that chaos into order. Someone has to be figuring out the company re-org. Someone has to be figuring out the project prioritization, and someone has to deal with the re-prioritization conversation with the CEO. Each time more people will be affected, we're increasing ambiguity.
I have yet to see a highly successful person without a high Ambiguity Tolerance Threshold. It doesn't always manifest in the same way. I've seen product-oriented people be terrible at managing their teams but comfortably step into the ambiguity of finding product-market fit. I've seen staff engineers balk at talking to customers but quietly coach entire teams through the complex project to get those customers what they need. These people can take a complex, ambiguous situation and figure out how to turn it into something sound and easy to understand. They don't balk at the ambiguity itself. They naturally understand that the ambiguity is inherent and it needs to be dealt with, and if someone's going to deal with it, then why not them?