Platform Engineering Insights

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

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.

I’ve been giving some thought to what’s next in software delivery, and this stat stood out to me: Forrester predicts that in 2025, half of enterprises will abandon individual software tools for DevOps platforms. I’ve seen this coming for a long time. Right now, the average developer is asked to manage 14 different vendor tools. This context-shifting between different interfaces, workflows and licenses leads to confusion, cognitive overload and lack of consistency in development. I’d argue that behind many of the recent high-profile software outages around the world is an unchecked proliferation of tools and overburdened developers. All of this points to the need for a robust, integrated platform that brings the tools developers need together in one place. Freed from managing multiple vendor relationships, teams can focus on making the development process more efficient. Critically, however, all of the solutions need to be best of breed. Developers aren’t forgiving and would rather build their own tools than use inferior ones. I’d like to hear from others on this. Is tool proliferation getting out of hand? Is platform engineering the way forward? I go into more depth on this and other developer experience trends in my latest article for Fast Company: https://bit.ly/4hHEFX9

To predict what’s next, we believe you have to see the present so clearly that the future becomes inevitable. Amid this generational platform shift with AI, we set out to examine how past tech cycles unfolded, and what they reveal about the road ahead. Three patterns we believe matter most: • Winners weren’t just tech innovators, they were business model pioneers. The most successful companies didn’t just ride the mobile or early internet waves, they mastered the business models inherent to those waves, entrenching market positions that proved nearly impossible to challenge. • Tomorrow belongs to the Architects of Experience. With commoditized APIs and increasingly interchangeable models, the edge no longer lies in technical building. It lies in assembling, refining, and creating emotional connection. • AI is no longer just the tool, it is becoming the business model. The next dominant models won’t be static systems. They’ll be dynamic, responsive organisms that learn, adapt, and evolve with every interaction, making switch costs tremendously high. At Forerunner, we’ve always focused on the intersection of shifting consumer behavior and business model evolution. That framework holds, even as the inputs change. Today, those stakes feel higher and more exhilarating than ever. We’ve been thinking deeply about what kinds of founders and companies are poised to lead in this new era. To kick off the conversation, we’re sharing this white paper that looks back at the platform shifts of the past to see what they tell us about tomorrow. Introducing: The Architects of Experience. https://lnkd.in/emh7Ze69

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.

Gartner's 2024 Top Strategic Tech Trends in #SoftwareEngineering just dropped! Based on analyzing client inquiries on software engineering, the top trends we've identified are: - Software Engineering Intelligence: Tools that measure developer productivity and developer experience are increasingly used, especially to measure to impact of generative AI on productivity and DevEx. - AI-Augmented Development: We project that by 2028, 75% of enterprise software engineers will use AI coding assistants, up from less than 10% a year ago. However, AI-augmented development goes beyond coding assistants, and now covers requirements analysis, testing, and refactoring. - Green Software Engineering: Green software engineering helps leaders to deliver mission-critical software in a sustainable way. This can include using more energy-efficient languages such as Rust, or an Internal Developer Portal which helps developers make energy-aware choices. - Platform Engineering: No surprise here, since this has been a top trend for a number of years now. But we hear our clients questioning the ROI of platform engineering more closely, as it moves beyond the peak of the Hype Cycle. - Cloud Development Environments: These provide remote, ready-to-use access to a hosted development environment. This decoupling of the development workspace from the physical workstation enables a low-friction, consistent developer experience and faster developer onboarding. Cloud Development Environments are a new entry in our Top Trends for Software Engineering for 2024, and it will be interesting to chart their progress. Congratulations to Joachim Herschmann, Manjunath (Manju) Bhat , Frank O'Connor, Arun Batchu, and Bill Blosen for leading this report. Gartner clients can access the full report here: https://lnkd.in/enkQvyas [Gartner subscription required]

Platform partnerships in AI just got more complex. 🤔 Windsurf's recent challenge with Anthropic limiting their direct access to Claude models highlights a critical lesson for any B2B SaaS company building on third-party AI platforms: your strategic partnerships can make or break your competitive position. Here's what's particularly interesting from a business strategy perspective: 🎯 Market positioning matters: While Cursor, Devin, and GitHub Copilot received direct Claude 4 access at launch, Windsurf didn't - despite being a major player in the AI coding space. This wasn't just a technical decision; it's a strategic one. 💡 Platform risk is real: Windsurf built their business to $100M ARR, but now faces the classic platform dependency challenge. When your core product relies on external APIs, you're essentially building on someone else's foundation. 🔄 Competition drives innovation: Anthropic launching Claude Code and investing in their own coding applications shows how platform providers increasingly compete with their own ecosystem partners. Having scaled SaaS by carefully managing platform relationships, I've learned that diversification isn't just smart—it's survival. The companies that thrive are those who: ✅ Build multiple vendor relationships ✅ Invest in platform-agnostic architectures ✅ Maintain direct user value beyond platform dependencies For founders in the AI space: How are you preparing for platform risk? Are your strategic partnerships diversified enough to weather changes in access or pricing? The AI landscape moves fast, but strategic thinking about platform dependencies moves even faster. 🚀 Read more: https://lnkd.in/gQdHZ9HR

𝗜𝗳 𝘆𝗼𝘂𝗿 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺 𝗶𝘀𝗻’𝘁 𝗿𝗼𝗰𝗸 𝘀𝗼𝗹𝗶𝗱, 𝗶𝘁 𝗱𝗼𝗲𝘀𝗻’𝘁 𝗺𝗮𝘁𝘁𝗲𝗿 𝗵𝗼𝘄 𝗴𝗼𝗼𝗱 𝘆𝗼𝘂𝗿 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗶𝘀—𝘆𝗼𝘂𝗿 𝗳𝘂𝘁𝘂𝗿𝗲 𝗿𝗲𝗰𝗮𝗹𝗹𝘀 𝗮𝗿𝗲 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗲𝗱. —𝘮𝘺 𝘱𝘦𝘳𝘴𝘰𝘯𝘢𝘭 𝘷𝘪𝘦𝘸; 𝘰𝘱𝘪𝘯𝘪𝘰𝘯𝘴 𝘢𝘳𝘦 𝘮𝘺 𝘰𝘸𝘯. Two decades in embedded software—half of them deep inside ECUs—taught me a brutal truth: 𝘗𝘭𝘢𝘵𝘧𝘰𝘳𝘮 𝘤𝘳𝘢𝘤𝘬𝘴 𝘴𝘶𝘳𝘧𝘢𝘤𝘦 𝘢𝘵 𝘩𝘪𝘨𝘩𝘸𝘢𝘺 𝘴𝘱𝘦𝘦𝘥, 𝘥𝘳𝘦𝘴𝘴𝘦𝘥 𝘢𝘴 𝘩𝘦𝘢𝘥𝘭𝘪𝘯𝘦𝘴 𝘢𝘯𝘥 𝘸𝘢𝘳𝘳𝘢𝘯𝘵𝘺 𝘣𝘪𝘭𝘭𝘴.  • A single thread-starved daemon can turn elegant code into a roadside assistance ticket.  • Integration blind spots inflate warranty costs faster than batteries charge.  • Shiny apps can’t mask an unstable boot chain or unsynced clocks. According to NHTSA, 𝗼𝘃𝗲𝗿 𝟯𝟬 % 𝗼𝗳 𝘃𝗲𝗵𝗶𝗰𝗹𝗲 𝗿𝗲𝗰𝗮𝗹𝗹𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗽𝗮𝘀𝘁 𝘁𝗵𝗿𝗲𝗲 𝘆𝗲𝗮𝗿𝘀 𝘄𝗲𝗿𝗲 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲-𝗿𝗲𝗹𝗮𝘁𝗲𝗱. The pattern is clear: great features built on shaky foundations end up on car carriers back to the dealership. 𝗧𝗵𝗲 𝗮𝗻𝘁𝗶𝗱𝗼𝘁𝗲  1. Harden the handshake    RTOS ↔ hypervisor ↔ middleware must survive heat soak, voltage drops, and Murphy’s Law.  2. Automate brutality    Platform validation in every CI run—stress, fault-injection, timing. No green build, no merge.  3. Shift left & lock safety in    Treat safety, security, and performance as a single non-negotiable spec. Before your next sprint adds a voice assistant, run a ruthless platform health check. If the core trembles, your customer will feel the quake. #SoftwareDefinedVehicle #AutomotiveSoftware #PlatformFirst #ShiftLeft #QualityEngineering

Platform Engineer != Cloud Engineer != DevOps Engineer Time to clear this up — once and for all. Job posts might blur them together, but if you want clarity, here it is. Cloud Engineers: → Build, manage, and optimize cloud infrastructure → Handle networking, security, resource provisioning within a cloud/multi-cloud/hybrid setup → Focus on platform scalability and cost-efficiency DevOps Engineers: → Streamline development pipelines via CI/CD → Automate deployments and manage IaC → Own monitoring, logging, and feedback loops → Bridge the dev–ops collaboration gap Platform Engineers: This is where things get interesting. Platform Engineers build Internal Developer Platforms (IDPs) — custom-built platforms (or you can call it internal tools) designed to abstract infrastructure and streamline developer workflows. Their role? → Provide golden paths for developers (secure, standardized workflows) → Build self-service capabilities (deployments, environments, observability) → Standardize tools and workflows across teams → Improve developer experience (DX) and velocity Platform Engineering sits on top of Cloud and DevOps practices — but it’s not just an intersection. It’s an enablement layer. The key distinction: Cloud = Infrastructure layer DevOps = Process layer Platform Engineering = Enablement layer for developers As companies scale, platform engineering becomes critical for reducing cognitive load on dev teams and ensuring consistency across the SDLC. What’s your take? • • • I regularly share bite-sized insights on Cloud & DevOps (through my newsletter as well) — if you're finding them helpful, hit follow (Vishakha) and feel free to share it so others can learn too! Image Source: Tech World with Nana

I first heard the term “platform thinking,” and thought it was a reference to some abstract Porter strategy framework (scars from 5 forces, lol). I eventually found myself in the platform PM trenches and learned the true, beautifully messy, meaning along with a series of lessons. Here are 3 things I’ve learned the hard way while building large-scale platforms for content, marketing, and digital experiences: 1. A platform is only as good as the people who (actually) use it. Build the most elegant architecture in the world—but if creators, marketers, and engineers don’t want to use it, it’s just an expensive ghost town. Adoption isn’t a phase or an afterthought; it’s the job. 2. Governance sounds boring until chaos shows up. Taxonomy, metadata, roles, and workflows don’t get standing ovations… until you discount them and end up with 6 versions of the same asset in 8 tools — all unpublished and unused. 🙃 3. Good platform leaders obsess over UX, not infrastructure. You’re not just building APIs and systems—you’re building trust. The real product is how people interact with it, how decisions get made, and how quickly teams get what they need. I don’t know who needs to hear this, but if you’re building (or rebuilding) platforms, I salute you: It’s unglamorous and not always sexy. Yet, it’s critical work that, when done right, quietly powers everything. What’s your favorite lesson from building platforms at scale?