Ambiguity Can Be Your Friend

Six months ago, I took on a new role at Microsoft.  I haven't written a blog entry in a while because of all the work I was doing in my new role.  I spent 10 weeks as an individual contributor before building a new team and it was a really fascinating time for me as I worked to understand the project that was assigned to me.  Was the project well-defined?  No.  Did I know my priorities?  No.  Did I have a team with some history to extrapolate from to figure out my course of action?  No.  I had one simple and general mission statement "make our customers happier".  Now go get it done.  Years ago, I would have considered this a daunting task.  Not because the space to figure this out is large or complex (although it is), but because it is vague and ambiguous.  Engineers typically don't like ambiguity.  If things aren't defined, then our priority is to go and define them.  How else do we build things?  You can't build something you can't define.  Well, actually you can, but you won't be called an engineer if you do that, you will be called an artist.

Ambiguity is a useful tool if you know how to handle it.  If allowed to reign over your efforts for too long, your efforts will dissolve because no impact occurred.  Things just stayed ambiguous too long so eventually, as engineers, you find a new route, a way to avoid the ambiguity to get to some final result.  The unfortunate consequence of this drive for results is that if you allow ambiguity to not have it's time in the spotlight, you miss that deeply-buried idea that only presents itself in the final hours of your ability to hold on to ambiguity.  So, what I'm getting at is that ambiguity can be your friend, it can be your freedom to be creative and to generate a better solution than you ever could if you rushed into definitions and priorities.  It takes a lot of practice to skillfully master the correct timing around keeping ambiguity in your work in order to produce the best result you can.

As engineers, we want to drive for results, and we absolutely should.  But if you want to get to that next level of engineering discipline, the one where you solve problems other people would turn away from, you need to embrace ambiguity like it is your best friend.  You need to settle into it and let it surround you.  It allows you to think out-of-the-box and consider ideas you couldn't if you already had all the rules and definitions in place.  And when you let ambiguity be your friend, you can feel better about erasing all those ideas and trying again if they just didn't seem right.  On the spectrum, if you go from extremely ambiguous to very ambiguous, back to extremely ambiguous so that you can rethink your ideas, is it really that bad?

Many people that go to work every day want to accomplish something so they can feel satisfied when they head home and know that their time was well spent.  But what happens if your time was only spent, but maybe not well because what you accomplished didn't meet the mission of your job?  What if your team hasn't taken the time to truly think through what the end result should be and the best way to get there?  Sometimes the knee jerk solution wins because it gets people doing work and moving forward.  Is moving forward in the wrong direction still satisfying?

Now, if you are interested in stepping up and managing ambiguity, let's make sure you can identify it correctly.  Or let's make sure you know what it is not.  Confusion is not ambiguity.  Confusion may accompany ambiguity depending on the perspective of the person looking at the problem you are trying to solve.  I am currently a software engineering manager working in a quality org acting as a program manager most of the time.  To some people around me, that seems very confusing.  To me, it's ambiguity that allows me to cross boundaries into each discipline to work on what needs to get done to meet my original mission.  But I still must manage the confusion that others have based on their perspective.  Confusion is the experience others have when trying to make sense of the ambiguity.  Showing no results or doing no work in your job is not the same as having ambiguity.  Yes, you can still accomplish things and go home feeling satisfied while managing ambiguity.  But if you accomplish nothing throughout the day and chalk it up to ambiguity, you're missing the point.  Ambiguity shouldn't be an excuse for inactivity.  Ambiguity brings freedom and active creativity.  If you are inactive when ambiguity is around, it will get the best of you.  And your efforts, no matter how small, will dissolve.

You need to have confidence in your ability to manage ambiguity if you want to use it as a tool to drive creativity and move a project forward.  You must know when to let it loose and when to start cinching it down.  You should determine what parts of your project can keep some ambiguity longer while other parts may need to get clarity much faster.  You do need to drive to clarity at some point across your whole project.  That's the only way you will get something delivered.  At some point, all the ambiguity needs to be gone, like puddles evaporating in the hot sun.  And you are left with your very solid, concrete deliverable that contains a ton of creativity and is the correct solution because you let ambiguity stay just long enough to see the positive benefits of it.  So, let ambiguity be your friend and don't force it away too quickly with structure and results or you may just miss out on an awesome creative solution.