Tell me about a time you had a disagreement with a team member.

Situation: I was the lead DS at the Discovery team and DS POC for holdout setup, monitor, and analysis. The holdout setup has been a very successful tool to evaluate the long term impact of the team and to track the OKR. However, my paired EM pushed it back and was not willing to set the holdout for the next half year.

Task: convince my EM and get Eng support to set the holdout.

Action:

1. Understand why the EM was not supportive: short of Eng resource, holdout introduces the overhead since we have to maintain it in the long term; OKR track got diluted by both algorithm and UI changes.

2. List the reasons why we need the holdout using data to both EM and PM 

   1. Holdout is a standard tool for data/tech-driven company in FLAAG

   2. It helped to trigger alerts of outage in discovery for 2+ times in the last few months

   3. It helped to evaluate and validate the team’s combined efforts in the long term

   4. The holdout setup is good candidate for failover that we know the business performance.

3. Reprioritize the tasks that need Eng support including the holdout setup. Got fully support from the PM, and came up with solutions together with the EM that simplified the holdout setups, and added process to automate the monitoring and maintenance.

Results: Got the EM convinced that holdout is essential and successfully set the improved holdout in time.

I’m telling you about my story when I participated in the Hackathon Competition hosted by Google Developer Group in Vietnam.

We had 5 members in a team and my role is a PM and mobile developer. Because we had only 48 hours to build everything from scratch, the feature prioritization was very important. This was the most essential element making the success of the project in hackathon competition. My engineers were very critical thinking, so it was not easy for me to convince them. 

At first, my team came up with the ideas to create the platform helping drivers be able to find suitable parking lots by connecting drivers and parking owners. Everyone thought it was quite good for us to create a solution in the short term, but me. I didn’t think so because it had some potential problems.

Now, I had some options inside my head that

• Focus on the solution team came up to make sure we did not quarrel because we didn’t have enough time.

  • Pros: Saving time, did not quarrel.

  • Cons: Business Model was not convinced

• Arguing this solution that was thought for 3 hour and coming up with the new idea from a personal view. 

  • Pros: We could possibly improve BM.

  • Cons: Removing all effort from other members and spending more valuable time on brainstorming another idea.

After making a quick research about the market and doing a quick interview with potential customers, I made a decision to tell my team that we would change the idea. At first, they were very disappointed and felt that 3 past hours were totally wastless. I knew it would happen, but I handled this situation by telling them the more brilliant idea they should choose instead of the last one.

• First, I showed them some numbers and evidence.

  • The number of vehicles and private parking lots in Vietnam. Demand >> Supply

  • The number of public parking lots around Vietnam

  • The past and current solution which have been almost the same as our problem.

• Now, they realised the problems in our solution. But they started feeling confused about how to monitor the public parking without any camera or monitoring device.

• My suggestion is we would recommend first instead of monitoring them. So what is “recommend”?

• Our customer’s pain point when they were using public parking lots in Vietnam was that the rules for parking in VN were very complicated and differentiating from other cities. So it was very easy to get a fire ticket when parking in public lots. 

• Therefore, our 1st MVP was ensuring that the drivers could use public parking lots, such as roadside, public parks without any concern about laws.

• To do that, we would collect the data from open-source maps then reorganize the data street and collect the parking laws from the government. Then put them together and suggest the suitable solutions for our customers.

• Because time was limited, so we limited the map we would cover, just around a district in our cities to present the idea.

• Finally after a 20-hour hackathon we could release the 1st prototype to present our idea and how it worked. Because of the differentiated solution, we won the young potential award around 40 teams in this hackathon competition.

A. Situation: 1. was selection of partner for a high performance, high reliable Database used in Telecom apps deployed in large scale.

B. Tasks. We had team of two myself and my team member assigned as prime evaluators with supporting technical staff. Director and VP ultimate decision makers. 

Had two existing vendors A, B and also Open Source alternatives. 

C. Action: since disagreements were likey,   I pushed for formal process that was transparent. Had formed a x functional team including technical, sales, support. RFP was created and evaluation table created and reviewed. We involved procurement and got responses. After bid defenses, gaps identified. Feature gaps were there on vendor A and B and had to be roadmapped.  Disagreement: my team member favored A and I favored B.   We did "even swaps" technique to wade through 50+ items and ultimately created a short 5 item list of disagreements. We decided to do something innovative. I took role to advocate his position and he did for my position in forum with our Director and VP. Ultimately we went with vendor that was advocated by my team member.

D. Results. we had a structured approach to resolve differences.