Platform Engineering Insights

𝗘𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗪𝗮𝗻𝘁𝘀 𝗔𝗜. 𝗡𝗼𝗯𝗼𝗱𝘆 𝗪𝗮𝗻𝘁𝘀 𝘁𝗼 𝗙𝗶𝘅 𝘁𝗵𝗲 𝗗𝗮𝘁𝗮. The funding pitch that often secures approval includes: - AI strategy - GenAI use cases - Sophisticated dashboards However, critical elements are frequently overlooked: - Data definitions - Quality checks - Metadata management - Lineage tracking - Clear ownership The truth that data engineers understand is that AI doesn't fail at the algorithm level; it falters because the data it relies on is untrustworthy. You can't construct a skyscraper on quicksand. While foundational work may not be glamorous, it is essential. It doesn't get showcased to executives or earn innovation accolades, yet it is vital for the stability of everything built above it. Before pursuing the next AI use case, consider the following: - Do we have consistent definitions? - Can we trace the origins of our data? - Who is responsible for data quality? - Are our data pipelines tested and monitored? 𝖥𝗂𝗑 𝗍𝗁𝖾 𝖻𝖺𝗌𝖾𝗆𝖾𝗇𝗍 𝖻𝖾𝖿𝗈𝗋𝖾 𝖻𝗎𝗂𝗅𝖽𝗂𝗇𝗀 𝗍𝗁𝖾 𝗉𝖾𝗇𝗍𝗁𝗈𝗎𝗌𝖾. "𝗔𝗜 𝗶𝘀 𝗼𝗻𝗹𝘆 𝗮𝘀 𝗶𝗻𝘁𝗲𝗹𝗹𝗶𝗴𝗲𝗻𝘁 𝗮𝘀 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮 𝗶𝘁'𝘀 𝘁𝗿𝗮𝗶𝗻𝗲𝗱 𝗼𝗻. 𝗚𝗮𝗿𝗯𝗮𝗴𝗲 𝗶𝗻, 𝗴𝗮𝗿𝗯𝗮𝗴𝗲 𝗼𝘂𝘁—𝗻𝗼 𝗺𝗮𝘁𝘁𝗲𝗿 𝗵𝗼𝘄 𝗳𝗮𝗻𝗰𝘆 𝘁𝗵𝗲 𝗺𝗼𝗱𝗲𝗹." Illustration inspired by John Wernfeldt

Lesson #5: Build Platforms, Not Tools. Create a Platform Advantage One of the most strategic things that a tech company can do is build a platform advantage. This creates a durable moat for a business. It also creates a built-in incentive for the market to keep coming back to you. So let’s study the concept of a Platform Advantage. A platform can bring several benefits to a business. 1. Foundation On Which Others Build Value: A platform is a foundation on top of which other players in the ecosystem build value. An example of this is application developers building apps for the iOS or Mac or Windows platform. 2. Platform Takes a Minority of the Available Economic Advantage: Typically, a great platform is built in a way that the ecosystem enjoys a large part of the economic opportunity availed by the platform. Going back to IOS or Windows, the revenue captured by all the app developers building on iOS is far greater than what Apple makes on iOS devices or what Microsoft makes on Windows. 3. Decrease in Incremental Effort: A platform advantage is defined as something where value can be realized with far less incremental effort for every subsequent addition for the user/customer. A great example of this is our Meraki platform. It started as a switching platform, but then the management plane was able to also manage cameras in the environment and people just decided to add them because the simplicity of managing everything is that much easier. 4. Sum is Greater than the Parts: The value of a good platform is always greater than the sum of the piece parts. In the security business at Cisco, we used to operate much more as a holding company. Several different products. Several different ways to use and manage the products. Each run by a General Manager. This created a disjointed experience for customers and incongruent objectives between the teams and the customer. And it didn’t take advantage of the breadth of the offering. As we built out the Cisco Security Cloud, all of this started to come together. There is a common design language, a common policy engine, a common set of policy objects, cohesion and predictability in how each component of the platform behaves, etc. Adding a new product to your environment has very low marginal effort. All the piece parts are well integrated. 5. Ecosystem Advantage: A platform delivers an ecosystem advantage. If you think of the Google ecosystem vs the Apple ecosystem, people aren’t making purchase decisions based on every small feature that gets added. When the iPhone 15 is released, only decision I make is whether to upgrade from my iPhone 14 to the newer version. What I’m not doing is evaluating the camera on the Google Pixel. That’s because I also use the Apple Watch, and the iPad and the Mac and the AppleTV and the VisionPro and iTunes and Apple News and they all work in perfect harmony with each other. The platform advantage leverages the power of the ecosystem. Net net, build platforms.

