[{"data":1,"prerenderedAt":602},["ShallowReactive",2],{"/en-us/the-source/authors/bryan-ross/":3,"footer-en-us":35,"the-source-navigation-en-us":343,"the-source-newsletter-en-us":370,"bryan-ross-articles-list-authors-en-us":382,"bryan-ross-articles-list-en-us":413,"bryan-ross-page-categories-en-us":601},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"config":8,"seo":10,"content":12,"type":27,"slug":28,"_id":29,"_type":30,"title":11,"_source":31,"_file":32,"_stem":33,"_extension":34},"/en-us/the-source/authors/bryan-ross","authors",false,"",{"layout":9},"the-source",{"title":11},"Bryan Ross",[13,25],{"componentName":14,"type":14,"componentContent":15},"TheSourceAuthorHero",{"config":16,"name":11,"role":20,"bio":21,"headshot":22},{"gitlabHandle":17,"twitterXProfileUrl":18,"linkedInProfileUrl":19},"bryanrossuk","https://twitter.com/bryanrossuk","https://www.linkedin.com/in/bryanross","Field CTO","With over 15 years of industry experience as a senior IT leader, Bryan helps customers realize business value from IT faster. Equally comfortable speaking with executives and engineers alike, he bridges the gap between technical and business stakeholders through compelling storytelling and real-world examples. With a knack for delivering authentic, impactful messages, he enjoys helping others at the intersection of technology, people and process.",{"altText":11,"config":23},{"src":24},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463324/mvdyvskii4hltdrgqxom.jpg",{"componentName":26,"type":26},"TheSourceArticlesList","author","bryan-ross","content:en-us:the-source:authors:bryan-ross.yml","yaml","content","en-us/the-source/authors/bryan-ross.yml","en-us/the-source/authors/bryan-ross","yml",{"_path":36,"_dir":37,"_draft":6,"_partial":6,"_locale":7,"data":38,"_id":339,"_type":30,"title":340,"_source":31,"_file":341,"_stem":342,"_extension":34},"/shared/en-us/main-footer","en-us",{"text":39,"source":40,"edit":46,"contribute":51,"config":56,"items":61,"minimal":331},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":41,"config":42},"View page source",{"href":43,"dataGaName":44,"dataGaLocation":45},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":47,"config":48},"Edit this page",{"href":49,"dataGaName":50,"dataGaLocation":45},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":52,"config":53},"Please contribute",{"href":54,"dataGaName":55,"dataGaLocation":45},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":57,"facebook":58,"youtube":59,"linkedin":60},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[62,89,162,230,292],{"title":63,"links":64,"subMenu":70},"Platform",[65],{"text":66,"config":67},"DevSecOps platform",{"href":68,"dataGaName":69,"dataGaLocation":45},"/platform/","devsecops platform",[71],{"title":72,"links":73},"Pricing",[74,79,84],{"text":75,"config":76},"View plans",{"href":77,"dataGaName":78,"dataGaLocation":45},"/pricing/","view plans",{"text":80,"config":81},"Why Premium?",{"href":82,"dataGaName":83,"dataGaLocation":45},"/pricing/premium/","why premium",{"text":85,"config":86},"Why Ultimate?",{"href":87,"dataGaName":88,"dataGaLocation":45},"/pricing/ultimate/","why ultimate",{"title":90,"links":91},"Solutions",[92,97,102,107,112,117,122,127,132,137,142,147,152,157],{"text":93,"config":94},"Digital transformation",{"href":95,"dataGaName":96,"dataGaLocation":45},"/topics/digital-transformation/","digital transformation",{"text":98,"config":99},"Security & Compliance",{"href":100,"dataGaName":101,"dataGaLocation":45},"/solutions/security-compliance/","security & compliance",{"text":103,"config":104},"Automated software delivery",{"href":105,"dataGaName":106,"dataGaLocation":45},"/solutions/delivery-automation/","automated software delivery",{"text":108,"config":109},"Agile development",{"href":110,"dataGaName":111,"dataGaLocation":45},"/solutions/agile-delivery/","agile delivery",{"text":113,"config":114},"Cloud transformation",{"href":115,"dataGaName":116,"dataGaLocation":45},"/topics/cloud-native/","cloud transformation",{"text":118,"config":119},"SCM",{"href":120,"dataGaName":121,"dataGaLocation":45},"/solutions/source-code-management/","source code management",{"text":123,"config":124},"CI/CD",{"href":125,"dataGaName":126,"dataGaLocation":45},"/solutions/continuous-integration/","continuous integration & delivery",{"text":128,"config":129},"Value stream management",{"href":130,"dataGaName":131,"dataGaLocation":45},"/solutions/value-stream-management/","value stream management",{"text":133,"config":134},"GitOps",{"href":135,"dataGaName":136,"dataGaLocation":45},"/solutions/gitops/","gitops",{"text":138,"config":139},"Enterprise",{"href":140,"dataGaName":141,"dataGaLocation":45},"/enterprise/","enterprise",{"text":143,"config":144},"Small business",{"href":145,"dataGaName":146,"dataGaLocation":45},"/small-business/","small business",{"text":148,"config":149},"Public sector",{"href":150,"dataGaName":151,"dataGaLocation":45},"/solutions/public-sector/","public sector",{"text":153,"config":154},"Education",{"href":155,"dataGaName":156,"dataGaLocation":45},"/solutions/education/","education",{"text":158,"config":159},"Financial services",{"href":160,"dataGaName":161,"dataGaLocation":45},"/solutions/finance/","financial services",{"title":163,"links":164},"Resources",[165,170,175,180,185,190,195,200,205,210,215,220,225],{"text":166,"config":167},"Install",{"href":168,"dataGaName":169,"dataGaLocation":45},"/install/","install",{"text":171,"config":172},"Quick start guides",{"href":173,"dataGaName":174,"dataGaLocation":45},"/get-started/","quick setup checklists",{"text":176,"config":177},"Learn",{"href":178,"dataGaName":179,"dataGaLocation":45},"https://university.gitlab.com/","learn",{"text":181,"config":182},"Product documentation",{"href":183,"dataGaName":184,"dataGaLocation":45},"https://docs.gitlab.com/","docs",{"text":186,"config":187},"Blog",{"href":188,"dataGaName":189,"dataGaLocation":45},"/blog/","blog",{"text":191,"config":192},"Customer success stories",{"href":193,"dataGaName":194,"dataGaLocation":45},"/customers/","customer success stories",{"text":196,"config":197},"Remote",{"href":198,"dataGaName":199,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":201,"config":202},"GitLab Services",{"href":203,"dataGaName":204,"dataGaLocation":45},"/services/","services",{"text":206,"config":207},"TeamOps",{"href":208,"dataGaName":209,"dataGaLocation":45},"/teamops/","teamops",{"text":211,"config":212},"Community",{"href":213,"dataGaName":214,"dataGaLocation":45},"/community/","community",{"text":216,"config":217},"Forum",{"href":218,"dataGaName":219,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":221,"config":222},"Events",{"href":223,"dataGaName":224,"dataGaLocation":45},"/events/","events",{"text":226,"config":227},"Partners",{"href":228,"dataGaName":229,"dataGaLocation":45},"/partners/","partners",{"title":231,"links":232},"Company",[233,238,243,248,253,258,263,267,272,277,282,287],{"text":234,"config":235},"About",{"href":236,"dataGaName":237,"dataGaLocation":45},"/company/","company",{"text":239,"config":240},"Jobs",{"href":241,"dataGaName":242,"dataGaLocation":45},"/jobs/","jobs",{"text":244,"config":245},"Leadership",{"href":246,"dataGaName":247,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":249,"config":250},"Team",{"href":251,"dataGaName":252,"dataGaLocation":45},"/company/team/","team",{"text":254,"config":255},"Handbook",{"href":256,"dataGaName":257,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":259,"config":260},"Investor relations",{"href":261,"dataGaName":262,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":264,"config":265},"Sustainability",{"href":266,"dataGaName":264,"dataGaLocation":45},"/sustainability/",{"text":268,"config":269},"Diversity, inclusion and belonging (DIB)",{"href":270,"dataGaName":271,"dataGaLocation":45},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":273,"config":274},"Trust Center",{"href":275,"dataGaName":276,"dataGaLocation":45},"/security/","trust center",{"text":278,"config":279},"Newsletter",{"href":280,"dataGaName":281,"dataGaLocation":45},"/company/contact/","newsletter",{"text":283,"config":284},"Press",{"href":285,"dataGaName":286,"dataGaLocation":45},"/press/","press",{"text":288,"config":289},"Modern Slavery Transparency Statement",{"href":290,"dataGaName":291,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":293,"links":294},"Contact Us",[295,300,305,310,315,320,325],{"text":296,"config":297},"Contact an expert",{"href":298,"dataGaName":299,"dataGaLocation":45},"/sales/","sales",{"text":301,"config":302},"Get help",{"href":303,"dataGaName":304,"dataGaLocation":45},"/support/","get help",{"text":306,"config":307},"Customer portal",{"href":308,"dataGaName":309,"dataGaLocation":45},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"text":311,"config":312},"Status",{"href":313,"dataGaName":314,"dataGaLocation":45},"https://status.gitlab.com/","status",{"text":316,"config":317},"Terms of use",{"href":318,"dataGaName":319,"dataGaLocation":45},"/terms/","terms of use",{"text":321,"config":322},"Privacy statement",{"href":323,"dataGaName":324,"dataGaLocation":45},"/privacy/","privacy statement",{"text":326,"config":327},"Cookie preferences",{"dataGaName":328,"dataGaLocation":45,"id":329,"isOneTrustButton":330},"cookie preferences","ot-sdk-btn",true,{"items":332},[333,335,337],{"text":316,"config":334},{"href":318,"dataGaName":319,"dataGaLocation":45},{"text":321,"config":336},{"href":323,"dataGaName":324,"dataGaLocation":45},{"text":326,"config":338},{"dataGaName":328,"dataGaLocation":45,"id":329,"isOneTrustButton":330},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"_path":344,"_dir":9,"_draft":6,"_partial":6,"_locale":7,"logo":345,"subscribeLink":350,"navItems":354,"_id":366,"_type":30,"title":367,"_source":31,"_file":368,"_stem":369,"_extension":34},"/shared/en-us/the-source/navigation",{"altText":346,"config":347},"the source logo",{"src":348,"href":349},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750191004/t7wz1klfb2kxkezksv9t.svg","/the-source/",{"text":351,"config":352},"Subscribe",{"href":353},"#subscribe",[355,359,362],{"text":356,"config":357},"Artificial Intelligence",{"href":358},"/the-source/ai/",{"text":98,"config":360},{"href":361},"/the-source/security/",{"text":363,"config":364},"Platform & Infrastructure",{"href":365},"/the-source/platform/","content:shared:en-us:the-source:navigation.yml","Navigation","shared/en-us/the-source/navigation.yml","shared/en-us/the-source/navigation",{"_path":371,"_dir":9,"_draft":6,"_partial":6,"_locale":7,"title":372,"description":373,"submitMessage":374,"formData":375,"_id":379,"_type":30,"_source":31,"_file":380,"_stem":381,"_extension":34},"/shared/en-us/the-source/newsletter","The Source Newsletter","Stay updated with insights for the future of software development.","You have successfully signed up for The Source’s newsletter.",{"config":376},{"formId":377,"formName":378,"hideRequiredLabel":330},1077,"thesourcenewsletter","content:shared:en-us:the-source:newsletter.yml","shared/en-us/the-source/newsletter.yml","shared/en-us/the-source/newsletter",{"amanda-rueda":383,"andre-michael-braun":384,"andrew-haschka":385,"ayoub-fandi":386,"bob-stevens":387,"brian-wald":388,"bryan-ross":11,"chandler-gibbons":389,"dave-steer":390,"ddesanto":391,"derek-debellis":392,"emilio-salvador":393,"erika-feldman":394,"george-kichukov":395,"gitlab":396,"grant-hickman":397,"haim-snir":398,"iganbaruch":399,"jlongo":400,"joel-krooswyk":401,"josh-lemos":402,"julie-griffin":403,"kristina-weis":404,"lee-faus":405,"ncregan":406,"rschulman":407,"sabrina-farmer":408,"sandra-gittlen":409,"sharon-gaudin":410,"stephen-walters":411,"taylor-mccaslin":412},"Amanda Rueda","Andre Michael Braun","Andrew Haschka","Ayoub Fandi","Bob Stevens","Brian Wald","Chandler Gibbons","Dave Steer","David DeSanto","Derek DeBellis","Emilio Salvador","Erika Feldman","George Kichukov","GitLab","Grant Hickman","Haim Snir","Itzik Gan Baruch","Joseph Longo","Joel Krooswyk","Josh Lemos","Julie Griffin","Kristina Weis","Lee Faus","Niall Cregan","Robin Schulman","Sabrina Farmer","Sandra Gittlen","Sharon Gaudin","Stephen Walters","Taylor McCaslin",{"allArticles":414,"visibleArticles":600,"showAllBtn":330},[415,455,491,526,562],{"_path":416,"_dir":417,"_draft":6,"_partial":6,"_locale":7,"slug":418,"type":419,"category":417,"config":420,"seo":424,"content":428,"_id":452,"_type":30,"title":425,"_source":31,"_file":453,"_stem":454,"_extension":34,"description":426,"date":429,"timeToRead":430,"heroImage":427,"keyTakeaways":431,"articleBody":435,"faq":436},"/en-us/the-source/platform/beyond-the-portal-hype-why-you-need-a-platform-first","platform","beyond-the-portal-hype-why-you-need-a-platform-first","article",{"layout":9,"template":421,"featured":330,"articleType":422,"author":28,"gatedAsset":423,"isHighlighted":6,"authorName":11},"TheSourceArticle","Regular","source-lp-how-to-build-a-resilient-software-development-practice",{"title":425,"ogTitle":425,"description":426,"ogDescription":426,"ogImage":427},"Beyond the portal hype: Why you need a platform first","Discover why many internal developer portals fall short and why a platform-first approach is key to improving developer productivity.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752086082/z2udikxenysukvroywvb.png",{"title":425,"description":426,"date":429,"timeToRead":430,"heroImage":427,"keyTakeaways":431,"articleBody":435,"faq":436},"2025-07-15","6 min read",[432,433,434],"Most portal initiatives struggle with adoption because organizations underestimate the product management effort required for successful implementation and ongoing maintenance.","Start by building a robust platform with streamlined workflows and automation before investing in a portal interface; the value of any portal is entirely dependent on the capabilities of the underlying platform.","Consider whether tool consolidation might be more effective than integration; end-to-end solutions can simplify your ecosystem and reduce the need for the complex integrations that portals attempt to solve.","When Spotify released Backstage as an open source project in 2020, it sparked a wave of enthusiasm across the platform engineering community. The promise was compelling: a unified dashboard where developers could discover, access, and consume everything they needed to build software efficiently. Who wouldn't want a sleek “shop front” to simplify the increasingly complex world of software development?\n\nFast forward to today, and the reality has proven more complicated. Despite the initial excitement, many organizations struggle to realize the promised benefits of internal developer portals. \n\n## Portals vs. platforms: What’s the difference?\nAn internal developer portal is a “front door” to your technical ecosystem. It sits atop your developer platform, which integrates different tools to provide standardized workflows and underlying infrastructure and helps enforce governance. While the platform handles the technical implementation of tooling and automation, the portal provides a single pane of glass that makes development resources discoverable and accessible.\n\nBefore we get to the challenges around portals, it’s worth acknowledging the very real challenges they aim to address:\n1. **Discovery obstacles**: Many organizations lack an API catalog, causing developers to struggle to find existing software components, documentation, best practices, and support channels. Portals attempt to solve this by creating a centralized catalog where developers can access these resources through a unified search and navigation experience.\n1. **Tool sprawl**: The modern software development lifecycle relies on numerous specialized tools, each with its own interface and learning curve. [GitLab research](https://about.gitlab.com/developer-survey/) found that 62% of teams use six or more separate tools for software development. Portals address this by integrating these disparate tools behind a consistent interface, reducing the cognitive load of context switching.\n1. **Siloed knowledge**: Teams focused on their specific challenges often create their own workflows and toolchains, hampering cross-team collaboration and leading to duplicated work. Portals aim to break down these silos by making team assets visible across the organization and promoting standardized workflows that encourage collaboration and reuse of existing solutions.\nThese challenges have a measurable business impact: According to the [2024 GitLab Global DevSecOps Report](https://about.gitlab.com/developer-survey/), 78% of developers spend at least a quarter of their time maintaining and integrating toolchains.\n\n## Why portal initiatives often fall short\nIf internal developer portals address genuine business problems, why do these initiatives regularly fail to gain traction? In my conversations with technical leaders at companies of all sizes, I’ve noticed several key factors:\n1. **Insufficient product management**: Many organizations underinvest in release announcements, internal enablement examples, training, and other adoption-fueling activities essential for portal success.\n1. **Dependency on platform capabilities**: A portal is only as valuable as its underlying platform. Without robust platform capabilities, a portal merely presents a unified view of dysfunction.\n1. **Technical complexity**: Organizations often underestimate that a portal is not simply a tool to install but a software development framework requiring significant engineering skills to build and maintain.\n1. **Ongoing investment requirements**: Building and maintaining a portal demands substantial continuous investment, which many organizations underestimate during initial planning stages.\n1. **Limited developer resonance**: Despite being highly discussed in platform engineering circles, a recent CNCF App Development Working Group survey revealed that many developers remain unaware of Backstage — suggesting it may not address problems developers consider material to their work.\n\nThese challenges are particularly acute when building the portal’s frontend interface. A portal essentially functions as a wrapper built around existing tools, aiming to become the single source of truth for developer interactions.\n\nBut here's the catch: If your portal doesn't mirror enough of the functionality of those underlying tools, developers will bypass it and go straight to the underlying tools, making your portal just another item in an already crowded toolchain. At the same time, trying to keep up with feature changes across a dozen backend tools requires a massive ongoing effort. Every time a backend system changes or releases a new capability, the portal team faces the same question: implement, integrate, or ignore?  Providing a single pane of glass is a significant, perpetual engineering investment that most organizations underestimate.\n\n[Netflix, which has deep experience in developer tooling, puts it bluntly](https://www.youtube.com/watch?v=qgFyb28NvlQ): “A common front door for existing tools is insufficient on its own to attract and keep a user base. Rather [it] needs end-to-end experiences not available in other tools to keep users coming back and discovering the additional features and capabilities.”\n\n## The platform-first approach\nOrganizations that have successfully improved developer productivity typically follow a platform-first approach rather than beginning with a portal. Here’s what this looks like in practice:\n1. **Start with developer needs**: Don’t assume what developers need. Speak directly with teams about their challenges and work closely with them to develop solutions that demonstrably improve their day-to-day experiences.\n1. **Focus on platform capabilities first**: Prioritize creating streamlined, automated workflows for regular tasks that incorporate best practices and corporate standards. Any future portal's value will entirely depend on these underlying capabilities.\n1. **Consider tool consolidation before integration**: Portals primarily solve integration issues between tools by abstracting authentication methods and bringing data sources together. Before investing in complex integrations, evaluate whether consolidating tools might simplify your ecosystem. End-to-end solutions across the software development lifecycle can reduce the need for extensive integration work.\n1. **Invest in product management**: Ensure strong product management to encourage platform adoption by new teams and drive new capability adoption by teams who have already embraced the platform.\n\n## When portals make sense\nThis isn’t to say that internal developer portals are inherently flawed. In fact, I’ve worked with several large, mature organizations that successfully use internal developer portals like Backstage, but with a crucial difference in approach and expectations.\n\nOne large financial institution I worked with recently has had tremendous feedback from their portal implementation. Rather than trying to create a single pane of glass for all development activities, their portal was built to serve two specific workflows: developer onboarding and new project scaffolding. When a developer joins a team, the portal guides them through account setup across six different systems, automatically provisioning access based on their team assignment. For new projects, the portal provides developers with an intuitive interface to select an appropriate template and configure it to their needs. The portal then triggers the necessary backend systems to build the required project scaffolding, including an initial code repository and a CI/CD pipeline with [policy-driven testing](https://about.gitlab.com/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops/) and [infrastructure-as-code](https://about.gitlab.com/blog/using-ansible-and-gitlab-as-infrastructure-for-code/) to deploy the application.\n\nSuccessful implementations like this leverage portals for activities that genuinely benefit from a simplified point-and-click interface. The portal doesn't try to be the primary interface for all activity; developers still work directly in their IDEs, Git repositories, and monitoring dashboards.\nCritically, organizations with successful developer portals build solid, capable internal developer platforms first. They also have mature approaches to gathering developer feedback to direct their efforts to real-world points of friction.\n\n## The path forward\nThe message for technical leaders navigating the platform engineering landscape is clear: Start with a strong platform rather than focusing primarily on a portal. Prioritize creating tangible value for developers through automation, standardization, and simplified workflows. Once your platform capabilities mature and deliver measurable benefits, consider adding a portal as an enhancement if specific needs warrant it.\n\nBy taking this measured approach, you'll avoid the common pitfall of implementing a beautiful dashboard that sits atop dysfunction — and instead build developer tooling that genuinely improves productivity, reduces cognitive load, and accelerates innovation.",[437,440,443,446,449],{"header":438,"content":439},"What's the difference between an internal developer portal and a platform?","An internal developer portal is a \"front door\" interface that sits atop your developer platform. The platform handles technical implementation, tooling, and automation with standardized workflows, while the portal provides a single pane of glass that makes development resources discoverable and accessible.",{"header":441,"content":442},"How much time do developers spend on toolchain maintenance and integration?","According to the 2024 GitLab Global DevSecOps Report, 78% of developers spend at least a quarter of their time maintaining and integrating toolchains. GitLab research also found that 62% of teams use six or more separate tools for software development.",{"header":444,"content":445},"Why do internal developer portal initiatives often fail?","Portal initiatives fail due to insufficient product management, dependency on weak platform capabilities, underestimated technical complexity, ongoing investment requirements, and limited developer resonance. Many organizations underestimate that portals require significant continuous engineering investment to maintain feature parity with underlying tools.",{"header":447,"content":448},"What should organizations prioritize before building a developer portal?","Organizations should follow a platform-first approach: start with developer needs assessment, focus on platform capabilities with streamlined automated workflows, consider tool consolidation before integration, and invest in strong product management for adoption. Build robust platform capabilities before adding portal interfaces.",{"header":450,"content":451},"When do internal developer portals make sense to implement?","Portals work best for specific workflows like developer onboarding and new project scaffolding rather than trying to be a single pane of glass for all activities. Successful implementations focus on activities that genuinely benefit from simplified point-and-click interfaces while developers continue using specialized tools directly.","content:en-us:the-source:platform:beyond-the-portal-hype-why-you-need-a-platform-first:index.yml","en-us/the-source/platform/beyond-the-portal-hype-why-you-need-a-platform-first/index.yml","en-us/the-source/platform/beyond-the-portal-hype-why-you-need-a-platform-first/index",{"_path":456,"_dir":417,"_draft":6,"_partial":6,"_locale":7,"config":457,"seo":459,"content":463,"type":419,"slug":487,"category":417,"_id":488,"_type":30,"title":460,"_source":31,"_file":489,"_stem":490,"_extension":34,"date":464,"description":461,"timeToRead":465,"heroImage":462,"keyTakeaways":466,"articleBody":470,"faq":471},"/en-us/the-source/platform/transform-your-platform-onboarding-for-higher-adoption-rates",{"layout":9,"template":421,"articleType":422,"author":28,"featured":330,"gatedAsset":458,"isHighlighted":6,"authorName":11},"source-lp-devsecops-the-key-to-modern-security-resilience",{"title":460,"description":461,"ogImage":462},"Transform your platform onboarding for higher adoption rates","Redesign your platform onboarding to boost adoption, reduce friction, and create seamless experiences for development teams.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463510/hm90bhwzptl1b2gwovhx.png",{"title":460,"date":464,"description":461,"timeToRead":465,"heroImage":462,"keyTakeaways":466,"articleBody":470,"faq":471},"2025-07-01","4 min read",[467,468,469],"A weak onboarding experience can significantly impact platform adoption, with research showing that one-third of users consider abandoning platforms after poor experiences.","Simple improvements like creating an intuitive landing page, writing clear documentation, and automating access processes can dramatically increase user adoption and satisfaction.","Building effective support systems across multiple channels (chat, email, ticketing) creates trust and ensures users can quickly overcome obstacles during their onboarding journey.","In my work with platform teams across industries, from startups to enterprises, I’ve noticed a consistent blind spot: the onboarding experience. While teams focus intensely on building robust features, they often neglect how new users first encounter their platform - and this oversight can severely limit adoption.\n\nAccording to the [diffusion of innovations theory](https://en.wikipedia.org/wiki/Diffusion_of_innovations), most platforms achieve about 16% adoption before stagnating. That's because innovators and early adopters - representing about 16% of an organization - are often willing to tolerate rough edges, motivated by novelty or vision. The early majority, comprising 34%, is key to going mainstream. They prioritize proven reliability, a clear value proposition, and ease of use. This shift in expectations is the chasm where many platform teams stumble. Your early adopters might forgive a clunky onboarding process, but the early majority won’t.\n\n![Diffusion of Innovation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176125/Blog/k6kxdtokv4laph4exsdt.png)\n\n## Start with a memorable, future-proof name\nThe platform's name is likely the first part of the platform that users will engage with. Choose something unique within your organization that’s easy to spell and not tied to specific technologies.\n\nEffective platform names often:\n\n**Reflect your value proposition** rather than the underlying technology. For example, try a name such as “Runway” that reflects the value proposition of helping teams launch faster instead of something more literal like “K8sPipeline.”\n\n**Use simple, memorable words** that evoke the platform’s purpose. Can someone easily understand and spell it after hearing it once? Choosing something simple and easy to remember, such as “Beacon,” will likely serve you better than a unique or creative option such as “Syzygy.”\n\nAvoid these common pitfalls:\n- **Version numbers in names** signal previous failures and raise doubts about longevity.\n- **Generic three-letter acronyms** become instantly forgettable in a sea of other TLAs.\n- **Technology-based names** suggest you prioritize tools over user needs.\n\n## Develop a multi-channel communication strategy\nEffective platform adoption requires deliberate communication planning across multiple channels, from a product website that clearly articulates your platform’s value proposition to user-centric documentation and email updates. Your communication strategy should also include a reliable health dashboard that gives users visibility into known issues and their resolution status. Remember that in enterprise environments, how you communicate about your platform often matters as much as the platform itself. Invest in communication with the same care you invest in your technical infrastructure.\n\n> [Learn more about building a comprehensive communication framework for platform engineering](https://about.gitlab.com/the-source/platform/building-a-communication-strategy-for-platform-engineering-teams/).\n\n## Simplify the access process\nTeams often spend months perfecting platform features while neglecting the most basic step: making it easy to access the platform.\n\nI’ve seen many examples of this at organizations of all sizes, across every industry. Common barriers include:\n\n**Manual onboarding processes** for supposedly self-service platforms. If you can’t fully automate the process, do your best to perform human-in-the-loop tasks asynchronously.\n\n**Time-consuming approval steps** or other barriers that delay initial exploration. One great solution to this is to offer immediate, temporary access to your platform for free for 30 days. This is long enough for someone to decide if your platform helps them and raise the necessary request to gain full access.\n\n**Mandatory training requirements** before users can begin. Training is valuable, but it should be required within a period of joining the platform rather than being a prerequisite.\n\n## Don’t neglect design and tone\nFirst impressions are largely visual. An outdated or inconsistent interface can deter users even if your functionality is excellent. Pay attention to branding, color schemes, and the tone of your messaging. These details might seem trivial, but they set the tone for user engagement.\n\nAim for clear, human communication rather than technical jargon. A user-friendly tone makes your platform more approachable to diverse stakeholders.\n\n## Build responsive support systems\nEven the best platforms need support, and nothing builds trust faster than responsive help when users encounter problems. Your primary goal during support interactions should be minimizing user frustration.\n\nCreate an effective support framework by leveraging multiple channels:\n- **Support tickets** provide accountability and integration with other systems.\n- **Email communication** works well for complex topics requiring clarity.\n- **Chat systems** enable real-time problem-solving when users are “in the flow.”\n\nBe present where your users are, even if that means monitoring multiple communication tools. Aim to answer chat queries within 30-60 minutes, and always follow up publicly so others can benefit from solutions.\n\n## The path to successful platform adoption\nOrganizations that prioritize user experience from day one gain significant advantages in adoption rates and user satisfaction. By creating intuitive onboarding processes, clear documentation, and responsive support systems, you transform the user journey from frustration to delight.\n\nRemember that your platform users are making a critical decision: whether your solution deserves their time and trust. A thoughtful onboarding experience tells them you value that investment - and dramatically increases your chances of widespread adoption.",[472,475,478,481,484],{"header":473,"content":474},"Why is platform onboarding so important to user adoption?","Poor onboarding experiences are a leading cause of stalled platform adoption. Research shows that one-third of users consider abandoning platforms after a frustrating first encounter. A thoughtful, streamlined onboarding process helps build trust and accelerates user engagement.",{"header":476,"content":477},"What are the most common onboarding mistakes platform teams make?","Teams often over-engineer platform features while neglecting usability basics. Common mistakes include clunky access processes, mandatory training before usage, poor visual design, inconsistent messaging, and weak support channels, all of which discourage adoption.",{"header":479,"content":480},"How can platform teams improve onboarding access without sacrificing control?","Offer temporary, self-service access, such as a 30-day trial, to remove early friction. If full automation isn’t possible, use asynchronous human-in-the-loop onboarding and avoid approval-heavy workflows that delay initial exploration and testing.",{"header":482,"content":483},"What role does naming and communication play in platform success?","A clear, future-proof name and consistent multi-channel communication strategy help build platform recognition and trust. Names should reflect user value, not technology, while communication must include user-focused documentation, health dashboards, and regular updates.",{"header":485,"content":486},"How should platform support be structured during onboarding?","Support should be fast, responsive, and multi-modal. Use tickets for tracking, email for clarity, and chat for real-time help. Aim for quick response times and always share publicly resolved issues to benefit all users.","transform-your-platform-onboarding-for-higher-adoption-rates","content:en-us:the-source:platform:transform-your-platform-onboarding-for-higher-adoption-rates:index.yml","en-us/the-source/platform/transform-your-platform-onboarding-for-higher-adoption-rates/index.yml","en-us/the-source/platform/transform-your-platform-onboarding-for-higher-adoption-rates/index",{"_path":492,"_dir":417,"_draft":6,"_partial":6,"_locale":7,"config":493,"seo":495,"content":499,"type":419,"slug":522,"category":417,"_id":523,"_type":30,"title":496,"_source":31,"_file":524,"_stem":525,"_extension":34,"date":500,"description":497,"timeToRead":430,"heroImage":498,"keyTakeaways":501,"articleBody":505,"faq":506},"/en-us/the-source/platform/unlock-developer-potential-with-effective-platform-teams",{"layout":9,"template":421,"articleType":422,"author":28,"featured":6,"gatedAsset":494,"isHighlighted":6,"authorName":11},"source-lp-building-a-resilient-software-development-practice",{"title":496,"description":497,"ogImage":498},"Unlock developer potential with effective platform teams","Discover how successful platform teams drive innovation by focusing on collaboration and developer experience rather than just technology.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463569/go1j065dkmpxh5qiabh1.png",{"title":496,"date":500,"description":497,"timeToRead":430,"heroImage":498,"keyTakeaways":501,"articleBody":505,"faq":506},"2025-06-24",[502,503,504],"Platform teams thrive when they measure success through developer velocity and adoption rates, not by technical complexity or feature count—creating value by removing obstacles rather than adding layers.","Building strong feedback loops between platform teams and developers creates a virtuous cycle where platforms evolve based on real needs, fostering higher adoption and greater business impact.","The most successful platform teams focus on making the right way the easy way, reducing cognitive load for developers and allowing them to concentrate on building features that matter to customers.","Developers are drowning in complexity while delivery dates keep slipping. Everyone’s talking about platform teams as the solution, but if you build it, will they come? The harsh reality is that most platform initiatives fail not because of technology choices but because they miss what truly matters: genuine collaboration. The most powerful platforms aren’t technology stacks - they’re relationship accelerators that fundamentally change how teams work together.\n\n## What are platform teams and what do they do?\nThe [Team Topologies](https://www.amazon.co.uk/Team-Topologies-Organizing-Business-Technology/dp/1942788819) framework defined the four fundamental types of teams involved in software development:\n1. **Stream-aligned teams**, who focus on a single stream of work\n1. **Enabling teams**, who provide specialized skills and expertise to support stream-aligned teams\n1. **Complicated-subsystem teams**, who build and maintain backend systems that require specialist knowledge\n1. **Platform teams**, who enable stream-aligned teams to operate more quickly and autonomously.\n\nOf these, platform teams often get the most attention - and for good reason. When done right, they can transform how quickly an organization delivers software.\n\nPlatform teams make developers’ jobs easier by handling complex technical work for them. They give developers everything they need to build, test, and deploy applications without worrying about the underlying technology. Think of the platform team as a product team creating an internal product - and developers are their customers.\n\nA platform team’s core goal is simple: enable developers to deliver software faster by simplifying complexity. Rather than having each development team figure out how to set up monitoring, security controls, CI/CD pipelines, and cloud resources, the platform team creates [standardized, well-documented solutions that work seamlessly together](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/).\n\nBut here’s a nuance many leaders miss: The success of a platform team isn’t measured by the sophistication of its technology stack or the number of features it delivers - it’s measured by how effectively it enables other teams to deliver business value. Platform teams are defined by how they collaborate with the teams they serve.\n\nI’ve worked with organizations across industries, and the pattern is clear. When platform teams focus on reducing cognitive load for developers and creating self-service capabilities that feel effortless, everyone wins. The business delivers faster, developers stay focused on what matters, and customers get better products.\n\n## The restaurant model of platform excellence\nThink of a well-designed platform like a restaurant. The food might be excellent, but customers are unlikely to return if the service is slow, the staff is rude, and the environment lacks character.\n\nThe same applies to platform teams. The technology matters, but how it’s organized and presented to developers - the customers of the platform - matters just as much. Great platforms create an environment where software developers can focus on creating business value instead of wrestling with infrastructure concerns or reinventing workflows.\n\nJust as restaurant kitchens must evolve with changing culinary techniques and equipment, platform teams must continuously evolve their offerings to meet changing business requirements and development processes.\n\n## Three pillars of platform team success\n### Align priorities around outcomes\nThe most effective platform teams align their priorities with the outcomes developers need to achieve. This alignment isn’t always easy, especially when platform teams report through IT functions while development teams report through business units.\n\nBreaking this organizational pattern requires platform teams to focus on what developers truly need. The metrics that matter aren’t technical but outcome-based: How much faster can developers ship? How confidently can they release changes? Here are a few of the outcomes you should be measuring:\n\n- **Increasing adoption rates**: Teams choose your platform because it makes their lives easier\n- **Developer velocity**: Teams using your platform ship faster than those who don't\n- **Developer satisfaction**: Regular feedback shows developers enjoy using your platform\n- **Reduced support burden**: Support tickets decrease dramatically as developers can self-serve through well-designed interfaces and comprehensive documentation\n\nGreat platform leaders advocate upward to leadership about the direct connection between developer productivity and business outcomes, turning “developer experience” from a nice-to-have into a strategic imperative.\n\n### Build strong communication channels\nRemember, the platform is a product, and developers are the customers. This mindset shift changes everything.\n\nThe best platform teams create multiple channels for feedback:\n- Regular user research sessions\n- Developer experience surveys\n- “Office hours” where developers can get help\n- Champions programs that bring developer perspectives into platform planning\n\nEven the name matters. Teams with names like “Developer Enablement Platform” or “Developer Experience Team” send a clear signal about their purpose - they exist to serve developers, not to control them.\n\nDevelopers who feel heard and respected become collaborators rather than mere users. They bring insights that improve your platform because they know their needs will shape its evolution.\n\n> [Learn more about how to create a communication framework for platform engineering that increases adoption, builds trust, and shows value](https://about.gitlab.com/the-source/platform/building-a-communication-strategy-for-platform-engineering-teams/).\n\n### Focus on developer delight\nDeveloper experience isn't just about reducing friction - it’s about creating delight. Think of your platform as a product that has to compete for mindshare. At one major media and telecommunications company I worked with, the platform team would theme their developer interfaces to celebrate key holidays and events throughout the year. These seasonal themes - whether for Halloween, major sporting events, or end-of-year celebrations - added no functional improvements yet consistently generated positive developer feedback. This simple touch demonstrated that the platform team cared about the human experience, not just the technical capabilities.\n\nThe best platforms don’t just build features; they craft experiences where:\n- Error messages guide rather than confuse\n- Documentation anticipates questions\n- Interfaces feel natural and intuitive\n- Common tasks require minimal cognitive load\n\nPlatform engineering excellence comes from making complex things appear simple. It’s not about building the most sophisticated system - it’s about hiding complexity so developers can focus on creating business value.\n\n## The path forward\nTeam Topologies provides a valuable framework for understanding how platform teams should function. But the real magic happens when you combine that framework with a relentless focus on the developer experience.\n\nMy advice for platform leaders:\n1. **Measure what matters**: Track developer velocity and platform adoption as your primary metrics.\n1. **Find champions**: Every feature should have a customer champion who helps shape it.\n1. **Make the right way the easy way**: Success comes when developers choose your platform because it's genuinely better than alternatives.\n\nThe most successful organizations I’ve worked with understand that platforms are collaborative ecosystems that succeed or fail based on human factors as much as technical ones.\n\nBy focusing on outcomes, communication, and experience, your platform team can become a force multiplier, transforming how your organization builds software.",[507,510,513,516,519],{"header":508,"content":509},"What is the main responsibility of a platform engineering team?","A platform engineering team's primary responsibility is to reduce complexity for developers by providing standardized tools, services, and workflows that enable faster, safer software delivery. Their role is to empower development teams, not control them.",{"header":511,"content":512},"How do successful platform teams measure their impact?","Impact is measured by developer outcomes, not technical features. Key metrics include adoption rates, developer velocity, satisfaction scores, and a reduced support burden. The best platforms help teams ship faster and more confidently.",{"header":514,"content":515},"Why is collaboration critical for platform engineering success?","Platforms succeed when built with developer input and feedback. Strong communication loops, including surveys, office hours, and developer champions, help ensure the platform evolves in response to real user needs, increasing adoption and trust.",{"header":517,"content":518},"What’s the “restaurant model” in platform engineering?","The restaurant model suggests that, like a good dining experience, a great platform needs more than good \"food\" (features). It also needs friendly service (support), clear signage (documentation), and a welcoming environment (developer experience).",{"header":520,"content":521},"How can platform teams boost developer engagement?","Beyond functionality, teams can create delight through intuitive interfaces, thoughtful error messaging, and even small cultural touches like themed dashboards. These elements show empathy and build stronger emotional connections with developers.","unlock-developer-potential-with-effective-platform-teams","content:en-us:the-source:platform:unlock-developer-potential-with-effective-platform-teams:index.yml","en-us/the-source/platform/unlock-developer-potential-with-effective-platform-teams/index.yml","en-us/the-source/platform/unlock-developer-potential-with-effective-platform-teams/index",{"_path":527,"_dir":417,"_draft":6,"_partial":6,"_locale":7,"config":528,"seo":530,"content":535,"type":419,"slug":558,"category":417,"_id":559,"_type":30,"title":531,"_source":31,"_file":560,"_stem":561,"_extension":34,"date":536,"description":532,"timeToRead":430,"heroImage":533,"keyTakeaways":537,"articleBody":541,"faq":542},"/en-us/the-source/platform/building-a-communication-strategy-for-platform-engineering-teams",{"layout":9,"template":421,"articleType":422,"author":28,"featured":330,"gatedAsset":529,"isHighlighted":6,"authorName":11},"source-lp-measuring-success-in-software-development-a-guide-for-leaders",{"title":531,"description":532,"ogImage":533,"config":534},"Building a communication strategy for platform engineering teams","Discover how to create a communication framework for platform engineering that increases adoption, builds trust, and shows value.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463500/aw80z4omecn1zduruwhi.png",{"ignoreTitleCharLimit":330},{"title":531,"date":536,"description":532,"timeToRead":430,"heroImage":533,"keyTakeaways":537,"articleBody":541,"faq":542},"2025-06-17",[538,539,540],"Effective communication is foundational to platform engineering success, directly impacting user adoption, satisfaction, and leadership support.","A multi-channel approach using product websites, blogs, health dashboards, documentation, emails, and chat platforms creates a comprehensive communication ecosystem.","Communication must be tailored to different audiences — from technical users needing implementation details to executives requiring value demonstrations.","Picture this: Your [platform engineering team](https://about.gitlab.com/the-source/platform/platform-engineering-its-about-culture-not-tools/) has spent months perfecting an internal solution that dramatically reduces deployment times and eliminates configuration errors. Yet three months after launch, adoption remains disappointingly low. The culprit? Not technical shortcomings but communication gaps.\n\nEven the most powerful internal developer platform will fail without effective communication. I consistently see technically sound platforms struggling with adoption because potential users don’t understand their value or how to use them.\n\nYour platform’s technical excellence means nothing if engineers don’t adopt it or leadership doesn’t fund its continuous improvement. Strategic communication bridges the gap between platform capability and business impact, transforming your technical innovation into measurable value that resonates with developers and executives.\n\n## Crafting effective rollout communications\nBefore diving into ongoing communication channels, we must address a crucial moment: your platform’s initial launch. Whether you’re communicating through email, Slack, or a real-time presentation, how you introduce your platform sets the foundation for adoption and engagement.\n\n**Start with the “why” behind your platform**. Engineers are naturally skeptical of new tools that appear to add complexity. Your communications should clearly explain how the platform reduces cognitive load, minimizes context switching, improves documentation access, and enables faster development cycles. Frame benefits as concrete improvements to daily workflows rather than abstract concepts. For example, highlight how automating environment setup can save each developer 5-7 hours weekly instead of simply claiming “increased productivity.”\n\n**Anticipate and address resistance points proactively**. Engineers often worry about how new platforms integrate with their preferred tools or disrupt established workflows. Your communications should acknowledge these concerns directly and explain integration capabilities, migration paths, and support options. Consider creating an FAQ document that addresses common objections before they arise. Being transparent about current limitations while sharing your roadmap builds credibility and sets appropriate expectations.\n\n**Recruit platform champions to amplify your message**. Identify respected technical colleagues who contributed to the platform’s development or successfully used early versions. Their authentic endorsements carry significantly more weight than official communications alone. Create opportunities for these champions to demonstrate the platform’s capabilities through lightning talks, recorded demos, or pair programming sessions. These peer-to-peer interactions allow potential users to see practical applications and ask candid questions in a low-pressure environment.\n\nOnce you’ve launched the platform, you’ll need to keep the communication with your users open. Let’s explore the five critical communication channels that should be part of every platform engineering team’s ongoing strategy.\n\n## The essential communication channels\n### Documentation\nGreat documentation - ideally in an editable wiki or intranet that everyone can contribute to - is transformative for platform adoption. It dramatically reduces support overhead and [accelerates user onboarding](https://about.gitlab.com/the-source/platform/transform-your-platform-onboarding-for-higher-adoption-rates/). Intentionally recording your knowledge is one of the most selfless and positive changes you can make in a team.\n\nYour documentation needs to answer three questions concisely: What problem does your platform solve, what benefits can developers expect, and where can they find more information?\n\nEffective documentation puts users first, organizing information around their journey rather than system architecture. It should also include:\n- Straightforward \"Getting Started\" guides showing how easily basic use cases can be implemented\n- A comprehensive knowledge base for more complex scenarios\n- Clear examples and code snippets that users can adapt\n- Regular updates that keep pace with platform changes\n\nThe best documentation anticipates user questions rather than just documenting system capabilities.\n\n### Team blog\nConsider creating an internal blog for your platform engineering team where they can share ideas and solutions with the platform users. A dedicated blog space enables your team to share deeper context about your platform that wouldn’t fit in brief communications. Blog posts allow you to:\n- Provide technical deep dives with diagrams or videos\n- Give users insights into how your platform operates\n- Cultivate knowledgeable platform advocates\n- Build trust through transparency\n- Give team members practice with technical communication\n- Share success stories or interesting use cases for the platform\n\nBlog content helps users understand how to use your platform and why certain design decisions were made, making them more effective users and potential advocates.\n\n### Health dashboard\nWhen users encounter platform issues, nothing frustrates them more than silence. A health dashboard provides immediate visibility into known issues and their resolution status.\n\nAn effective dashboard serves multiple purposes in your communication strategy. First, it builds trust by acknowledging problems quickly rather than leaving users to wonder if issues will be addressed. During widespread outages, a dashboard significantly reduces duplicate support requests by providing a central source of truth about system status. Prospective users often review these dashboards to evaluate how reliably you operate before committing to your platform. Perhaps most importantly, a transparent health dashboard demonstrates your team’s commitment to openness and accountability, qualities that foster long-term trust with your user community.\n\nRemember that dashboards must be accurate to maintain credibility. A dashboard showing all green systems during a known outage will destroy user trust. Similarly, reported problems should always include resolution updates.\n\n### Email updates\nDespite inbox overload, email remains effective for periodic platform updates. Monthly newsletters help maintain awareness of your platform’s ongoing development and improvements.\n\nThese communications serve two purposes:\n- Informing users about new features, improvements, and upcoming changes\n- Demonstrating continuous momentum and investment in the platform\n\nRemember that most recipients will skim emails for just a few seconds. Make key points stand out with clear formatting, concise language, and visual hierarchy. The communication reinforces your team's active presence even if users don’t read every word.\n\n### Real-time messaging\nYour team should maintain a presence wherever your users naturally collaborate - which often means real-time chat platforms like Slack. Chat builds relationships with users through accessibility and responsiveness, creating a community around your platform. Here are a few golden rules teams can follow to ensure they’re building a good relationship with their users:\n\n**Respond to queries promptly**. Chat moves quickly. Teams should aim to respond to user questions within 30-60 minutes during business hours to maintain engagement and show users they’re valued. It’s not ideal if users are chatting in real time about your product and your team is nowhere to be found.\n\n**Present a consistent voice to users**. Think of your organization’s messaging systems as a “public” customer service channel. Maintain a separate “internal” channel where engineers can debate and discuss conflicting viewpoints. A user should never see two engineers debating with one another - they both lose credibility.\n\n**Document solutions publicly**. After resolving an inquiry, ensure that engineers update the channel with the outcome so other users can benefit from the knowledge.\n\n**Open support tickets for users**. Chat is great for quick questions, but more complicated requests should be tracked in issue management software. Instead of directing users to “open a ticket,” ensure your engineers can do this on behalf of the user.\n\n## Bringing it all together\n[Effective platform engineering](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/) requires a holistic approach to communication that combines all these channels into a cohesive strategy. Each channel serves distinct purposes and reaches different segments of your audience.\n\nBy implementing this comprehensive framework, your platform team can build trust, demonstrate value, and drive adoption - ultimately ensuring that your technical capabilities translate into business impact.\n\nRemember that in enterprise environments, how you communicate about your platform often matters as much as the platform itself. Invest in communication with the same care you invest in your technical infrastructure.",[543,546,549,552,555],{"header":544,"content":545},"What role does communication play in successful platform engineering?","Communication is foundational to platform engineering success. Even the best technical platforms will fail if users don’t understand their value, know how to use them, or feel supported. Communication drives adoption, builds trust, and helps secure long-term investment.",{"header":547,"content":548},"Why do platform rollouts fail even when the tech is solid?","Rollouts often fail due to poor communication. If developers don’t see clear benefits, or if concerns around workflow disruption and tool integration aren't addressed, adoption stalls. Successful rollouts proactively explain value, anticipate objections, and include trusted advocates to build credibility.",{"header":550,"content":551},"What communication channels should every platform team use?","A strong communication strategy includes five core channels: detailed documentation, a team blog, a live platform health dashboard, periodic email updates, and real-time messaging on platforms like Slack. Each channel supports different user needs and helps ensure ongoing engagement.",{"header":553,"content":554},"How should platform teams communicate with technical vs. executive stakeholders?","Communication should be tailored to each audience. Developers need technical guidance and practical examples. Executives need clear demonstrations of platform impact, such as improved delivery speed or reduced support costs. One message rarely fits both groups.",{"header":556,"content":557},"What’s the benefit of having a health dashboard for your platform?","A transparent health dashboard builds trust by showing users what’s working and what’s not. It reduces support noise during issues, demonstrates accountability, and assures users that problems are known and being resolved.","building-a-communication-strategy-for-platform-engineering-teams","content:en-us:the-source:platform:building-a-communication-strategy-for-platform-engineering-teams:index.yml","en-us/the-source/platform/building-a-communication-strategy-for-platform-engineering-teams/index.yml","en-us/the-source/platform/building-a-communication-strategy-for-platform-engineering-teams/index",{"_path":563,"_dir":417,"_draft":6,"_partial":6,"_locale":7,"config":564,"seo":565,"content":569,"type":419,"slug":596,"category":417,"_id":597,"_type":30,"title":566,"_source":31,"_file":598,"_stem":599,"_extension":34,"date":570,"description":567,"timeToRead":571,"heroImage":568,"keyTakeaways":572,"articleBody":576,"faq":577},"/en-us/the-source/platform/platform-engineering-its-about-culture-not-tools",{"layout":9,"template":421,"articleType":422,"author":28,"featured":330,"gatedAsset":423,"isHighlighted":6,"authorName":11},{"title":566,"description":567,"ogImage":568},"Platform engineering: It’s about culture, not tools","Discover how platform engineering evolves beyond DevOps to foster collaboration across teams while balancing autonomy with governance.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463480/xeygsznqg7uo5cihn2oj.png",{"title":566,"date":570,"description":567,"timeToRead":571,"heroImage":568,"keyTakeaways":572,"articleBody":576,"faq":577},"2025-06-10","7 min read",[573,574,575],"Platform engineering is less about adding new tools and more about creating a collaborative approach that brings teams together with a product mindset focused on developer experience.","Successful platform teams prioritize empathy, treating internal developers as customers and making governance and security features rather than obstacles.","Measuring platform success requires balancing technical metrics with perception metrics, focusing on team-specific improvements rather than comparing teams against each other.","Over the past decade, we’ve seen significant changes in how development organizations structure their teams. Traditional operations teams gave way to Google’s Site Reliability Engineering (SRE) model, which aimed to modernize operations and better define interfaces with software developers. This was a move away from the “throw it over the wall” approach that often ended in blame contests when things went wrong.\n\n[DevOps](https://about.gitlab.com/topics/devops/) emerged as a slightly different approach to the same problem, bringing developers and operators into a single team focused on delivering business value. This model proved successful - bringing people together is always a good idea, and aligning them to business outcomes helped get features out the door faster.\n\nHowever, challenges emerged as organizations attempted to scale DevOps. Having developers and operators in every team became expensive. Teams also focused on local optimization, making their tools and processes efficient for their specific needs, sometimes at the expense of global organizational goals. Corporate policies, security requirements, and governance often got lost in the shuffle.\n\nEnter platform engineering: the next step in this evolution.\n\n## What is platform engineering?\n[Platform engineering](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/) represents a balance between the structured interfaces of SRE and the collaborative spirit of DevOps. At its core, it involves creating a centralized platform team with a well-defined interface to decrease developers' cognitive load, approaching internal tooling as a product rather than a service.\n\nThe product mindset is central to platform engineering. Platform teams build services for consumption, treating them as products and the developers as customers. This means:\n- Engaging with developers to understand their needs and pain points\n- Designing the platform based on user research and feedback\n- \"Marketing\" the platform’s value to increase adoption\n- Continuously improving based on usage metrics and customer satisfaction\n- Creating documentation and enablement materials that speak to developer needs\n\nUnlike traditional IT service models built around tickets and wait times, platform engineering teams build self-service capabilities that development teams want to use. Their Internal Developer Platforms provide \"golden paths\" with all essential components for building reliable, secure software so developers can focus on writing code. That translates into more efficient software delivery and faster time to market.\n\nA key difference from DevOps is that platform engineering [acknowledges how large organizations tend to be structured](https://about.gitlab.com/the-source/platform/unlock-developer-potential-with-effective-platform-teams/). Rather than trying to put operators on every team (which becomes expensive and creates inconsistency), it creates a specialized team that serves the broader organization - but with a product mindset rather than a service desk approach.\n\n## The human side of platform engineering\nThe secret to platform engineering success isn’t choosing the right technology stack - it’s rooted in empathy. Effective platform teams deeply understand what a day in the life of a developer, security engineer, or operations specialist looks like. They know the pressures these teams face, their performance metrics, and the challenges that frustrate them most.\n\nThis empathy leads to a core principle: **make the right thing the easiest thing**. We are all fundamentally drawn to the path of least resistance. If security scanning is painful and slow, developers will try to work around it. If deployment pipelines are cumbersome, teams will build their own.\n\nSecurity and compliance should be features of your business, not obstacles. This mindset shift changes everything. Think of it like car brakes - they aren’t there to slow you down; they’re there so you can confidently drive faster. You’d drive much more cautiously without good brakes or avoid driving altogether.\n\n> [Learn steps to take to transform your onboarding for higher platform adoption rates](https://about.gitlab.com/the-source/platform/transform-your-platform-onboarding-for-higher-adoption-rates/).\n\n## Optimizing process through collaboration\nWhen I’m helping a platform team consider the process behind their platform, I like to look at their approval steps and ask, “When was the last time this approval step resulted in a rejection?” I’m always blown away by how many approval steps never result in a rejection. This is a clear sign of a process that’s not adding value.\n\nSo, how can organizations start to critically examine existing development processes with an eye toward optimization?\n\nOne of the most powerful tools in platform engineering isn’t a tool at all - it’s a workshop. Path to Production (or [value stream](https://about.gitlab.com/the-source/platform/optimize-value-stream-efficiency-to-do-more-with-less-faster/)) workshops bring together everyone involved in releasing software, from developers and security specialists to compliance and product teams.\n\nThe format is simple: Get representatives from each team in a room with sticky notes and an empty wall. Chart out exactly what happens to go from an idea to production code. Understand what each team does, how handoffs work, and how long each step takes.\n\nFor many organizations, this might be the first time these teams have all been in the same room discussing how they work together. Good things happen when people come together - this time helps everyone understand functional requirements and emotional pain points in the process.\n\nThis collaborative approach should extend to your platform team’s day-to-day work. Successful platform teams regularly engage with finance to help them understand technology investments. They build relationships with security teams to automate compliance rather than block progress and create feedback loops with platform users to continually improve the platform based on real needs.\n\n> [Learn how to build an effective communication strategy for platform engineering teams](https://about.gitlab.com/the-source/platform/building-a-communication-strategy-for-platform-engineering-teams/).\n\n## Measuring success beyond adoption rates\nFor most organizations, one of the top priorities of a platform engineering initiative is improving developer experience. However, developer experience is subjective, so how can organizations measure the success of their platform teams? Adoption rates are a good start, but you’ll need to dig deeper to get a complete picture.\n\nGood metrics should be:\n1. Tied to business outcomes, not just technical capabilities\n1. Small in number but broad in what they measure\n1. Used to understand trends within teams, not compare across teams\n1. Clear about why they’re being measured\n\nOrganizations often jump straight to [frameworks like DORA](https://about.gitlab.com/the-source/ai/dora-insights-where-is-ai-really-driving-developer-productivity/) when measuring platform engineering success. DORA is a great place to start because it boils everything down to four metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service. However, one thing to be mindful of when using DORA metrics is to avoid comparing metrics across teams. For any metric to be useful, you need to consider it in the context of a specific team with specific goals. For example, deploying many times a day might be great for a web application, but less desirable for a complex backend finance tool.\n\nMore importantly, metrics should always be used to measure teams' performance, not individuals’ performance. The very act of recording metrics will change behavior. Software engineers are problem solvers by nature - if you measure their performance based solely on deployment frequency, they’ll find ways to deploy more frequently, whether or not that’s beneficial to the organization.\n\nAlso, keep in mind that perception matters as much as reality. A deployment process might only take 15 minutes, but developers will perceive it as slow if it feels painful and frustrating. User interfaces that are unresponsive, require duplicate data entry, or demand unnecessary approvals create a perception of friction even if the actual time impact is minimal, so a high-performing platform team should always be looking for ways to understand whether they need to change the speed of the system or change the perception of the system.\n\n> [Read more about how to unlock developer potential with effective platform teams](https://about.gitlab.com/the-source/platform/unlock-developer-potential-with-effective-platform-teams/).\n\n## A cultural shift, not just a technical one\nPlatform engineering represents an evolution of DevOps that acknowledges both the value of bringing people together and the reality of how large organizations operate. However, its greatest potential lies not in its technical approach but in its cultural impact.\n\nBy fostering collaboration across teams, treating developers as customers, and making security and governance features rather than obstacles, platform engineering helps organizations deliver better software faster - not by adding new tools, but by helping people work better together.\n\nThe most successful platform teams understand they’re building bridges, not just tools. They focus on making the right thing the easiest thing, balancing developer autonomy with organizational governance, and measuring success in ways that drive positive behavior.\n\nAs you evaluate your organization’s approach to internal platforms, ask what technologies you’re using and how you’re bringing people together around them. That’s where the true power of platform engineering lies.",[578,581,584,587,590,593],{"header":579,"content":580},"What is platform engineering and how is it different from DevOps?","Platform engineering focuses on creating centralized, self-service platforms that treat internal developers as customers. Unlike traditional DevOps, which often embeds operators into each team, platform engineering balances autonomy and governance by scaling enablement through productized tooling.",{"header":582,"content":583},"Why is empathy important in platform engineering?","Empathy helps platform teams understand the real needs and frustrations of their users — developers, security engineers, and others. This perspective enables the team to create platforms that reduce friction, support team goals, and encourage adoption.",{"header":585,"content":586},"How does platform engineering improve developer experience?","By reducing cognitive load through golden paths, self-service interfaces, and better documentation, platform engineering makes secure, compliant workflows easier to follow. This improves developer satisfaction and enables faster software delivery.",{"header":588,"content":589},"How should platform engineering teams measure success?","While adoption rates are useful, success is best measured by a combination of business-aligned metrics, user perception, and trend analysis within teams. Frameworks like DORA can help, but should be used thoughtfully and not for team-to-team comparison.",{"header":591,"content":592},"What role do workshops play in platform engineering?","Workshops like “Path to Production” help break down silos by bringing together all stakeholders involved in software delivery. These collaborative sessions identify inefficiencies, improve handoffs, and foster shared ownership of platform improvements.",{"header":594,"content":595},"Why is platform engineering described as a cultural shift?","It goes beyond tooling by changing how teams collaborate. Platform engineering encourages cross-functional empathy, values governance as a feature (not a blocker), and builds systems that prioritize ease-of-use and shared responsibility across the organization.","platform-engineering-its-about-culture-not-tools","content:en-us:the-source:platform:platform-engineering-its-about-culture-not-tools:index.yml","en-us/the-source/platform/platform-engineering-its-about-culture-not-tools/index.yml","en-us/the-source/platform/platform-engineering-its-about-culture-not-tools/index",[415,455,491,526,562],{"ai":356,"platform":363,"security":98},1753207407663]