Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

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

Specialization vs. Wearing Many Hats

23 November

William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.

Internal Communication
Collaboration
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Building a New Team in a Foreign Country

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, went all the way across the world to build a brand new team who worked very differently than he was used to.

Team Processes
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

What It Takes to Understand Other’s Perspective

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how to really understand someone else’s point of view.

Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

How to Handle Team Collaboration After a Merger?

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how he helped the acquired company’s team members understand the business mission and give them focus.

Acquisition / Integration
Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

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.