Scale or Silos Tech Wins | Generated by AI
Your observation is sharp and aligns with some of the most powerful principles in both software engineering and modern business strategy. Let’s break down your insights and explore how these principles apply to successful companies—especially in tech—and why traditional industries like banking often struggle with these concepts.
1. Design for Scale: The Power of Abstraction and Reuse
Tech Companies (TikTok, Spotify, Apple)
- Single System, Global Reach: TikTok/Douyin and Spotify use a single core platform with localized adaptations (language, content moderation, etc.), not separate apps for each country. This reduces duplication and maximizes efficiency.
- Few SKUs, Massive Impact: Apple’s product line is famously minimalist (e.g., iPhone Pro/Pro Max, SE). Fewer models mean fewer supply chains, simpler inventory, and easier updates. A single iOS update benefits all users globally.
- Software Principles: These companies treat their products like well-architected software—modular, reusable, and abstracted. A change in the core (e.g., algorithm, UI) cascades seamlessly to all users.
Banks (DBS, HSBC, etc.)
- Fragmented Systems: Banks often operate as federations of local entities, each with its own app, compliance, and tech stack. This creates silos, duplication, and inefficiency.
- Regulatory Constraints: Local laws (e.g., data sovereignty, KYC) force banks to customize heavily, but many could still abstract non-regulated features (e.g., UI/UX, core banking logic).
- Legacy Tech: Older systems are harder to refactor. Tech companies build for scale from day one; banks often bolt on new features to decades-old infrastructure.
2. Economies of Scale vs. Localization
Tech Wins with Global Platforms
- Network Effects: A single app (TikTok) or OS (iOS) means more users, more data, and better AI/ML models. Banks miss this by fragmenting their user base.
- Cost Efficiency: One team maintains one codebase. Banks pay for multiple teams to maintain similar (but slightly different) systems.
Banks’ Dilemma
- Local Trust: Users trust local banks (e.g., DBS Singapore vs. DBS China). But this doesn’t require separate apps—just localized content and compliance layers on a shared platform.
- Regulation as an Excuse: Some fragmentation is necessary, but much is cultural inertia. Stripe, for example, abstracts global payments while handling local regulations.
3. Software Principles for Business Analysis
Your analogy to software design is spot-on. Here’s how to apply it:
- DRY (Don’t Repeat Yourself): Are features/code/apps duplicated across regions? If yes, it’s a red flag for inefficiency.
- Modularity: Can the company update one module (e.g., UI, fraud detection) and deploy it everywhere? If not, their architecture is brittle.
- Abstraction: Are they solving the same problem (e.g., user onboarding) in 10 different ways? Good design abstracts the common 80% and customizes the 20%.
Example: Amazon’s global marketplace uses a single backend with localized frontends. Banks could do the same for non-regulated features (e.g., mobile banking UI).
4. Why Don’t Banks Fix This?
- Risk Aversion: Banks prioritize stability over innovation. Changing core systems is seen as risky.
- Short-term Incentives: Local managers are incentivized to “own” their market, not collaborate globally.
- Regulatory Fear: Compliance teams default to isolation, even when shared systems could meet regulations with the right design.
Key Takeaway
The most successful companies—tech or otherwise—design for reuse and abstraction. They treat their business like a software system:
- One core platform (with localized adaptations).
- Fewer, better products (like Apple’s SKU strategy).
- Changes that scale (one update benefits all users).
Banks (and other traditional industries) can adopt this mindset, but it requires:
- Leadership alignment (global > local).
- Investment in modular architecture.
- Cultural shift (from “this is how we’ve always done it” to “how can we abstract this?”).
Question for you: Are you analyzing this from an investor’s perspective, a product designer’s, or an engineer’s? Or are you brainstorming how to apply these principles to a specific industry?