Man, you can just feel the "thought leadership" in this one... But perhaps more constructively, I've long harbored the feeling that we are not thinking about t

Man, you can just feel the "thought leadership" in this one... But perhaps more constructively, I've long harbored the feeling that we are not thinking about the interplay between business and engineering in very useful terms. Phrases such as "tech debt", "culture of shipping" and "product-driven" seem to me to miss a larger point, which is this: there is an inescapable need for semi-undirected, exploratory work. Expecting engineers to always know where they're headed is counterproductive, I think. In my experience, time spent exploring, refactoring, "paying off tech debt" and other forms of undirected "massaging" of code are significant force multipliers, when performed in addition to planned, focused dev sprints. The reason is simple: manipulating the code base leads to a better understanding of both codebase and domain logic, which in turn leads to better sprint-planning, and therefore faster execution, but also to better products! As engineers perform minor refactors and improvements, they are developing an intuition for which parts of the codebase are pliable, and which parts resist intervention. They can use this intuition to better estimate delays, and better evaluate the utility of new tools and techniques. Once in a while, they may also discover opportunities for improvement, including new product features. The over-emphasis on "keeping focus" seems to reveal a belief that the product team should set the priorities and that engineers should execute. In some ways, this is a perfectly reasonable approach since it is obvious that the product team is better informed than the engineering team about market, customer demands, deal-flow, and other such business-facing concerns. However, it is also obvious that they are less informed about technical capabilities, i.e. about what is generally possible to do. Likewise, they are also not in a position to make accidental discoveries, and can only direct product development on the basis of known knowns. I often worry that in an otherwise sensible attempt to keep engineers focused on profitable tasks, this "product-driven" mentality stunts the ability of companies to compete, precisely by setting conditions that inexorably lead to reproducing what already exists. This is especially pernicious for (pre-)Seed and Series A companies, which need to discover their product-market fit, and make durable their differentiation, respectively. Companies like Google seem to have some (imperfect and perhaps subconscious) understanding of this, as evidenced by the now-famous 20% rule. By spending a significant chunk of time exploring, and bettering things along the way, opportunities for significant improvement are discovered, junior programmers become more familiar with infrastructure and code, the bus-factor increases, and the 80% of time spent on focused sprints becomes more productive. It's inevitable.