A Platform Engineering VP shared some eye-opening numbers with me yesterday: VP: "I've been trying to quantify our environment costs. We have 200 developers, each making ~5 PRs a week." Me: "How long does it take to test each change?" VP: "Average wait time for a test environment is 45 minutes. Plus another hour to run tests. Sometimes up to 3 hours if there are conflicts." *does quick math* "That's about 2000 engineering hours every week just waiting for environments and test results." VP: "Exactly. At $150/hr fully loaded engineering cost, we're burning $300K every week. But duplicating environments for faster testing would cost even more in infrastructure." This is when I shared how modern service mesh architectures are changing this equation: Instead of duplicating infrastructure, you can create instant test environments by isolating at the request level using Istio/Linkerd. Each developer gets their own "slice" of the environment through smart request routing. The numbers got interesting: - Infrastructure costs: Down 90% (sharing resources vs duplicating) - Wait times: From 45 mins to 2 mins - Test completion: From hours to minutes - Time to debug issues: Cut in half The VP's response: "So we can give every developer instant environments AND reduce costs?" This is why I'm excited about modern cloud native architectures. The ROI isn't incremental - it's transformative. Real question: How are other platform teams measuring the cost of slow testing cycles? Would love to hear your metrics. #platformengineering #devops #microservices #productivity

12 years in DevOps, and I’ll say it straight. DevOps is broken. Not in theory. In practice. It was supposed to bridge the gap between devs and ops. Instead, it created: ❌ Devs still waiting on ops. ❌ Ops still firefighting infra issues. ❌ Tool sprawl eating budgets. ❌ DevOps engineers babysitting pipelines instead of innovating. But... DevOps was never meant to be a job. 𝐈𝐭 𝐰𝐚𝐬 𝐚 𝐩𝐡𝐢𝐥𝐨𝐬𝐨𝐩𝐡𝐲. Companies misunderstood it, built "DevOps teams," and made the silos worse. Meanwhile, 𝐬𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐝𝐞𝐥𝐢𝐯𝐞𝐫𝐲 𝐠𝐨𝐭 𝐰𝐚𝐲 𝐦𝐨𝐫𝐞 𝐜𝐨𝐦𝐩𝐥𝐞𝐱: → Multi-cloud, Kubernetes, and serverless took over. → Security and compliance became non-negotiable. → Developer velocity became a business priority. That’s where 𝐏𝐥𝐚𝐭𝐟𝐨𝐫𝐦 𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠 comes. Instead of custom scripts, scattered pipelines, and ops bottlenecks… Platform teams build golden paths, 𝐬𝐞𝐥𝐟-𝐬𝐞𝐫𝐯𝐢𝐜𝐞 𝐩𝐥𝐚𝐭𝐟𝐨𝐫𝐦𝐬 𝐭𝐡𝐚𝐭 𝐥𝐞𝐭 𝐝𝐞𝐯𝐬 𝐬𝐡𝐢𝐩 𝐟𝐚𝐬𝐭𝐞𝐫 𝐰𝐢𝐭𝐡𝐨𝐮𝐭 𝐛𝐫𝐞𝐚𝐤𝐢𝐧𝐠 𝐭𝐡𝐢𝐧𝐠𝐬. ✅ Internal Developer Platforms (IDPs) remove infra complexity. ✅ Devs don’t waste time on YAML hell or Terraform nightmares. ✅ Standardization = faster, more reliable deployments. ✅ Security & compliance are baked in from day one. And the biggest shift? Platform teams treat developers as customers. 𝐃𝐞𝐯𝐬 𝐬𝐡𝐨𝐮𝐥𝐝𝐧'𝐭 𝐛𝐞 𝐟𝐢𝐠𝐮𝐫𝐢𝐧𝐠 𝐨𝐮𝐭 𝐢𝐧𝐟𝐫𝐚. 𝐓𝐡𝐞𝐲 𝐬𝐡𝐨𝐮𝐥𝐝 𝐛𝐞 𝐬𝐡𝐢𝐩𝐩𝐢𝐧𝐠 𝐜𝐨𝐝𝐞. DevOps isn’t evolving. It’s being replaced. High-performing teams are already moving to platform engineering. What’s your take? Is your company making this shift?

