I’m thinking of two orgs that did cloud by oh shit lift and shift and then rebuilt everything with more cloud-native architectures. The first org planned and executed that rebuild as a company-wide effort. They mandated, “We will all focus all our effort on doing this The Right Way (TM)” and didn’t ship a new feature for many years. Eventually they ended up purchased by a larger org. The second one did the rebuild piecemeal, shifting components where opportunities arose, and continued to make new stuff all along. The full exercise also took many years to complete, but the product improved in depth and breadth every quarter. They’re now fully switched and have a much lower Operational Expenditure level per customer (hence much better gross margin, hence better business). Better! Except, here’s the funny thing: doing better at SaaS hasn’t made org two as wildly successful as org one was, or as some of its better-known competitors in the same space. Doing better at SaaS has kept them alive instead of making them excel. Maybe architectural choices don’t matter as much as we think?
If the business is a vehicle, the product architecture is analogous to its design. How much energy does it cost to move the car down the road for a mile? One design is much less efficient than another. But, I could also buy half a dozen vans for the price of one entry-level Lucid, and the lower operational costs of the sedan will take a very long time to make a difference to total cost of ownership. TCO is also very sensitive to sunk cost. If you’ve already got an oil-burning trash heap of a van with three blown cylinders that makes 8 miles per gallon with a downhill slope and a tailwind, but you don’t have the money for a new electric sedan, the van is the vehicle you’ll drive.
Poor technical choices are a drag on the company. But does that matter? It depends on your size. Sure, a default alive company that’s achieved product market fit and scale has a lot of energy and momentum, but a default dead startup trying to find PMF doesn’t. So why wouldn’t you do the most efficient and elegant architecture available? Solar car instead of Project Orion (nuclear propulsion)? The answer is, “you don’t know yet what you’ll need.” Because market fit doesn’t exist yet, you don’t really know who your customers are or what products they need. You’re just comparing yourself with established companies, and that’s a mistake because you’re not Google. Poorly considered architecture can be deadly to a startup.
On the other hand, an established business can handle a whole lot of drag. Speaking of Google, how many moonshots has its search business supported for how long? Even now, with Google’s search business starting to slip, they’re able to afford ballooning the cost of each search with an AI summary. Eventually drag becomes a problem that has to be fixed, but multinational corporations with monopoly positions can go decades without dealing with their fundamental issues. Executives might not like it, but without great legibility into their own complex organizations, leaders at bigger companies are just as likely to hurt the organization when trying to fix it. Is the effort of replacing an existing architecture going to improve margins sufficiently to open a new business opportunity, such as expanding from enterprise-only into mid-sized businesses? Can the non-engineering parts of the company adjust to that new reality and build the correct go-to-market machines to find fit with that new product in the new market that’s available? If not, it might only be an internally motivated exercise.
Monkeynoodle.Org 