Can you tell me about a difficult piece of feedback you received and how you handled it?

I was responsible for performing nightly software upgrades to our DNS servers.  The upgrade script failed around 1/3rd of the time, in which case I ran a separate back-out script that undid the changes.  I assumed the systems engineer responsible for the project was checking the upgrade results when he came in for the day, and addressing the failed upgrades.  He advised me later that he expected me to notify him of on any failures, and he took my silence to suggest all upgrades succeeded.  I acknowledged that I should have provided detailed nightly reports, apologized for failing to do so, and provided complete reports going forward.  I also requested additional training on how the scripts worked and what could be done in the event of a failure.  Ultimately all of the upgrades were completed, with additional assistance from the systems engineer for the failed upgrades.

Situation: I was working on a new reporting feature for OneTrust, specifically adding functionality for users to set up default dashboards. In our initial enthusiasm to deliver a robust solution, we rushed into the design phase without fully understanding the project's requirements and user needs.

Feedback Received: My manager provided me with difficult feedback, pointing out that we had skipped crucial steps in the process by not thoroughly collecting user requirements upfront. This oversight had led to overly complex design concepts, threatening to bloat the project scope and delay the release.

Task: The task was to address this feedback by improving the process of collecting user requirements at the project's outset to prevent scope creep and ensure the project stayed on track.

Action:

Acknowledged the Feedback: I took the feedback seriously and recognized the importance of thorough upfront research and clear goal setting.

Led Upfront Research: I initiated cross-functional workshops with key stakeholders, including product managers, developers, and user researchers. These workshops focused on:

Collaborative Goal Setting: Clearly defining the core functionalities of the default dashboard feature to ensure everyone was aligned from the outset.

Uncovering User Needs: Conducting in-depth user research through interviews and usability testing to tailor the design to actual user needs.

Documented and Approved: I documented all the findings from the workshops in a comprehensive report, including user insights, revised project goals, and a proposed design direction. I presented this documentation to all stakeholders for review and approval, ensuring a clear path forward.

Result:

Reduced Scope Creep: Implementing these strategies contained the project scope within its original boundaries, preventing unnecessary feature creep and ensuring efficient resource allocation.

Improved Focus and Efficiency: A well-defined project roadmap allowed the entire team to maintain focus and execute the design and development process efficiently, saving time and resources.

Enhanced Team Collaboration: The collaborative workshops fostered better communication and alignment among all stakeholders, leading to a more cohesive project approach and stronger teamwork.

High-Quality Deliverables: By addressing user needs and prioritizing clarity from the start, we delivered a high-quality, user-friendly default dashboard feature that met all project requirements and provided a positive user experience.

Lesson Learned: This experience solidified the importance of thorough upfront research and clear goal setting in UX design. The feedback, although difficult to hear, was crucial in improving my approach to project management. By prioritizing these actions, I learned to ensure focused, efficient, and high-quality project execution.

The actual words were "You're not the manager, I am the manager". This was a consulting engagement where an engagement manager was managing multiple projects including mine. I was leading a pipeline migration team for a client manager, where my team was pulled in different directions because of lack of clarity in work. My first task after joining the team was to streamline these adhoc requests and gate them so that we don't drop the ball on the migration. While doing that I had to make a number of hard conversations with the client manager, where I was trying to manage scope and say no to a bunch of his requests. This included some technical requests which was usually taken by the solution architect in the team. When the engagement manager heard about that he felt that I was overstepping my authority. He felt that I was taking decisions which I should not. I politely informed him that I did not intent to be a manager, but just wanted to make sure that the correct work was driven. Also, I had had conversations with the solution architect, and we had reached on an agreement on pushing back on these requests. I also told the engagement manager that I will keep him informed of these decisions in the future. I set up a 1:1 weekly meeting with him afterwards, where we would talk about the progress and impediments, and I would discuss my approach on how to manage them.

Initially when I joined the project, I was testing user stories and creating defects on defect management tool. In bug triage meeting, I discussed about the defects which I created and got it reviewed. However, after the meeting my supervisor gave me a critical feedback about the incomplete information in the defect.

At first I was defensive about the feedback and was little concerned. But then I soon realized that this feedback will help me improve my QA skills and processes.

So, I reviewed the defects raised by me and added all relevant information like when was the first time I noticed the issue, steps to reproduce the issue, what test data was used, which environment has this issue occurred, also updated the summary of the defect with proper wordings.

Thus, going forward I always use standard format in creating the defects like- details, steps to reproduce, expected result, actual result, test data/ payload used, any other information.

I learnt from this incident the importance of information given, which leads to quick turnaround time in resolution of the issue.

Now after standardizing the format of raising the defect by me, it is being used by other coworkers. 

