Handling Ambiguity in the Workspace

Problem

Ambiguity is part of our everyday life -- and to no surprise, work too. Knowing how to strive in an ambiguous environment is one of the critical traits engineers should have. I get to encounter a variety of ambiguous situations in the workplace, where my ability to find my way through vagueness and uncertainty helped me solve the most complicated problems.

I was once assigned a rather ambiguous project where even the stakeholders didn’t know what a product should look like. They approached me with a fairly vague vision of what they wanted to do. During the calls with some of the insurance agents who were using our platform, they learned about a pattern of violations of compliance rules. Without compliant to these rules, nothing that agents will sell could be accepted. The problem was obvious: agents were wasting time and money. But how to solve it was a bit less obvious.

Actions taken

The proposal that ended up on my plate was that we should build something to eliminate the possibility of such a scenario taking place. Frankly, that proposal struck me as rather ambiguous. I could see what the problem was, but I didn’t know where we were heading. To move forward, I had to convert their proposal into a well-defined engineering problem. I started off by asking two questions:

• How would you define a quantified success for this project? For example, by how much (what percent) you want to reduce the possibility of that scenario;
• What is the type of behavior you want to achieve: preventional or punitive?
  

While I needed some clarity of the context, my questions were meant to help stakeholders reflect more on the problem and better understand the needs of insurance agents. In general, the approach I practice is to get into other people’s shoes. Although I am an engineer, I should be able to think like a product owner or any other stakeholder I am interacting with. Empathy helps me grasp even better than some stakeholders what the problem is and how to solve it. In this particular case, empathy coupled with my engineering competencies allowed me to propose a new solution.

I came up with a pretty solid solution. We were going to build automatic tools that would monitor the calls, collect data and do some basic metrics analysis. Based on those metrics, we would propose courses to those agents who needed more training or help. We set up a sophisticated mechanism that would differentiate between the first, second, and third violations. Once the requirements were clearly set, it was easy to implement them and build the product.

Then, once the product was there, we had to come up with a plan on how we would measure the success. We needed a lot of monitoring and analysis to showcase that the engineering effort put into this project didn’t end in vain. We created multiple business metrics dashboards to show the before-after difference, which was persuasive both to agents and stakeholders.

Lessons learned

• Ambiguity is a norm rather than an anomaly of engineering. Rather than trying to avoid it, try to embrace it.
• You should always put yourself in other people’s shoes. That would allow to keep ownership but expand the perspective. Putting yourself in your stakeholders’ shoes will give you insights you wouldn’t be able to acquire if you have stayed entrenched in your role.
• Define project requirements as clearly as possible. Oftentimes stakeholders don’t know what they want. But you can help them better understand their needs by sharing the context and possibilities they are unaware of. You should help them define what they, in fact, want. There are many ways to do that. I strongly recommend quantifying success metrics to start with.
• Before you jump into implementation, you need to set up a monitoring process along with a dashboard that will display the progress that will be made. You should define those metrics before the project is completed to reduce the amount of uncertainty.