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

The Art of Asking Why: Narrowing the Gap Between Customers and Users

24 May

Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Customers
Innovation / Experiment
Product
Personal Growth
Leadership
Stakeholders
Users
Jord Sips

Jord Sips

Senior Product Manager at Mews

Managing Different Time Zones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Managing Remotely: Balancing Team Cohesion and Focus Time

26 May

Jonathan Belcher, Engineering Manager at Curative, explains how to balance team cohesion and individual focus time, tapping into his experiences of working remotely for seven years.

Remote
Micromanagement
Meetings
Internal Communication
Productivity
Psychological Safety
Performance
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.