https://www.amazon.com/Have-Fun-at-Work-Livingston/dp/093706...
this book covers the head space you are in ("homo sap has gotten in over his head") and you should read it now:
https://www.amazon.com/Have-Fun-at-Work-Livingston/dp/093706...
In a non-startup company there is generally one bottleneck that holds the organization back and has to be controlled
https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0...
In a startup company or if you are trying to develop a "revolutionary" product there are usual several bottlenecks that need to be attacked. For instance going to the moon you have to solve problems from a list such as
* propulsion
* navigation
* life support
https://www.amazon.com/Have-Fun-at-Work-Livingston/dp/093706...
When you use goals to "destroy the competition" or "change the world", goals are a powerful technique. If you are setting goals because somebody told you to set goals or somebody else sets goals you are going to drive yourself to distraction.
https://www.amazon.com/Have-Fun-at-Work-Livingston/dp/093706...
is a manifesto for "small groups" to solve hard problems.
https://www.amazon.com/Have-Fun-at-Work-Livingston/dp/093706...
it has a checklist to answer your question.
I am not so sure it is either/or. Probably your product/business people are as concerned about the success of your product as you are, so if you bring up this issue that communication is a problem, maybe they'll be responsive.
Working across time zones require some adaptation. Often I have meetings at 8am in the morning with people in Europe and Asia, sometimes I have meetings at 8pm at night. If you have a few people who do liasoning on each side, they could each shift schedules by 1 hour and then you have a three hour overlap. You can get better at written communications, there really are a lot of options.
Definitely when you can't get in the face of a "product manager" there are some people who really won't do the job, and sometimes they won't if you can get in their face.
Some tasks are hard to estimate because they have an element of experimentation or research. Here a working model is the "run-break-fix" model where you expect to require an unknown number of attempts to solve the problem. In that case there are two variables you can control: (1) be able to solve the problem in less tries, and (2) take less time to make a try.
The RBF model points out various problems with carelessness as an ideology. First of all, being careless can cause you to require more tries. Being careless can cause you to ship something that doesn't work. Secondly, and more important, the royal road to (2) is automation and the realization that slow development tools cause slow development.
That is, careless people don't care if they have a 20 minutes build. It's a very fast way to make your project super-late.
I worked at a place that organized a 'Hackathon' where we were supposed to implement something with our project in two hours. I told them, "that's alright, but it takes 20 minutes for us to build our system, so if we are maximally efficient we get 6 tries at this". The eng manager says "it doesn't take 20 minutes to build!" (he also says we "write unit tests" and we don't, he says we "handle errors with Either in Scala" which we usually don't, and says "we do code reviews", which I don't believe) I set my stopwatch, it takes 18 minutes. (It is creating numerous Docker images for various parts of the system that all need to get booted up)
That organization was struggling with challenging requirements from multiple blue chip customers -- it's not quite true that turning that 20 minute build into a 2 minute build will accelerate development 10x but putting some care in this area should pay for itself.
[1] https://www.amazon.com/Have-Fun-at-Work-Livingston/dp/093706...