Overcoming Ambiguity at Work
Ambiguity is inevitable in nearly every project and team. Communicating a vision or requirement with a group of people with varying backgrounds and areas of expertise can be difficult. The ability to identify and overcome ambiguity will often play a crucial role in the success of a project. Below I have listed a few methods that I use to add clarity and reduce ambiguity when starting a new project or feature.
This is the simplest place to start, but might be uncomfortable for some people. If you don't understand what is being discussed, then it is important to call that out right away. Chances are, if you don't understand something then someone else in the room (or on the call) doesn't either. Asking a clarifying question has no downside, but could have a huge upside if it means identifying a missed requirement or a misunderstanding early.
Some people are just really good at seeing the big picture and being able to put all of the pieces together. They may be more familiar with the domain or the person making the request. No matter what it is, lean on other members of the team to gain a better understanding of what is being presented.
I currently work with an excellent Principle Engineer who is like a "Patrick Whisperer". He is extremely good at framing problems and rephrasing complicated requests in a way that I can understand. These skills are sometimes undervalued, but are extremely important.
This is my favorite way to overcome ambiguity and make sure everyone is on the same page. There are very few ways to replace a good whiteboarding session. High level descriptions can often be hard to follow and can leave a lot of gaps. Working through "real world" examples, talking about work flow, and working through edge cases can provide a lot of clarity. It can also be an excellent way to document what was discussed and decisions that were made for later reference.
This is a method that I have used a lot more with my current teams. We build some very complex systems and work with astronomically large datasets. This means that even if we think everyone is on the same page and we have worked through all scenarios, there can still be a lot of gaps or uncertainty. Instead of going all in on a solution, we build a small proof of concept (POC) or execute some scenarios with real data that we can show to the project team and get feedback.
Conclusion
These were just a few ways that I use to overcome ambiguity. Like any other skill or process, it will take time and multiple iterations to see improvement. Ambiguity is inevitable, but by being intentional in working to overcome, it doesn't have to derail your next project.
Data Science, Data Automation, and AI
9 个月I was also thinking of “Being flexible to pivot and learn from mistakes”