One of the boldest takes from AI Engineer World’s Fair 2025:  𝗪𝗲’𝗿𝗲 𝗵𝗲𝗮𝗱𝗲𝗱 𝘁𝗼 𝗮𝗻 “𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝘀𝘁𝗮𝗰𝗸 𝘄𝗵𝗲𝗿𝗲 𝗰𝗼𝗻𝘁𝗲𝘅𝘁 𝗴𝗿𝗮𝗽𝗵𝘀 + 𝘁𝗼𝗼𝗹 𝗱𝗶𝘀𝗰𝗼𝘃𝗲𝗿𝘆 𝗿𝗲𝗽𝗹𝗮𝗰𝗲 𝘁𝗼𝗱𝗮𝘆’𝘀 𝗳𝗶𝘅𝗲𝗱 𝗨𝗜𝘀; 𝗵𝗮𝗿𝗱-𝗰𝗼𝗱𝗲𝗱 𝗨𝗫 𝗮𝗻𝗱 ‘𝗔𝗣𝗜-𝘄𝗿𝗮𝗽𝗽𝗲𝗿 𝘀𝘆𝗻𝗱𝗿𝗼𝗺𝗲’ 𝘄𝗼𝗻’𝘁 𝗹𝗮𝘀𝘁.” This resonates deeply with what I’m seeing across software delivery, especially in the bigger enterprises. My take is that we’re witnessing 𝗮 𝗳𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹 𝘀𝗵𝗶𝗳𝘁 𝗮𝘄𝗮𝘆 𝗳𝗿𝗼𝗺 𝗿𝗶𝗴𝗶𝗱 𝗨𝗜𝘀 𝘁𝗼𝘄𝗮𝗿𝗱 𝗮𝗱𝗮𝗽𝘁𝗶𝘃𝗲, 𝗰𝗼𝗻𝘁𝗲𝘅𝘁-𝗮𝘄𝗮𝗿𝗲 𝘀𝘆𝘀𝘁𝗲𝗺𝘀 that dynamically compose workflows based on intent and available tools. The developer of the future won’t want to navigate predetermined menus and forms. They’ll express intent (“deploy this service with these requirements”) and have the system intelligently orchestrate the right tools and workflows, dynamically. Some shifts I believe should happen in engineering teams is: • Internal developer platforms need to evolve from static portals to intelligent orchestration layers  • Software delivery toolchains must become composable and discoverable, not just integrated  • Teams investing heavily in hard-coded workflow tools may find themselves rebuilding sooner than expected The question isn’t whether this shift will happen - it’s how quickly organizations will adapt their delivery infrastructure to support truly flexible, agentic workflows. What’s your take? Are we ready to move beyond the comfort of predictable UIs toward more adaptive systems?

I was obsessed with creating the "perfect" AI tool. Our features were cutting-edge. Our algorithms were superior. Our UI was beautiful. Back when I was building my last business on top of GPT2. And yet, adoption crawled. The painful truth emerged during a customer call. "Your tool is impressive," they said, "but integrating it into our workflow is a nightmare." That's when it hit me: we weren't in the product business. We were in the workflow business. I learned my lesson for this go around. Instead of enhancing features, we: → Built bridges to existing tools they already trusted → Created templates for specific industry workflows → Developed a community where practitioners shared implementation strategies → Focused on being the connective tissue rather than a replacement Results came quickly. And things really took off when we stopped trying to be a standalone solution and started becoming part of our customers' ecosystem. We're entering what I call The Great Convergence - a post-product world where: → Distribution outweighs invention → Trust matters more than features → Execution systems beat standalone products This isn't just happening in AI. Look at the success of Salesforce (platform, not product), Stripe (financial infrastructure, not payment tool), or Figma (collaboration system, not design app). The pattern is clear: successful companies don't just make tools; they orchestrate systems. And it's an open secret that large companies are very well positioned because they also have the distribution advantage Now I'm building differently. I identify workflows where I have deep domain expertise, nurture communities of practice around those workflows, and develop multi-product portfolios that support nuanced integration. The biggest winners in this new landscape won't be those who build the most advanced technology. They'll be those who create the most trusted systems for putting that technology to work. In the era of convergence, being the glue is more valuable than being just another brick. #startups #founders #growth #ai — Hi, I'm Oliver — I help B2B founders build a repeatable GTM motion. Consistency and quality are the first things to go during busy times in the founder-led sales motion. If you're drowning in busy work or getting lost in the noise of AI tooling, DM me!

𝗧𝗵𝗲 𝗧𝗿𝘂𝘀𝘁 𝗚𝗮𝗽 𝗶𝗻 𝗘𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 𝗧𝗲𝗰𝗵 In my 12 years work experience I learned one fundamental truth... New technology in the enterprise world rarely fails because of the tech itself. It fails because of a lack of trust. Whenever we evaluated new solutions, technical performance was merely the "ticket to play." The factors that actually decided whether a project moved forward were far more strategic: 1️⃣ Auditability: Can we fully audit the system’s decisions? 2️⃣ Data Sovereignty: Who controls the data flows at every touchpoint? 3️⃣ Business Continuity: What happens if the provider disappears from the market? 4️⃣ Governance: Does it align with our strict compliance frameworks? These are the exact questions boards and CEOs are asking about AI right now—and frankly, most AI providers don’t have clear answers yet. The winners of the next decade won't be the companies with the flashiest demos. They will be the providers who treat Trust and Compliance as a core feature, not a patch added after the fact. What has been the biggest hurdle for adopting new technology in your organization?

