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

Question

Anonymous · Accepted Answer

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.

Anonymous · Answer

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.

Anonymous · Answer

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"

Anonymous · Answer

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.

Anonymous · Answer

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.

Anonymous · Answer

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:
 1. Document Your Thoughts: Clearly articulate your strategies and approaches in
    writing to ensure thoroughness and clarity.
 2. Collaborate with Stakeholders: Actively seek and incorporate feedback from
    peers and stakeholders to strengthen your plan.
 3. Prepare for Decision-Making: Schedule meetings only when you have addressed
    potential edge cases and are ready to make informed decisions.

Anonymous · Answer

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."

Anonymous · Answer

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.

Anonymous · Answer

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.

Anonymous · Answer

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.

Anonymous · Answer

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.

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

Answers