Tell us about a time when you made an unpopular decision.

In my previous role as a project manager, I once decided to delay a product launch by a month. The development team encountered unforeseen technical issues, and despite the pressure from stakeholders to meet the original deadline, I chose to prioritize the quality and stability of the product. This decision was unpopular among the sales and marketing teams who had campaigns aligned with the initial launch date. However, the extra time allowed the team to resolve critical bugs and improve overall performance, leading to a successful launch and positive customer feedback, ultimately validating the decision.

“One night flying into Newark, we were on final approach after a long day with gusty winds, turbulence, and low visibility. The captain was flying, and I was pilot monitoring, keeping an eye on airspeed, alignment, and anything that might require a callout. Everyone was ready to be on the ground — the passengers, the crew — it had been a long day, and the momentum was to just get the airplane landed.

As we crossed the runway threshold, the airplane hit a strong burst of turbulence and refused to settle. In that split second, I knew what had to be done, but I also knew it wouldn’t be the popular choice. A go-around meant a delay, frustrated passengers, and possibly second-guessing from the crew. But safety has to come first, so I immediately called ‘Go-around.’ The captain executed it smoothly, and we climbed away, briefed again, and landed safely on the second attempt.

Afterward, the captain thanked me for speaking up and said he completely agreed with the decision. It reinforced for me that as pilots, we can’t let convenience or the desire to finish cloud our judgment. Sometimes the right call isn’t the popular one, but it’s always the right call when it keeps everyone safe.”

In my engineering design course, I led a group project where we had to develop a prototype. Early on, the team disagreed about how much time we should spend refining the design versus testing quickly. Most wanted to keep adding features, but our deadline was tight, and our grade depended heavily on functionality.

As the team lead, I had to make the call on how to move forward, even though I knew it wouldn’t be popular with some teammates.

I decided we would pause new feature ideas and focus on simplifying the design so we could test earlier. I communicated this clearly to the group, explaining that while it might feel like we were cutting corners, it was the best way to meet the deadline and improve our grade. I also made sure to involve those who disagreed by giving them ownership over specific testing tasks so they still felt engaged.

At first, there was some frustration, but as testing revealed issues we hadn’t anticipated, the team realized the decision paid off. We had time to fix problems, and ultimately our grade improved from where it was trending—a strong result that everyone was proud of. The experience taught me how to make tough calls, explain the reasoning behind them, and bring people along even when they initially disagree.

While I was working at the insurance company, I was implementing an application that would let users submit an application to the underwriters for receiving quotes.This was mainly for users that not approved in the first round of application but were referred for underwriter referrals.This application would receive sensitive data from the users to determine their eligibility. During the implementation of this  new software application, we encountered a critical security vulnerability related to authentication and session management. Our team had initially planned for a smooth rollout, but this issue disrupted our timeline.

Action:

• Discovery: While conducting thorough testing, our QA team identified the vulnerability. Essentially, the application was not properly invalidating user sessions after logout, leaving the door open for session hijacking.

• Impact Assessment: We quickly assessed the potential impact. If exploited, this vulnerability could allow unauthorized access to sensitive user data or even compromise the entire system.

• Revised Priorities: Recognizing the severity, I immediately shifted our priorities. Instead of proceeding with feature enhancements, we focused solely on fixing the authentication flow.

• Collaboration: I worked closely with developers, security experts, and stakeholders. We implemented proper session management, including secure session tokens, session timeouts, and robust logout mechanisms.

• Communication: I kept all stakeholders informed about the situation. We had to adjust the project timeline, which meant communicating the delay to upper management and end-users.

• Risk Mitigation: Beyond the immediate fix, we also reviewed other parts of the application for similar vulnerabilities. This proactive approach helped prevent future issues.

Result:

• Successful Mitigation: By addressing the vulnerability promptly, we ensured that user sessions were secure. The revised authentication process was thoroughly tested and validated.

• Project Impact: Although the change disrupted our original timeline, stakeholders appreciated our commitment to security. Their trust in our team remained intact.