During my initial years at Amazon, I received a critical feedback from my manager and other colleagues that even though I have strong technical skills, I am not very vocal in expressing my opinions. Initially this was difficult to take as I always thought my work speaks for itself. I later started showing improvements by prepping for design discussions and actively participating in them. I noticed that my opinions mattered and people valued them. This helped me grow in my team and fostered a positive relationship with my teammates.

Certainly, here's another example:

"One particularly tough piece of feedback I received was from a professor on a research paper I had worked on for months. They pointed out several flaws in my argumentation and analysis, suggesting that my conclusions were not well-supported by the evidence. Initially, I felt disheartened and frustrated, especially after investing so much time and effort into the project. However, I knew that dwelling on those feelings wouldn't help me improve. Instead, I took a step back and carefully reviewed the feedback, trying to understand where I went wrong. It was hard to accept at first, but I realized that constructive criticism is essential for growth. I revisited my research, strengthened my argument, and refined my analysis based on the feedback. In the end, the paper improved significantly, and I learned valuable lessons about humility, perseverance, and the importance of seeking feedback to enhance my skills."

While working at XXY as the Director of Technology, one of my key responsibilities was to develop an Operational Excellence roadmap for the upcoming fiscal year. We were onboarding many new customers, and my CTO wanted me to lead this initiative.

After two weeks of preparation, I called a meeting to present my plan. However, I was unprepared for the depth of questions I faced, such as inquiries about our escalation strategy and ticketing process. Unable to answer many of these questions, I left the meeting feeling disheartened.

That evening, I reflected on where I went wrong. Instead of rushing to set up another meeting, I decided to take a more methodical approach. I documented my thoughts and strategies in detail, outlining a comprehensive roadmap. I then shared this document with my peers to gather additional input and feedback.

After incorporating their suggestions, I refined the document and shared it with my CTO. Following a few iterations and improvements, I felt confident that the roadmap addressed our operational requirements comprehensively.

I then called a meeting with my peers to gain their buy-in. With their support, we proceeded with the plan as documented.

The key lessons I learned from this experience are:

At center card, while I was leading the infrastructure team - my CTO asked me to come up with metrics and monitoring strategy. Initially I presented the metrics with only the Kubernetes related metrics  and the monitoring setup we need to have, my CTO was not happy and he asked me re-work on the metrics and come up with a more comprehensive data points. I realized that i need to do a deep dive with not just Kubernetes but also in relation to applications we would running on, I first gathered all the data points which was present on Kubernetes and the applications which were running on it. then I looked at the logs to understand the nature of errors - based that I came up with more precise and wholistic approach to determine the health of the system and the applications that were running on it. The lesson I learnt is that, I need to not take the feedback personally, but a way to improve on the feedback and learn from it.

Yes, I will give you one example that I got from my co-worker. He mentioned that the information that I prepared to discuss in the meeting is insufficient and he cannot proceed next step and have to wait until information from me is available that caused delay in feedback to customer.

What I did for this case is:

Firstly, I say thank you and apologize for the insufficient information and then I came back to review if it is really insufficient. The answer was yes, I missing to provide him about production date of the component that caused he cannot trace back production historical and checked other related information with manufacturing team. This information is part of the request from customer.

Then right after the meeting, I immediate find out that information and provided him and confirm with him if other information is required. Then he can use this information to work with other members and we can submit the required information to customer on time.

What I have learnt from this situation, 1) I have expanded this lesson learnt to other activities for example, when writing email, I have to review it carefully and ensure the information is sufficient to make it clear communicated, no rework or double job. 2) When reviewing, I have to think in different dimensions or wear different hats then I can get potential questions and I will prepare it accordingly.

When I recieve difficult feedback, I try to analyze what went wrong and how I can improve and grow from it.

At Auctane, we had small outage as during our initial phase. My Manager was not happy that we did not catch it early - to avoid customer impact. I looked at the current process of capturing and we lacked some of the metrics - instead of just  fixing and moving forward, I wanted my team and myself to own and learn from it.

I facitlited a deep dive into the root cause of the issue, by documenting and having a lessons learnt drafted by my team, I communicated to my leadrship - on what mistakes were made and what we learnt from our mistakes - we broadcasted to all the team members so that they can also learn from our mistakes. We call this document as "Correction of Errors"

In the past, I received difficult feedback in the form of critiquing code. For instance, situations involved negative feedback on code organization, choice, or format. However, in cases like these I found these critiques quite useful. After receiving feedback on my code organization, I took the time to learn more about best practices in code organization and applied these principles in my subsequent projects. This significantly improved the readability and efficiency of my code. I can prevent future mistakes by using this feedback as a guide to write code in an organized and robust fashion. I value keeping composure and seek feedback as improvement for attributes/knowledge I lack.