Back to resources

Handling Ambiguity in the Workspace

Internal Communication
Stakeholders
Team Processes

16 August, 2021

Richard Li
Richard Li

Senior Software Engineer Manager at ASSURANCE IQ

Richard Li, Senior Software Engineer Manager at ASSURANCE IQ, shares how he minimized ambiguity by translating a vague idea into a well-defined engineering project.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Innovation / Experiment
Building A Team
Leadership
Ownership
Stakeholders
Cross-Functional Collaboration
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Growth Mindset in Modern Product Engineering

28 November

The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.

Building A Team
Leadership
Collaboration
Feedback
Ownership
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy