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

How to Maintain Happiness: The Underrated Aspect of Creating Team Dynamic

2 August

Jonathan Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.

Personal Growth
Company Culture
Leadership
Internal Communication
Psychological Safety
Jonathan Ducharme

Jonathan Ducharme

Engineering Manager at AlleyCorp Nord

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

Dealing with Uncertainties and Adapting as You Go

14 June

Muhammad Hamada, Engineering Manager at HelloFresh, addresses the uncertainties brought on by the pandemic, how these have affected our work environments, and how we can adapt.

Goal Setting
Internal Communication
Collaboration
Roadmap
Stakeholders
Prioritization
Muhammad Hamada

Muhammad Hamada

Engineering Manager at HelloFresh

Promoting Interdepartmental Teamwork for More Efficient Problem-Solving

13 June

Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.

Internal Communication
Collaboration
Roadmap
Team Processes
Cross-Functional Collaboration
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems