Could you describe a situation where you made a decision that didn't work out as planned? What did you learn from the experience?

Question

Anonymous · Accepted Answer

I created a 30 day coaching plan that didn't work out. I learned as the
performance improves, it best to revisit the plan and update as necessary for
continuous improvement

Anonymous · Answer

During the design of a migration project from DynamoDB to Opensearch, I missed a
detail that DynamoDB had enabled cross-region replication to avoid cross-region
calls. This added significant latency in other regions. I hadnt explicitly
called this out in my design doc so it never occurred to anyone either. We
discovered this during the A/B testing and decided to add cross-region
replication at a later point thereby causing a delay in the launch.
Result: This was a miss on my part for not verifying my assumptions. A good
learning for me from this experience is to verify assumptions and call them out
explicitly so even if I wasnt aware of some detail someone else might be.
Another learning was to perform mult-region load testing instead of sticking to
a single region as that woudl have helped discover this in the earlier stages as
well.

Anonymous · Answer

So i have this decision to upgrade one of the library in our codebase android.
So, i see that this library causing is outdated and might have relation to the
crash that happening for so long. So i did upgrade it, but when it is already on
production then i just knew that because this library upgrade, firebase logs in
firebase dashboard is not working as expected. Because of this, i had to rolled
back the upgrade of library and turns out after production release, it is also
not fixing the bugs.

What i have learnt from this is always checking all edge cases, creating a
documentation on pros/cons of why upgrading the libs, and rolling out carefully.

Anonymous · Answer

Context: One of the most challenging situations I had to deal with recently was
at freshpaint, a platform that helps health care providers protect their user
data. The situation was deciding whether or not to expand features on a product
we had just launched. The product scans our customers' websites periodically and
reports on trackers and pixels that could jeopardize user PII data. We assumed
that customers would also want the ability to select trackers in the reports and
implement blockers we provide. This feature would require significant
engineering resources and effort, and I wanted to ensure we were building the
right thing.
Decision process: To approach this decision, I consulted with stakeholders,
conducted customer interviews, and collected data for analysis. This involved
engaging with our product team, engineering leads, and a sample of our customers
to gather diverse perspectives and validate our assumptions.
Outcome: Ultimately, I decided to proceed with the feature, but I limited the
scope of the feature to gather more feedback. This decision was difficult
because, while early research showed potential, the evidence was not yet strong.
I had to balance immediate resource allocation with other priorities. 
Learning: This experience underscored the importance of validating customer
interests before committing significant resources. It also highlighted the value
of flexibility in project scope and the necessity of securing stakeholder
buy-in. Moving forward, I plan to allocate more time for preliminary research
and validation phases to ensure we align our efforts with customer needs and
organizational goals. Additionally, I will continue to emphasize the importance
of iterative development and stakeholder communication in future projects.

Could you describe a situation where you made a decision that didn't work out as planned? What did you learn from the experience?

Answers