Dealing with Ambiguity is one of the core competencies Microsoft tests for in their interviews. It is the ability to approach complex, ambiguous problems in a systematic manner, and make sustained forward progress without getting lost in tangents.
Today I’d like to drill a little bit into this competency, explaining how it plays out in real-world scenarios, and a couple approaches to succeeding in highly ambiguous situations.
Moreover, I would like to show that ambiguity permeates every aspect of software engineering, and dealing with it effectively is the key component of career success.
The Ambiguity Bullseye
In a previous post, The Career Stage Bullseye, I explored the chart on the left as a progression of scope, but another useful way to look at it is as a progression of ambiguity.
In other words, a Junior starts out dealing only with the ambiguity inherent in the tech they’re using (ideally not much of one) and anything the PM left out in describing the feature they’re working on.
A Principal, in comparison, is dealing less with specific tasks, and more with business problems. It’s their job to translate the ambiguity of a business problem, such as “how do we achieve 5 9's?” into concrete tasks the Juniors and SDE2s can then execute on.
The Unified Theory of Ambiguity
How do you approach ambiguity in your work? Methodically.
Dealing with ambiguity is simple, as long as you work out a method for yourself. Different people will gravitate toward different methods, but in general, they will all follow the same general path:
The Top-Down approach
Also known as the Snowflake method. Break the task into major components, then break each component into sub-components, and so on, until you get to the level of task you intrinsically feel comfortable handling. 2-day granularity works well — i.e. tasks you can realistically accomplish in 2 days. That way you will have a constant sense of progress as you move through the overall task.
The key here is to go incrementally. Figure out the major mile markers so you can celebrate when you get there. Then, as you discover something you didn’t know you didn’t know along the way, you can reference back to your mile markers to figure out how to adjust course.
The Concrete approach
In this approach, you chip away at parts of the ambiguity making you most uncomfortable by coming up with something concrete. That concrete thing becomes an anchor for further discussion, a foundation to build from. My colleague at Adobe put this very well:
Think about the difficulties in describing software that doesn’t exist and people’s ability to take issue with specifics once there is something (barely) working. People are better at talking about what’s wrong with what exists than they are about what could exist. For this reason, show the direction and perhaps a broken prototype for a simple/understandable part of the ambiguous problem AS SOON AS POSSIBLE. Getting (re)direction before too much resource has been spent is of paramount importance. Before there was Agile and we were asked to use Waterfall (which was awful/unhelpful), a VP I worked for called this process “ugly early.” — Kurt Heston
Eventually it’s still good to combine this approach with the top-down one; just don’t let yourself get too lost in breaking down the tasks to exhaustion before prototyping.
Example 1: The absent manager (Junior-level)
You’re a junior dev two weeks into your first job, when your manager Jane comes to you with a problem. The product has been plagued with stupid regressions, customers are getting pissy, and upper management wants something done. Jane says the team is letting obvious issues slip through to QA, and wants you to figure out some way to address this. In discussing this with her, you suggest static code analysis. Jane thinks that’s a great idea, and asks you to integrate the tool into the CI/CD system.
You nod enthusiastically. You want to make a good impression on Jane, and on the rest of your team. You’re not about to let on how overwhelmed you’re feeling. Jane asks you if you can be finished in two weeks. Well, this was your idea. Time to put your money where your mouth is, right? You agree, burying your head in your hands when she finally leaves you alone.
What are you going to do? You’ve used the Clang static analyzer in college, but you have no idea if that’s the best tool for the job, or what “integrate it” actually means. You haven’t had to deal with CI/CD before. You don’t even know what team to engage with, or how to engage.
In short, you’re terrified you’ve committed to something you can’t possibly deliver.
A good manager has a feel for how much ambiguity an individual can handle. They’ll grow that skill gradually, without overwhelming their report. Jane isn’t doing a good job by just dumping the task on your shoulders and walking away.
The most likely outcome is you’re going to try powering through the problem, working enormous overtime and ticking off your colleagues as you become increasingly stressed and snappy. If you’re very bright you might cobble something together in the agreed-upon timeframe, but your solution is unlikely to be maintainable in the long term.
Situational Leadership will tell you the manager’s leadership style and the report’s leadership needs are misaligned. That’s fatal in any domain, but especially fatal when it happens in the domain of ambiguity.
If you’re a manager, learn about Situational Leadership. Your reports need different things from you, depending on their overall level of competence, and their skill in the specific domain you’re tasking them with. Learning to recognize this will make you far more effective at ensuring your reports have the knowledge and the confidence to succeed.
Complex problem: integrating a static code analysis tool into the CI/CD pipeline.
A quick breakdown:
- Learn about what code analysis tools are out there.
- Prototype (locally) a couple leading contenders. Select the best one.
- Learn about your team’s CI/CD pipeline. What does it take to integrate a new tool?
- Integrate the tool from step 2 into the pipeline.
Notice none of these dictate how to go about executing the task, just what to do. These are your mile markers — your path through the task. As you learn more at each stage, you can fit it within the context of this path so you don’t get lost in details that may not matter.
The next step is pretty simple: you break down just step 1 into smaller chunks. You execute on those chunks. You apply what you learned to steps 2–4. Rinse and repeat. Profit.
Example 2: The Failed Initiative (Senior-level)
You are in charge of a team working on a key company initiative, passed straight down from the CEO. The startup you’re in prides itself on valuing Ownership — “We hand you business problems, not individual tasks,” the management often says. That, combined with the “Got Your Back” value, is what attracted you to the position in the first place.
One day your VP of Product comes to you with a challenge: they need your team to increase the MAU of your feature by 20% over the next quarter. Ownership and all, you’re welcome to collaborate with your PM in whatever way you see fit, and present your approach to the senior leadership in a week.
Feeling empowered, you work with the team, presenting your proposal to the CEO and upper leadership at the end of the week.
The presentation is a disaster.
The CEO goes off on you and the team, saying you don’t understand what the company is trying to accomplish, and that your solution is crap. He then proposes an entirely different course of action that doesn’t make sense within the constraints previously provided.
You and the team come away from the meeting shell-shocked. You had exercised initiative, creativity, and ownership in coming up with the ideas you had. And were shot down.
What happens next?
The team becomes a collection of coding monkeys. (That’s a term I use for when an individual exhibits no initiative of their own, just blindly executing whatever tasks are set before them.) They listlessly work on the solution the CEO proposed, going to him to clarify every little ambiguity in the task.
As you can imagine, that isn’t terribly scalable. You miss your deadlines.
The team is disbanded 2 months later.
You get the blame for the poor leadership.
This is another example of an ambiguity fail, except now you have to contend not only with task-level ambiguity, but with relationship ambiguity too. Who are the stakeholders? What opinions do they hold you weren’t privy to? Knowing this becomes increasingly critical as you advance to Senior and Principal. Otherwise you’re like a ship captain, trying to bring your ship through a tricky channel into port, blindfolded.
The issue here had more to do with the personalities involved than with the task itself. You made assumptions about the requirements and about the stakeholders involved. At the end of the day, that’s what sunk you.
So pause for a second, and analyze the ambiguity inherent in the assignment. Do you really understand the requirements? Who are the stakeholders? What do they think of the work? Engaging them early helps resolve the stakeholder ambiguity, giving you a much more comfortable path ahead.
Could you have avoided the disaster? You betcha, if you’d involved the CEO earlier. Could the CEO have avoided the disaster? You betcha, if he’d paused to analyze the level of ambiguity he was passing down with his original task versus the level of ambiguity you had been comfortable handling.
But since you can’t control what the CEO does, approach the problem by assuming hidden rocks, and doing your best to expose them before you get too far down the execution path.
The Three Types of Ambiguity
Tech. Business Problems. People.
Ambiguity can appear from different directions, depending on your level of seniority. As a junior developer, you start from the simplest: how to approach a complex, ambiguous task. As you grow, the size and complexity of these tasks will increase until you’re not dealing so much with specific tasks as with general business problems. Ambiguity in relationships begins to play more and more of a role, where it isn’t even the task so much that you need to wrap your head around, as the different stakeholders you must appease during its execution.
So, when approaching the task, thinking through the following three questions may help you identify areas of ambiguity that are likely to come a-knocking if you ignore them:
- What business problem is the task trying to solve?
- What constraints are placed on the work, and are they necessary constraints?
- Who are the stakeholders, and are their requirements well-understood?
Dealing with Ambiguity effectively is perhaps the most useful skill you can develop as an employee. It will allow you to thrive in challenging situations, detect and prevent disasters before they happen, and progress quickly up the career ladder.
So how do you detect that you’re about to hit the ambiguity iceberg?
Listen to your own gut. Are you feeling uncomfortable? Unsure what to do next? Stressed?
Pause. Take a breath. Try to figure out what is ambiguous about the work you’re doing. What questions are inherent to the task that you’re not asking? What people are involved that you’re not talking to?
Chart yourself a path through the task. What does completion look like? What does the midpoint look like? Then, when you get lost in the details of the task, reference back to this path.
It might just save your life.
There you go, and necessary disclaimers
Thanks to Kurt Heston again for reviewing my scribblings.
As usual, the views above are my own, and aren’t meant to represent Adobe or Microsoft. Feel free to hit me up on Twitter @partnerinflight, comment below, or shoot me an email at email@example.com.
Other entries in this series:
Like what you read? Want to read more? Here’s the complete list of articles so far (in suggested order of reading):