Congratulate your anxiety/paralysis on being right, and do not try to overtly solve the problem. Instead, try moving the situation forward in one or more ways:
- Documentation: Write up the history of the problem, when it occurs, which users are affected, what previous work has been done toward solving the problem, etc.
- Reduction: Only look for limited solutions - proving a few of the "easy" cases for some difficult mathematical theorem. Patches or work-arounds that only reduce the impact of a computer program failing. Chemical synthesis of a less-tricky part of a complex organic molecule.
- Counter-example: A counter-example can be literal - the problem was to prove a mathematical theorem, and your counter-example proves that the theorem is wrong. Or, it can be a proof that the problem is impossibly difficult. The mathematical theorem you were told to prove is equivalent to the Axiom of Choice. The computer programming challenge is equivalent to P vs. NP. The physical theory/device you need to create would violate the laws of thermodynamics.
- Define a very clear target. Include quantities. If the goal is "speed up the api endpoint"... measure the current performance and define a target. The goal must become tangible and measurable in an objective way. Otherwise, it's just up to someone's opinion whether the goal was reached.
- Get stakeholder buy-in on that target. Also communicate your estimate of the probability of success.
Boss: "Hey how are you getting on? You said this'll take two weeks tops, we've got so many clients asking for this thing."
It's most problematic when something looks simple and easy at first glance but then ends up with corner cases upon corner cases and the damn thing refuses to work properly while you sink into a pit of despair amidst calls to deliver already.
This is more important than you think. To expand on the parent, when communicating keep in mind several extremely important goals:
- you are able to organize your work. If a problem is potentially without a solution, you're likely not going to be able to hold all of that info in your brain at all times.
- when you bring someone in to help, they could get all the context they need by reading the materials - emails, documents, comments, etc, that you already created and organized. They will likely not have all the context you have, but they will have information available and digested.
- it helps keep stakeholders up to date on the progress and risks. Maybe you are able to just talk to your boss, but you don't want to repeat all of that each time you tell someone new. You don't want to setup a meeting just to update your stakeholders
- in case you are able to solve the problem, the materials you write while solving the problem will serve as a staring point for the documentation of the feature/product
Expectation management. Be predictable in your output even if it means being a bit worse on average. If you occasionally perform miracles, don’t be surprised when people show up asking for more miracles.
This is why I prefer to commit to stages of development, rather than a shipping feature, for things that require research. If possible, I will absolutely try to avoid giving a target date for a feature until I've already got a prototype working. I will give a target date for the prototype, though... even though that number is far more often just an arbitrary date than not.
I understand that my approach frustrates managers who demand timelines. But sometimes reality interferes with those timelines, and I'm the one steeped in reality.
Which then immediately gets thrown into production and becomes the bedrock upon which further bad decisions are irreversibly built on every time, of course. Now the time pressure is even higher because people are actively complaining about the issues that cannot be solved with the hastily jerry rigged implementation ("should be simple right, just do..." is a bane of my existence).
- Documentation: Write up the history of the problem, when it occurs, which users are affected, what previous work has been done toward solving the problem, etc.
- Reduction: Only look for limited solutions - proving a few of the "easy" cases for some difficult mathematical theorem. Patches or work-arounds that only reduce the impact of a computer program failing. Chemical synthesis of a less-tricky part of a complex organic molecule.
- Counter-example: A counter-example can be literal - the problem was to prove a mathematical theorem, and your counter-example proves that the theorem is wrong. Or, it can be a proof that the problem is impossibly difficult. The mathematical theorem you were told to prove is equivalent to the Axiom of Choice. The computer programming challenge is equivalent to P vs. NP. The physical theory/device you need to create would violate the laws of thermodynamics.