There are questions with power. They are rare and challenge you to think deep. The question, "Why can't this be done sooner?" by Larry Page is one of them. It makes you deeply understand the approach you're taking, question it, find the gaps in your knowledge, and analyze the risks better so that you make an informative decision while moving faster. Yet, it doesn't ask to reduce the project's quality or scope; it's purely focused on understanding the limitations.
Fast-moving companies often neglect to grasp the reasons why things take longer than managers imagined. Managers tend to lower-estimate a software project than software engineers because they don't have sufficient information or technical limitations are not so obvious.
The limitations often play a significant role in software development. One of the biggest debates is in quality vs. speed. While engineers want to deliver high-quality software, the product manager wants to deliver new features faster to compete in the market. However, it's challenging to achieve both at once. But once we know the limitations and risks, it's easier to make decisions and deliver faster with quality.
Uncovering risks and filling the knowledge gaps shape the prioritization strategy and how to break down tasks. All software features and projects have multiple ways to split the work and deliver. Engineers can divide tasks according to the technical- or domain-driven design. Both strategies offer many different ways to build software. Finding out which one to use requires awareness of risks.
Let's think about the domain-driven approach. When the software team goes with a domain-driven approach, they split the problem into user journeys and business domain requirements instead of technical layers. We can think of each following box as one part of the domain requirements.
Sometimes the best solution, and often preferred one, is straightforward, following one block after another to build value to the customers and company.
A straightforward way satisfies all requirements. But when we want to deliver the project faster and ask, "Why can't this be done sooner? Why not?" we are forced to think of both alternative approaches and risks we currently have in our design. Once we identify them, we can choose another path and remove the risky or unnecessary blocks.
Despite the question, sometimes there is no change in the result at all. If we're able to answer with "Because of the reason X and dependency Y that we have no other choice," we're acting mindfully. The question makes us to clearly see our risks and limitations and communicate them to other people.
If there is a risk that we're hesitant to take, we're focusing on different strategies to mitigate the risks. The question doesn't give any hint for changing the direction to another way. To answer it, we need to truly understand why can't we do the job in any other way. Thinking about alternatives pushes us to focus on the problem rather than blindly loving the solution.
When we focus on delivering early and understand the risks clearly, the situation creates psychological safety. Early and smaller wins motivates us and increases dopamine in our body. Knowing risks and impediments early and act accordingly help reduce stress. As a result of delivering early, learning from users fast enables us to decrease the size of failures that might lead to stress and burnout.
The question is useable by both engineers and managers. While it provides managers the context and reasoning about the limitations, it also helps engineers understand the gaps in their knowledge and nudges them to look for other ways or strategies to break down the project to reduce risks.