Business value vs. platform health? It’s not either-or. It’s a portfolio strategy. Over the years, I’ve seen companies take on massive multi-year re-platforming efforts. These usually succeed in launching a shiny new platform...But at what cost? 1️⃣ The business is often set back significantly during the transition. 2️⃣ The new platform rarely delivers the features the business actually needed when the effort was launched - requirements were lost in translation, subject matter experts left and knowledge lost, context was missing. 3️⃣ Worse, the team stopped learning. No customer feedback for years, no iteration, and by the time the platform is done, the market has changed. On the flip side, I’ve also seen what happens when platform health is ignored: Customer satisfaction is impacted with more disruptions and incidents. Tech debt grows while the work slows down. Less productivity from engineering and product teams. Morale dips. Velocity drops. Less experimentation. Growth stalls as competitors move faster and better. That’s why I approach this challenge like a portfolio. 📊 Most of the investment should go toward delivering business value. That should NEVER stop. 🔧 But 20–30% must be consistently allocated to platform modernization, platform health, engineering excellence, and reducing technical debt with consistent incremental delivery Neglecting that part of the portfolio doesn’t just build up future risk — it quietly erodes your ability to move fast and deliver impact. It's not a tug-of-war between tech and business. It’s about investing wisely in both — today and for the long run.

The Untapped Risk in Marketplace-First Brands... Marketplace Dependency Risk — and it quietly compounds as you scale. Here’s the math: 1️⃣ Topline Fragility  If 70–80% of your revenue comes from Amazon, Flipkart, or Myntra... One algorithm tweak, penalty, or policy shift — and your revenue can drop by 30–40% overnight. 2️⃣ Pricing and Margin Squeeze  Marketplaces push for discount parity.  They want the lowest prices and commissions.  You can’t easily raise prices, but your costs (logistics, returns, ads) keep rising quietly. Margin compression isn't a phase. It's structural. 3️⃣ No Consumer Ownership  Even after selling 10,000+ units, you don’t own the customer data.  You can’t remarket. You can’t build loyalty.  You are permanently renting traffic—on someone else’s terms. 4️⃣ Working Capital Traps  Longer payment cycles + return risks = working capital nightmares.  Every rupee stuck in the system delays scale. 5️⃣ Exit Valuation Hit  Brands with over 60% marketplace dependence often get lower valuations.  Investors penalize the "platform risk" by adjusting down the revenue multiple. This is the advice I've seen the smart founders share: - Balance marketplace sales with your own website D2C channel. - Invest in brand-building early—even when marketplace sales look tempting. - Build retention engines (email, WhatsApp) off-platform. - Negotiate smarter platform deals once you have leverage. 📌 What's one thing a founder should do to de-risk their channel dependence? Picture - Inc42 FAB MAVEN

The belief that a data platform can align every team around a single source of truth is a mirage. Few initiatives inspire as much hope (and confusion) as the promise of “self-service data.” The vision is simple and seductive: a clean, centralised platform where every department can access, interpret, and act on the same data. Try to execute on this vision, however, and the challenges multiply. Just ask a product manager, a compliance officer, and a marketing analyst what a "customer" is and you will receive three answers—each internally coherent, mutually incompatible, and passionately defended. When asked to reconcile these views, they won't hesitate: "We are different." They are not wrong. Departments truly do require distinct lenses on shared data. Legal obsesses over provenance. Sales demands immediacy. Finance prizes certainty. The mistake lies not in the insistence on difference, but in what we allow that difference to justify. What begins as reasonable adaptation ends in architectural entropy: shadow pipelines, contradictory dashboards, duplicated metrics, and bitter territory disputes over who owns the "real" number. This poses a problem for data leaders trained to think like engineers. The natural instinct is to standardise. But unlike roads or power grids, data is not merely infrastructure—it is interpretation. It is shaped by the questions people ask, not just the tools they use. That makes universal definitions elusive. Every attempt to impose them meets resistance, and usually for good reason. The alternative is not surrender, but strategy. If the data itself cannot always be standardised, the meaning of the data must be. That is the job of metadata. Properly understood, metadata is not a footnote—it is a language of reconciliation. It tracks who defined a metric, how it was calculated, what it is used for, and why. It allows different departments to see through their own lens without losing sight of the common frame. It does not eliminate difference—it codifies it, making it legible and accountable. Investing heavily in metadata does not lend itself to grand pronouncements or flashy dashboards. It is slow, incremental, often thankless. But it is the only way to preserve departmental autonomy without descending into chaos. It accepts that data strategy is not about enforcing uniformity, but about enabling coherence in a pluralistic environment. The future of data is not centralisation or unification, but coordination. The secret is not to silence the differences, but to learn to describe them precisely. In data, as in diplomacy, peace comes not from sameness, but from mutual intelligibility.