Take a close look:
There! A picture paints a thousand words, don't they say? Well, don't take this chart at face value, it's just an illustration, but of very specific things.
The first case (line passing at the bottom of the striped area) represents the case, where you start out carefully, adopt proper patterns and practices, devote the necessary amount of time to plan ahead and design. You avoid technical debt by spending an additional small amount of time to pay it off "at birth", so that you don't accumulate "interest".
The second case (line passing at the top of the striped area) represents the case, where you start out carelessly under much pressure, so you need results now, and cleanup later. In that case, no matter how experienced you and your team are, all you can do is just keep the interest on the technical debt down. But it accumulates as time goes by.
I am focusing on these cases because you seem to fall under the second case. I would go as far as to say that this is a rather typical "deal" with startups. You either take time (and resources) to shine, or you get results fast, and pay for them later (but at least you still have your job).
The point is as simple as this: Given any starting point, there is a critical instant in the future, from which point on you will begin suffering from having seriously hampered your productivity by having ignored "research" (really a buzzword for just taking the time to reduce your technical debt or avoid it all along). Accordingly, of course, while you are ignoring "research", you will be getting more work done for a while, but this period is not everlasting. This fact is represented by the orange-y striped area in the chart above.
No matter how hard one may bang their head on a wall, there is no getting around this fact. Technical debt accumulates interest. A problem that takes x hours to fix now, takes y >= x hours to fix later, with the ">" being far more probable and the difference growing with time.
All there is to do, then, is to make serious considerations, whether this critical time in the future is closer, or not, than some extremely important deadline. If you are going to handicap your future productivity, you must have very good rea$on$ to do so! Think something along the lines of an all-or-nothing deal, for example.
Keep in mind that ignoring research may, at times, be the "wise" thing to do. For example, your company may be in need of resources, which are expected to come before t-critical, but definitely not later. So, painful catching-up is often better than no company at all.
This is the hard stuff the managers have to handle, of course, so it's their call, but they need to understand the facts very well. Maybe if you gave it a little thought, you could approximate some actual numbers in there and discuss with your manager using these numbers about how you are beyond this critical instant in time and you are constantly preparing for ever lowering productivity rates.
If your manager takes time to, at least, pay attention to what you say/show, some catchy chart might get the point along far better than any amount of spoken words.
Update
Due to some of the comments raising new questions, it needs to be stated that the chart above is just a(n overly) simplistic approximation. Estimating the approximate location of this t-critical instant is a very hard problem, but is not the problem we are usually trying to solve (this is, according to the single-responsibility principle, a problem of Management). What we should strive for is to know which side of the temporal axis we are at, with respect to this instant, at some given time.
Also, this chart simply represents what Management needs to know: "If we ignore investigation ****, research (and all other keywords, which are just aliases for proper code housekeeping), we will never become as good as we could have been if we just spent a little more time in the beginning". If one of the ambitions/goals/necessities for the company is a highly flexible and high-performance tech team, given the current codebase/product state, they might just as well drop it sooner instead of wasting more resources on a lost case.
Based on that, the dialog could be like this:
- See this 1st line high above, "Peak productivity with research"? That is where we will probably never be even close to.
- See this 2nd line below, "Peak productivity without research"? This is where we will be at best, that is, if we are lucky. Don't try to measure this in metric units, the vertical scale is shrunk by multiple orders of magnitude!
- If the survival of the company depends on being "viably" above the lower line, we should simply call it off now that we can, to save resources, and start considering different career opportunities.
The way we are heading right now, we are past t-critical, so, in order to even be able to climb above the 2nd line at some point in the future, we need to work very hard to first repay the virtual work gains represented by the orange-line-striped area, and then strive to slowly translate the gained productivity benefits to an amount of work that is sizable enough to deliver.
Note that by "virtual work gains", I mean that doing more work then was like stealing that work from the future. Can you imagine how much better our life would be if we had an extra 10 minutes of productive time each day? Well, going to work in our underwear would offer us those 10 minutes of additional productivity. This is precisely what was done. Not dressing up is not a good way to save time from your work, I hope you follow the analogy and the metaphor.
By the way, it is not enough to be adequately productive, you also have to keep in mind the amount of work needed to be carried out have been carried out at any time. This is represented by deadlines! Either you move the next planned deadlines to get time for recovery, or we all go home...not now, of course, but a few deadlines from now, when catching a deadline will require productivity that is far above that 2nd line on the chart... the one that we will never reach if we keep going like that...
