The most difficult engineering tasks aren't flashy UI features, but backend architectural changes. Refactoring a database schema to be more flexible is invisible to users but is crucial for long-term development speed and product scalability. Prioritizing this "boring" work is a key strategic decision.
When a startup pivots, it often adapts its existing software instead of rebuilding. This leads to a convoluted codebase built for a problem the company no longer solves. This accumulated technical debt from a series of adaptations can hobble a company's agility and scalability, even after it finds product-market fit.
Overly structured, workflow-based systems that work with today's models will become bottlenecks tomorrow. Engineers must be prepared to shed abstractions and rebuild simpler, more general systems to capture the gains from exponentially improving models.
Wiz's product team, trained at Microsoft, avoids building features that only solve for today's customer but break with tomorrow's enterprise giant. This 'infinite scale' mindset isn't about slowing down; it's about making conscious architectural choices that prevent time-consuming and costly refactoring later on.
As a company grows, its old operational systems and processes ('plumbing') become obsolete. True scaling is not about addition; it's about reinvention. This involves systematically removing outdated processes designed for a smaller scale and replacing them entirely.
Building a true platform requires designing components to be general-purpose, not use-case specific. For instance, creating one Kanban board for sales, support, and engineering. This thoughtful approach imposes a ~20% development 'tax' upfront but creates massive speed and leverage in the future.
To get product management buy-in for technical initiatives like refactoring or scaling, engineering leadership is responsible for translating the work into clear business or customer value. Instead of just stating the technical need, explain how it enables faster feature development or access to a larger customer base.
To prevent engineers from focusing internally on technical purity (e.g., unnecessary refactoring), leaders must consistently frame all work in terms of its value to the customer. Even tech debt should be justified by its external impact, such as improving security or enabling future features.
The pivot from Arc to Dia was also a cultural and technical reset. The Browser Company gave their team a "blank page," allowing engineers to build a new, faster architecture and designers to rethink the experience. This chance to fix old problems and pursue new ideas was key to getting team buy-in.
Saying yes to numerous individual client features creates a 'complexity tax'. This hidden cost manifests as a bloated codebase, increased bugs, and high maintenance overhead, consuming engineering capacity and crippling the ability to innovate on the core product.
A mentor taught Shopify's CEO that you have about two years to get an important piece of software's architecture right. After that, it's as if "cement gets poured in the codebase," making fundamental changes nearly impossible.