There’s a natural tension between quickness and quality in early-stage product development. The faster you build a product, the sooner you can get feedback and iterate towards what users want. If you move too quickly at first, you risk the maintainability of the code and can end up spending all of your development time fighting fires due to all the shortcuts you took.

For individual engineers, this is an everyday challenge. Spend the extra hour rewriting the API now that you know what you’re building? Clean up that mess you found along the way? Or just ship it and come back to it later? Engineers should constantly prioritize the highest-impact use of their time, shipping high-quality features while avoiding overengineering.

This tradeoffs between quickness and quality is a struggle for organizations, as well. As the product surface area grows beyond what a single engineer can keep in her head, engineers need to be allocated thoughtfully to prioritize new product work against quality improvements to existing features. Deciding when to make the transition from iterating as fast as possible to architecting for the future of course depends on the organization. If a larger organization with product-market fit still allocates resources like an early-stage company, assigning engineers to projects for short stints to build new features before reallocating to higher-impact work, the quality of the codebase suffers and risks the potential for that organization to iterate going forward.

High-quality software comes with long-term ownership. If the same team is responsible for an important area of the codebase for a long period of time, that team is incentivized to make foundational improvements to enable future iteration speed and developer happiness. Without knowing that you’ll be able to reap the benefits of foundational changes, leaning yet another feature on a shaky foundation will always take priority. As a specific example, fixing a nagging bug that takes two hours of an engineer’s time each week and requires a week to fix will pay off after twenty weeks. If the team won’t own the feature for more than twenty weeks, there’s no point. If different developers are working on the same project for short periods of time, these small issues pile up and make the code impossible to reason about.

Great engineers are proud of their craft and won’t tolerate unnecessary development taxes or persistent distractions due to poorly-written code. Giving a team ownership over a codebase for a long period of time allows the to see the extent of its warts and gives them the agency to trade off those improvements over new product work to build high-quality code for the long haul.