• Process Improvement: We incorporated stricter security checks into our development workflow, ensuring that such issues would be caught earlier in future projects.

At my previous job in an accounting office, my role involved gathering and verifying documents from around 500 customers. This required constant communication with insurance companies, banks, and customers to track missing paperwork. Our team of five—including the accountant, the account manager, a secretary, another worker, and me—had to stay updated on each case. However, we relied on WhatsApp for communication, which was inefficient because updates were scattered, and no one had access to each other’s work unless shared manually through messages. I needed to find a way to improve collaboration and document tracking so that we could work more efficiently without constant back-and-forth messaging. I introduced an app with software that centralized all our work—allowing us to access shared notes, documents, emails, and even communicate through a built-in chat. Initially, my team was hesitant, fearing it would create confusion since anyone could edit each other’s notes. To address their concerns, I set up guidelines for how we would use the tool, provided a short training session, and demonstrated how it could actually make our work more organized. Although my colleagues were skeptical at first, within a few weeks, we noticed a significant improvement. We spent less time updating each other manually, our response times to customers became faster, and overall efficiency increased. Eventually, even those who resisted at the beginning admitted that the new system helped us work more smoothly.

When working at Flutter different teams were using different continuous integration systems. This was a consequence of not having a centralized Engineering Productivity team however when the Engineering Productivity team was created having to support multiple CI systems was splitting resources that could be used to solve scalability or reliability problems.

I proposed consolidating all the Flutter Teams development workflows to use a single continuous integration. The proposed system was highly scalable and reliable but it was slightly more difficult to use. Even though the benefits were many, some teams opposed the change and I had to offer concessions to unblock the program. I had to negotiate and offered a transitional change keeping the two different infrastructures running at the same time with an eventual deprecation on one of them. This increased the maintenance burden in the short term but allowed me to continue the standardization process with an eventual convergence to single infrastructure.

For several reasons (unlisted here for brevity) I needed a team to participate in the operational up-keep and on-call rotation for a old large stateful backend service. This was initially unpopular with the team because it was a departure from what they expected: which was that they'd go on-call only for the new backend that they'd built if and when it is productionalized.

I spoke to the team individually to ensure I learnt all the reasons for their lack of support and addressed each of them over a period of 3 months. 

Other actions taken:

1. Explain benefits of learning how to operate large services

2. Spell out the opportunity to study the code of a $1B data service.

3. Show them why it's beneficial to work with in-house experts (Senior, Staff engineers on the team whom they'd previously not had exposure to).

4. Promise to make on-call better. And stick to it. Quantify the betterment. We reduced operational load from 60+/week to <7 when they went on-call independently.

5. Provide training deliberately.

6. Promise to be open to changes and genuinely listen and incorporate feedback.

Result:

The two sites where brought together under the wider organization. Tenured folks in BarLand were able to share their operational expertise and 15+ years of lessons gathered about customer usecases with the FooLand team. FooLand brought in fresh perspective to the old backend and learnt valuable lessons on why it had evolved the way it had. They also got a better understanding of ways to conduct at-scale tests and learnt more about their own system while teaching their colleagues.

When I need to make a unpopular decision - I try to anticipate the pushback I can get and see how I can mitigate that.. At Auctane, I noticed that there was no unit tests on the legacy code, I knew I had to improve on the engineering standards. When we had a plan to migrate to monlotith  - I proposed we add unit tests in our sprint cycle, I got a push back from the established team members as they did not want to change thier approach to development. So I apporached new devs on the team, they were onboard with this idea, after 2 sprints the team saw the code with unit tests were less buggy and more modular. This encouraged others to adopt units test while development phase well. In the end our team achived at least 75% code coverage.

At Motorola, we were building IoT devices and the V1 version we sent to our clients and the update process for the IoT device fumbled. This meant that some of our clients had no way to recover the IoT device and function normally. This had a huge customer impact and I realized this and I took ownership of that and we went back to the drawing board, reworked the way we would update our IoT device. Reworked the way we updated our IoT device and we had to ship a new set of boxes for the customers to install. This led to some downtime for the customers in the short run, but it was also the right thing to do so that we can achieve the long-term stability of the devices.

החלטה לא פופולרית שעשיתי במהלך העבודה שלי בבנק הייתה לפטר מנהל מוצר שעבד תחתיי למרות שהיה אדם ממש נעים, חברותי ואנשים אהבו לעבוד איתו. למרות שההחלטה הייתה מאד לא קלה, היא הייתה מאד נכונה. אותו מנהל מוצר לא היה מתעמק במוצרים שלו ובדרישות שכתב, הוא לא היה מבין את הדברים לעומק והיה נשאר בלבל מאד שטחי. על כן, המוצר שלו לא התקדם בהתאם ליעדים שהוגדרו לו וזה גרם למעורבות ניהולית מאד גבוהה מצידי. ניסיתי להדריך וללמד אותו מה נדרש ממנהל מוצר, לתת לו דוגמאות מהעבודה היומיומית כדי לראות כיצד ניתן להשתפר ובסופו של דבר לאחר תקופה ממושכת של חוסר שיפור, החלטתי שאין ברירה להחליף אותו. במקום יציב כמו הבנק, זו לא החלטה טרוואלית וזו החלטה שהיה קשה להעביר במשאבי אנוש אך לאחר שהרגשתי שעשיתי הכל כדי לגרום לו להשתפר, הבנתי שלהמשיך להעסיק אותו פוגע במוצר, בעמידה ביעדים וכפועל יוצא, בארגון.

At Auctane, we were following a out dated deployment process. That is inspite of we moving to monloith services.. we followed a single . It caused a big bottleneck in our release time frame and I challenged the need for such a train - as one of the philosophy in Microservice is independently deployable. The team was relectant to make changes to the process (for e,g we needed to create a seperate github repo, come up with a artifactory repo) - the team was initially reluctant to make changes but I convinved the team that this was a good move in the long run as it would eliminate unnecessary process and speed things. Even though the team did not agree initially, they saw the value after we migrated to new process. My philiopy was short term pain for long term gain.

We had a large renovation at a labritory scheduled and partway through to job it was brought to my attention that there was an issue with us disrupting some of the labritories work. I needed to find a way to complete the work and not disrupt the client. I descided to change the hours of work for my workers from days to nights. this was very unpopular but had to be done. I gathered all the workers together and explained why we needed the change and that it would benifit us as well by removing obsticles. after a few nights work most of the workers agreed this was a good idea as it helped speed up our work and shortened the projects time line

A client request a dead line I felt was not unachievable. after listening to the clients concerned,  I explained why the time line was not achievable, due to the plans being approved by the local planing and zoning department.  The end result was the client understood the issues and adjusted their expectations. 

Back in December 2024 the decision from the City to descope or "defer" the station to a later date, I had a team meeting to communicate the decision and start looking at a full Value engineering. Some of the team members were upset that after all these years working on designs we were not going to deliver but I stood strong and reassured that our roles and jobs were kept and that in the government this is not atypical and that we are still delivering a large scale project that will keep us busy for the forthcoming years. I maintain that I was available if anyone needed to discuss this further and make sure that all their questions were answered in the most transparent way

I had to migrate some CI/CD tests which run on older devices to run on newer device. There were already newer device tests added to our end to end pipeline to be part of CI/CD. My initial idea was to keep them running and not migrate them.

Later after migrating ~10 suites I was completing the migration program document and figured that we would have to disable older CI/CD tests once we have newer device tests which would end the program.

Then I changed my script to migrate anything that is in newer device also so it would make the disabling process smoother and not human resource intensive.

As a QA leader I had to choose between run a full check of a new functionality that wasnt very popular or use or let the change pass over with the aprove of the PM for some time saving. I choose run the full check, take a few days more, but when the functionality goes to production it works well, without any bugs.