[{"data":1,"prerenderedAt":761},["ShallowReactive",2],{"/en-us/the-source/authors/bryan-ross":3,"footer-en-us":33,"the-source-banner-en-us":367,"the-source-newsletter-en-us":373,"the-source-navigation-en-us":380,"authors-en-us":403,"categories-en-us":442,"bryan-ross-articles-list-en-us":443},{"id":4,"title":5,"body":6,"category":6,"config":7,"content":9,"description":6,"extension":24,"meta":25,"navigation":26,"path":27,"seo":28,"slug":29,"stem":30,"testContent":6,"type":31,"__hash__":32},"theSourceAuthors/en-us/the-source/authors/bryan-ross.yml","Bryan Ross",null,{"layout":8},"the-source",[10,22],{"componentName":11,"type":11,"componentContent":12},"TheSourceAuthorHero",{"config":13,"name":5,"role":17,"bio":18,"headshot":19},{"gitlabHandle":14,"twitterXProfileUrl":15,"linkedInProfileUrl":16},"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":5,"config":20},{"src":21},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463324/mvdyvskii4hltdrgqxom.jpg",{"componentName":23,"type":23},"TheSourceArticlesList","yml",{},true,"/en-us/the-source/authors/bryan-ross",{"title":5},"bryan-ross","en-us/the-source/authors/bryan-ross","author","fSon_pjQKF1SoSOt3Vg6MC6j1m9Ej0ODYs8fCB-gyB8",{"data":34},{"text":35,"source":36,"edit":42,"contribute":47,"config":52,"items":57,"minimal":356},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":37,"config":38},"View page source",{"href":39,"dataGaName":40,"dataGaLocation":41},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":43,"config":44},"Edit this page",{"href":45,"dataGaName":46,"dataGaLocation":41},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":48,"config":49},"Please contribute",{"href":50,"dataGaName":51,"dataGaLocation":41},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":53,"facebook":54,"youtube":55,"linkedin":56},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[58,115,172,231,294],{"title":59,"links":60,"subMenu":76},"Pricing",[61,66,71],{"text":62,"config":63},"View plans",{"href":64,"dataGaName":65,"dataGaLocation":41},"/pricing/","view plans",{"text":67,"config":68},"Why Premium?",{"href":69,"dataGaName":70,"dataGaLocation":41},"/pricing/premium/","why premium",{"text":72,"config":73},"Why Ultimate?",{"href":74,"dataGaName":75,"dataGaLocation":41},"/pricing/ultimate/","why ultimate",[77],{"title":78,"links":79},"Contact Us",[80,85,90,95,100,105,110],{"text":81,"config":82},"Contact sales",{"href":83,"dataGaName":84,"dataGaLocation":41},"/sales/","sales",{"text":86,"config":87},"Support portal",{"href":88,"dataGaName":89,"dataGaLocation":41},"https://support.gitlab.com","support portal",{"text":91,"config":92},"Customer portal",{"href":93,"dataGaName":94,"dataGaLocation":41},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"text":96,"config":97},"Status",{"href":98,"dataGaName":99,"dataGaLocation":41},"https://status.gitlab.com/","status",{"text":101,"config":102},"Terms of use",{"href":103,"dataGaName":104,"dataGaLocation":41},"/terms/","terms of use",{"text":106,"config":107},"Privacy statement",{"href":108,"dataGaName":109,"dataGaLocation":41},"/privacy/","privacy statement",{"text":111,"config":112},"Cookie preferences",{"dataGaName":113,"dataGaLocation":41,"id":114,"isOneTrustButton":26},"cookie preferences","ot-sdk-btn",{"title":116,"links":117,"subMenu":128},"Product",[118,123],{"text":119,"config":120},"DevSecOps platform",{"href":121,"dataGaName":122,"dataGaLocation":41},"/platform/","devsecops platform",{"text":124,"config":125},"AI-Assisted Development",{"href":126,"dataGaName":127,"dataGaLocation":41},"/gitlab-duo-agent-platform/","ai-assisted development",[129],{"title":130,"links":131},"Topics",[132,137,142,147,152,157,162,167],{"text":133,"config":134},"CICD",{"href":135,"dataGaName":136,"dataGaLocation":41},"/topics/ci-cd/","cicd",{"text":138,"config":139},"GitOps",{"href":140,"dataGaName":141,"dataGaLocation":41},"/topics/gitops/","gitops",{"text":143,"config":144},"DevOps",{"href":145,"dataGaName":146,"dataGaLocation":41},"/topics/devops/","devops",{"text":148,"config":149},"Version Control",{"href":150,"dataGaName":151,"dataGaLocation":41},"/topics/version-control/","version control",{"text":153,"config":154},"DevSecOps",{"href":155,"dataGaName":156,"dataGaLocation":41},"/topics/devsecops/","devsecops",{"text":158,"config":159},"Cloud Native",{"href":160,"dataGaName":161,"dataGaLocation":41},"/topics/cloud-native/","cloud native",{"text":163,"config":164},"AI for Coding",{"href":165,"dataGaName":166,"dataGaLocation":41},"/topics/devops/ai-for-coding/","ai for coding",{"text":168,"config":169},"Agentic AI",{"href":170,"dataGaName":171,"dataGaLocation":41},"/topics/agentic-ai/","agentic ai",{"title":173,"links":174},"Solutions",[175,179,184,189,194,198,203,206,211,216,221,226],{"text":176,"config":177},"Application Security Testing",{"href":178,"dataGaName":176,"dataGaLocation":41},"/solutions/application-security-testing/",{"text":180,"config":181},"Automated software delivery",{"href":182,"dataGaName":183,"dataGaLocation":41},"/solutions/delivery-automation/","automated software delivery",{"text":185,"config":186},"Agile development",{"href":187,"dataGaName":188,"dataGaLocation":41},"/solutions/agile-delivery/","agile delivery",{"text":190,"config":191},"SCM",{"href":192,"dataGaName":193,"dataGaLocation":41},"/solutions/source-code-management/","source code management",{"text":133,"config":195},{"href":196,"dataGaName":197,"dataGaLocation":41},"/solutions/continuous-integration/","continuous integration & delivery",{"text":199,"config":200},"Value stream management",{"href":201,"dataGaName":202,"dataGaLocation":41},"/solutions/value-stream-management/","value stream management",{"text":138,"config":204},{"href":205,"dataGaName":141,"dataGaLocation":41},"/solutions/gitops/",{"text":207,"config":208},"Enterprise",{"href":209,"dataGaName":210,"dataGaLocation":41},"/enterprise/","enterprise",{"text":212,"config":213},"Small business",{"href":214,"dataGaName":215,"dataGaLocation":41},"/small-business/","small business",{"text":217,"config":218},"Public sector",{"href":219,"dataGaName":220,"dataGaLocation":41},"/solutions/public-sector/","public sector",{"text":222,"config":223},"Education",{"href":224,"dataGaName":225,"dataGaLocation":41},"/solutions/education/","education",{"text":227,"config":228},"Financial services",{"href":229,"dataGaName":230,"dataGaLocation":41},"/solutions/finance/","financial services",{"title":232,"links":233},"Resources",[234,239,244,249,254,259,264,269,274,279,284,289],{"text":235,"config":236},"Install",{"href":237,"dataGaName":238,"dataGaLocation":41},"/install/","install",{"text":240,"config":241},"Quick start guides",{"href":242,"dataGaName":243,"dataGaLocation":41},"/get-started/","quick setup checklists",{"text":245,"config":246},"Learn",{"href":247,"dataGaName":248,"dataGaLocation":41},"https://university.gitlab.com/","learn",{"text":250,"config":251},"Product documentation",{"href":252,"dataGaName":253,"dataGaLocation":41},"https://docs.gitlab.com/","docs",{"text":255,"config":256},"Blog",{"href":257,"dataGaName":258,"dataGaLocation":41},"/blog/","blog",{"text":260,"config":261},"Customer success stories",{"href":262,"dataGaName":263,"dataGaLocation":41},"/customers/","customer success stories",{"text":265,"config":266},"Remote",{"href":267,"dataGaName":268,"dataGaLocation":41},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":270,"config":271},"GitLab Services",{"href":272,"dataGaName":273,"dataGaLocation":41},"/services/","services",{"text":275,"config":276},"Community",{"href":277,"dataGaName":278,"dataGaLocation":41},"/community/","community",{"text":280,"config":281},"Forum",{"href":282,"dataGaName":283,"dataGaLocation":41},"https://forum.gitlab.com/","forum",{"text":285,"config":286},"Events",{"href":287,"dataGaName":288,"dataGaLocation":41},"/events/","events",{"text":290,"config":291},"Partners",{"href":292,"dataGaName":293,"dataGaLocation":41},"/partners/","partners",{"title":295,"links":296},"Company",[297,302,307,312,317,322,327,331,336,341,346,351],{"text":298,"config":299},"About",{"href":300,"dataGaName":301,"dataGaLocation":41},"/company/","company",{"text":303,"config":304},"Jobs",{"href":305,"dataGaName":306,"dataGaLocation":41},"/jobs/","jobs",{"text":308,"config":309},"Leadership",{"href":310,"dataGaName":311,"dataGaLocation":41},"/company/team/e-group/","leadership",{"text":313,"config":314},"Team",{"href":315,"dataGaName":316,"dataGaLocation":41},"/company/team/","team",{"text":318,"config":319},"Handbook",{"href":320,"dataGaName":321,"dataGaLocation":41},"https://handbook.gitlab.com/","handbook",{"text":323,"config":324},"Investor relations",{"href":325,"dataGaName":326,"dataGaLocation":41},"https://ir.gitlab.com/","investor relations",{"text":328,"config":329},"Sustainability",{"href":330,"dataGaName":328,"dataGaLocation":41},"/sustainability/",{"text":332,"config":333},"Diversity, inclusion and belonging (DIB)",{"href":334,"dataGaName":335,"dataGaLocation":41},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":337,"config":338},"Trust Center",{"href":339,"dataGaName":340,"dataGaLocation":41},"/security/","trust center",{"text":342,"config":343},"Newsletter",{"href":344,"dataGaName":345,"dataGaLocation":41},"/company/contact/#contact-forms","newsletter",{"text":347,"config":348},"Press",{"href":349,"dataGaName":350,"dataGaLocation":41},"/press/","press",{"text":352,"config":353},"Modern Slavery Transparency Statement",{"href":354,"dataGaName":355,"dataGaLocation":41},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":357},[358,361,364],{"text":359,"config":360},"Terms",{"href":103,"dataGaName":104,"dataGaLocation":41},{"text":362,"config":363},"Cookies",{"dataGaName":113,"dataGaLocation":41,"id":114,"isOneTrustButton":26},{"text":365,"config":366},"Privacy",{"href":108,"dataGaName":109,"dataGaLocation":41},{"visibility":26,"title":368,"button":369},"The Intelligent Software Development Era: How AI is reshaping DevSecOps teams",{"config":370,"text":372},{"href":371},"/resources/developer-survey/","Get the research report",{"title":374,"description":375,"submitMessage":376,"formData":377},"The Source Newsletter","Stay updated with insights for the future of software development.","You have successfully signed up for The Source’s newsletter.",{"config":378},{"formId":379,"formName":345,"hideRequiredLabel":26},1077,{"logo":381,"subscribeLink":386,"navItems":390},{"altText":382,"config":383},"the source logo",{"src":384,"href":385},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750191004/t7wz1klfb2kxkezksv9t.svg","/the-source/",{"text":387,"config":388},"Subscribe",{"href":389},"#subscribe",[391,395,399],{"text":392,"config":393},"Artificial Intelligence",{"href":394},"/the-source/ai/",{"text":396,"config":397},"Security & Compliance",{"href":398},"/the-source/security/",{"text":400,"config":401},"Platform & Infrastructure",{"href":402},"/the-source/platform/",{"amanda-rueda":404,"andre-michael-braun":405,"andrew-haschka":406,"ayoub-fandi":407,"bob-stevens":408,"brian-wald":409,"bryan-ross":5,"chandler-gibbons":410,"cherry-han":411,"dave-steer":412,"ddesanto":413,"derek-debellis":414,"emilio-salvador":415,"erika-feldman":416,"george-kichukov":417,"gitlab":418,"grant-hickman":419,"haim-snir":420,"iganbaruch":421,"jason-morgan":422,"jessie-young":423,"jlongo":424,"joel-krooswyk":425,"josh-lemos":426,"joshua-carroll":427,"julie-griffin":428,"kristina-weis":429,"lee-faus":430,"marco-caronna":431,"michelle-gill":432,"nathen-harvey":433,"ncregan":434,"rob-smith":435,"rschulman":436,"sabrina-farmer":437,"sandra-gittlen":438,"sharon-gaudin":439,"stephen-walters":440,"taylor-mccaslin":441},"Amanda Rueda","Andre Michael Braun","Andrew Haschka","Ayoub Fandi","Bob Stevens","Brian Wald","Chandler Gibbons","Cherry Han","Dave Steer","David DeSanto","Derek DeBellis","Emilio Salvador","Erika Feldman","George Kichukov","GitLab","Grant Hickman","Haim Snir","Itzik Gan Baruch","Jason Morgan","Jessie Young","Joseph Longo","Joel Krooswyk","Josh Lemos","Joshua Carroll","Julie Griffin","Kristina Weis","Lee Faus","Marco Caronna","Michelle Gill","Nathen Harvey","Niall Cregan","Rob Smith","Robin Schulman","Sabrina Farmer","Sandra Gittlen","Sharon Gaudin","Stephen Walters","Taylor McCaslin",{"ai":392,"platform":400,"security":396},[444,493,538,583,627,670,714],{"id":445,"title":446,"body":6,"category":447,"config":448,"content":452,"description":454,"extension":24,"meta":478,"navigation":26,"path":479,"seo":480,"slug":482,"stem":483,"type":484,"__hash__":485,"date":453,"timeToRead":455,"keyTakeaways":486,"articleBody":460,"faq":487,"heroImage":477},"theSource/en-us/the-source/ai/why-enterprises-can-t-afford-to-standardize-on-one-ai-model.yml","Why enterprises can’t afford to standardize on one AI model","ai",{"layout":8,"template":449,"featured":450,"author":29,"sourceCTA":451,"isHighlighted":450,"authorName":5},"TheSourceArticle",false,"software-innovation-report-2025",{"date":453,"title":446,"description":454,"timeToRead":455,"keyTakeaways":456,"articleBody":460,"faq":461,"heroImage":477},"2026-03-26","Explore why enterprises need AI model diversity to match tasks to performance, cost, and governance needs, and how orchestration makes it work at scale.","5 min read",[457,458,459],"No single AI model can optimize for speed, quality, and cost at once. Enterprises that route tasks to the right model extract more value from AI while keeping spending under control.","IDC projects that organizations will underestimate AI infrastructure costs by 30% through 2027. Applying FinOps practices to model spend gives enterprises the visibility and control they need to scale.","The most resilient enterprise AI systems support model diversity within a governed control plane, enabling teams to use frontier, self-hosted, and custom models without sacrificing reliability or compliance.","Most organizations are setting themselves up for failure by adopting AI the same way they buy software: pick a vendor, standardize, and roll it out everywhere.\n\nThe assumption is that one model will solve every problem. But a model that excels at code generation might struggle with security analysis, while a frontier model that’s perfect for prototyping may not meet your data residency requirements.\n\nSolving this mismatch requires flexibility in how you deploy AI models. Some teams need advanced, large-scale models for cutting-edge reasoning, while others need specialized models for domain-specific work. And, critically, you need the ability to mix and match based on the task at hand.\n\n## The AI Paradox: Coding is just one piece of the puzzle\nThe current wave of AI adoption focuses almost entirely on accelerating code generation. But coding represents a fraction of what developers actually do. According to [GitLab’s 2025 Global DevSecOps Survey](https://about.gitlab.com/developer-survey/), developers spend only about 15% of their time writing code. The rest goes to planning, reviewing code, testing, debugging, managing dependencies, coordinating with teammates, and navigating compliance requirements.\n\nThis creates an AI paradox: AI is accelerating coding, but disconnected toolchains and manual coordination overhead have slowed overall productivity so much that it’s costing nearly a full workday per developer each week.\n\nTo solve this, AI needs to work across the entire development lifecycle, not just code generation. The challenge is that different activities across the software lifecycle have fundamentally different performance requirements:\n* **Speed-critical tasks** like auto-completing code or suggesting fixes during active development need sub-second response times, which might favor smaller, locally hosted models.\n* **Quality-critical tasks** like architectural planning or security analysis justify the cost of frontier models with superior reasoning.\n* **Cost-sensitive tasks** at high volume, like running tests or updating dependencies across hundreds of repositories, require economical options to stay viable.\n\nA single model can’t optimize for all three simultaneously. The organizations that gain the most from AI are the ones building systems flexible enough to route each task to the model that best fits its performance, quality, and cost profile.\n\n## Premium models for every task will break your budget\nPrice is a major factor influencing which model teams should choose for each job. A practical cost-to-value strategy might look like this:\n* For high-volume, routine work like writing commit messages, summarizing log files, or writing test cases, teams lean toward cheaper and faster options, including open-source models where feasible.\n* For tasks that demand complex reasoning, like code generation, teams pay for more capability.\n* For specialized models that are more deterministic, teams might be willing to pay a premium for infrastructure-as-code generation or high-accuracy data transformation.\n\nOptionality — the ability to choose between different models based on the task — is a hedge against model performance differences, pricing swings, and the reality that providers may sunset products or go out of business altogether.\n\nBut where does that optionality come from? There are essentially three sources:\n1. Commercial frontier models (Anthropic, OpenAI, Google) deliver cutting-edge performance and are constantly improving, but you’re dependent on vendor roadmaps and pricing.\n1. Self-hosted commercial or open-source models give you control over data residency, costs, and availability, but require infrastructure management and, in the case of open source, cannot handle agentic workflows.\n1. Domain-specific models you’ve trained can outperform general models on narrow, high-stakes tasks where you have unique data and clear success criteria, but such work requires specialist expertise and can be operationally very expensive.\n\nEach approach has trade-offs. The key is building systems that let you use all three strategically.\n\n## Managing AI like cloud infrastructure\nModel flexibility only creates value if you can manage the economics behind it. The price gap between models is substantial: complex reasoning models can cost 500% more per request than general-purpose models that work fine for routine tasks.\n\nThis is where model routing — the ability to define which models get used for which tasks — becomes critical. A code review might route to a frontier model, while commit message generation uses a faster, cheaper option.\n\nBut routing alone isn’t enough. Enterprises need the same financial controls they have for cloud infrastructure: quotas to prevent runaway spending, limits to enforce budget discipline, and chargeback models that allocate costs to the departments actually using AI. Without these guardrails, AI adoption becomes financially unsustainable.\n\nThis is why [FinOps practices](https://about.gitlab.com/the-source/platform/finops-balancing-financial-responsibility-and-innovation/) are extending to AI. [According to IDC](https://www.cio.com/article/4107377/cios-will-underestimate-ai-infrastructure-costs-by-30.html), organizations will underestimate their AI infrastructure costs by 30% through 2027, and combining GenAI with FinOps processes will be essential for managing this complexity. (And that's just for GenAI — the impact of underestimating agentic AI could be considerably higher.) The organizations that treat AI spend like cloud spend — with visibility, accountability, and governance — are the ones that will scale AI successfully.\n\n## How customization delivers ROI\nModel flexibility also depends on context. AI needs information spread across systems that weren’t designed to work together by default. A developer debugging an issue might need to reference the work backlog, pull recent discussions from Slack, and review app performance metrics in Grafana. If every system has its own AI experience and none of them connect cleanly, AI slows productivity.\n\nFortunately, recent open source developments have paved the way forward: [Model Context Protocol (MCP)](https://about.gitlab.com/topics/ai/model-context-protocol/) makes AI reliable by letting tools share relevant context and actions across a single workspace.\n\nThis shared foundation (with unified context) is what makes meaningful customization possible. In fact, the most effective customization works best in layers because you can encode how your organization performs work within each one.\n\nI think about this in three layers. Most developers will rely on pre-built agents and workflows that make AI available for common tasks without requiring expertise. Power users shape how a model operates through detailed prompting, essentially teaching it to follow their organization's playbook. And experts connect multiple agents into governed flows that mirror how humans deliver work, with strict review protocols in place.\n\nOrganizations get the most ROI by designing a system where AI is constrained by context and accountability, and where they can connect different models based on their requirements: frontier commercial models, self-hosted instances of commercial models for data residency, or specialized models they’ve already trained for domain-specific work.\n\n## Reliability comes from orchestration, not standardization\nEnterprise AI adoption requires outputs that reliably hold up inside real systems, under real constraints. \n\nThe most successful organizations are building systems that support model diversity while maintaining strict governance. They treat AI spend like cloud spend, with model routing, quotas, and chargeback. And they’re focusing on orchestration to ensure AI fits naturally into daily workflows and relevant context is shared across tools.\n\nA rigorous selection process matters here. The best platforms use under-the-hood subagents that evaluate models across quality, performance, and cost for each type of operation — and make those evaluations visible to users so teams understand why a given model is being used for a given task. That transparency creates trust. And when teams have requirements that differ from the defaults, they should be able to override model selections with their own preferences, or bring their own models entirely.\n\nThis approach lets them use frontier models where performance matters, self-hosted models where data residency is required, and specialized models where domain expertise makes the difference. The common thread is the governed control plane that maintains the same standards for reliability and security regardless of model source.\n\nThe future of enterprise AI isn’t about finding one perfect model. It’s about building systems that let you connect the models that match your requirements.",[462,465,468,471,474],{"header":463,"content":464},"Why can't enterprises rely on a single AI model for all tasks?","Different tasks have fundamentally different performance requirements. Speed-critical tasks favor smaller, locally hosted models; quality-critical tasks justify frontier model costs; and high-volume, cost-sensitive tasks require economical options. No single model can optimize for speed, quality, and cost simultaneously.",{"header":466,"content":467},"How much more do complex AI reasoning models cost compared to general-purpose models?","Complex reasoning models can cost up to 500% more per request than general-purpose models. This price gap makes model routing — directing specific tasks to appropriately priced models — essential for keeping enterprise AI spending financially sustainable at scale.",{"header":469,"content":470},"What is AI model routing and why do enterprises need it?","Model routing defines which AI models handle which tasks — for example, sending code reviews to a frontier model while routing commit message generation to a faster, cheaper option. Combined with quotas, spending limits, and chargeback models, it gives enterprises the same financial controls they apply to cloud infrastructure.",{"header":472,"content":473},"How much are organizations underestimating their AI infrastructure costs?","According to IDC, organizations will underestimate AI infrastructure costs by 30% through 2027. The gap could be even larger when accounting for agentic AI workloads, making FinOps practices — visibility, accountability, and governance over AI spend — essential for scaling successfully.",{"header":475,"content":476},"What are the three sources of AI model optionality for enterprises?","Enterprises can draw from: (1) commercial frontier models like Anthropic, OpenAI, and Google for cutting-edge performance; (2) self-hosted commercial or open-source models for data residency and cost control; and (3) domain-specific models trained on proprietary data for narrow, high-stakes tasks where unique data creates a performance edge.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1774036667/gukolblclgirfae9a1qg.png",{},"/en-us/the-source/ai/why-enterprises-can-t-afford-to-standardize-on-one-ai-model",{"config":481,"title":446,"description":454},{"noIndex":450},"why-enterprises-can-t-afford-to-standardize-on-one-ai-model","en-us/the-source/ai/why-enterprises-can-t-afford-to-standardize-on-one-ai-model","article","sFWU0kpwu6i7oZqyfu_731NCwI9WE55ZISQiIPnNKAg",[457,458,459],[488,489,490,491,492],{"header":463,"content":464},{"header":466,"content":467},{"header":469,"content":470},{"header":472,"content":473},{"header":475,"content":476},{"id":494,"title":495,"body":6,"category":447,"config":496,"content":498,"description":500,"extension":24,"meta":523,"navigation":26,"path":524,"seo":525,"slug":528,"stem":529,"type":484,"__hash__":530,"date":499,"timeToRead":455,"keyTakeaways":531,"articleBody":505,"faq":532,"heroImage":522},"theSource/en-us/the-source/ai/the-real-cost-of-build-vs-buy-for-agentic-ai-in-regulated-industries.yml","The real cost of build vs. buy for agentic AI in regulated industries",{"layout":8,"template":449,"featured":450,"author":29,"sourceCTA":497,"isHighlighted":450,"authorName":5},"global-devsecops-report-2025",{"date":499,"title":495,"description":500,"timeToRead":455,"keyTakeaways":501,"articleBody":505,"faq":506,"heroImage":522},"2026-03-24","Agentic AI is repeating the DevOps toolchain sprawl pattern — and the organizations that recognize it early will have a significant advantage.",[502,503,504],"In regulated industries, building agentic AI in-house is a multi-year platform engineering commitment. The regulatory, security, and integration obligations tend to be far greater than initial analyses suggest.","Agentic AI is following the same fragmentation arc as DevOps toolchains. Organizations that make a platform decision early, rather than a series of point decisions, can compress years of catch-up into months.","For a team of roughly 200 developers, an internal AI build costs an estimated $1.4M in year one with 12–18 months to first use case. A purpose-built platform runs roughly $410K–$460K with deployment in days.","There's a pattern regulated industries know well. A new capability emerges. Teams spin up point solutions. Each one solves a discrete problem. Before long, you're managing fifteen tools that were never designed to work together and spending more engineering time on integration than on the outcomes you were trying to achieve.\n\nThat's what happened with DevOps toolchains. And it's exactly what's starting to happen with agentic AI.\n\n## The build trap\n\nWhen AI coding tools started delivering real productivity gains, the natural instinct for many organizations was to go deeper. A code assistant here. An internal AI gateway there. A few open-source models, some custom orchestration, and suddenly you're calling it a platform.\n\nThere's a reason this happens. Technology teams are wired to build, and that instinct isn't wrong. Building is how engineers learn, how teams develop expertise, and how genuinely novel problems get solved. The same DIY energy that shaped the early DevOps era produced some remarkable tools and practices. But that same divergent experimentation rarely serves the broader organization. Organizations don't want some people to be AI-enabled. They want everyone to be AI-enabled, consistently, in a way that's governable and scalable. That's the tension at the center of every build vs. buy conversation right now.\n\nBefore going further, it's worth naming what you're actually deciding. Most build vs. buy conversations quietly compare two very different things:\n\n* **Build**: Assemble open models + cloud AI services + custom orchestration + custom governance + the underlying infrastructure (compute, storage, databases, networking) required to run it all. You are the platform vendor.\n* **Buy**: Adopt a platform that already unifies models, tools, orchestration, and governance across the SDLC. You are the platform consumer.\n\nThat distinction matters enormously in a regulated environment. Building an internal agentic AI platform in banking or insurance is a multi-year platform engineering commitment with regulatory surface area most organizations underestimate:\n\n* **Model lifecycle management**: Selection, tuning, drift monitoring, deprecation. Ongoing, always on.\n* **Security hardening**: Agents that touch code and infrastructure trigger obligations well beyond a standard SaaS integration: prompt injection defenses, sandboxing, SIEM and DLP integration, red-team testing.\n* **Regulatory documentation**: Under frameworks like DORA and the EU AI Act, an internal AI system is a *regulated system*. You define the risk classification, maintain the documentation, and produce the audit evidence, meaning recurring obligations for the life of the system.\n* **Platform integration**: Agents must be embedded in your SDLC to deliver meaningful value. Every touchpoint is a mini-product that requires maintenance across IDE versions, tooling changes, and org restructures.\n\nAnd then there's the cost that rarely makes it into initial analyses: every engineer building the platform is an engineer *not* modernizing a legacy pipeline, remediating security debt, or accelerating a critical delivery program.\n\n## Agentic AI is following the DevOps playbook — for better and worse\n\nLet’s think back to the DevOps era. Teams didn't set out to build fragmented toolchains, they made rational, incremental decisions. A better CI tool here. A preferred SCM there. A security scanner bolted on. A separate secrets manager. A different deployment orchestrator.\n\nEach decision made sense in isolation. Collectively, [they created sprawl](https://about.gitlab.com/the-source/platform/more-code-more-bottlenecks-tackling-the-ai-paradox/): integration burden, inconsistent governance, duplicated effort, and no single view of what was happening across the SDLC.\n\nThe industry spent the better part of a decade consolidating around platforms precisely because that sprawl was expensive and hard to audit, two things regulated organizations can't afford. Agentic AI is following the same arc, faster. The organizations that recognize this early enough to make a *platform decision*, rather than a series of point decisions, will compress years of catch-up into months.\n\n![Regulated organizations spent a decade consolidating fragmented DevOps toolchains. Agentic Al is following the same arc — faster.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1774033724/hhkpa2moojmnjfp4q5tb.png)\n\n## A framework for the decision\n\nRather than a generic build vs. buy debate, anchor on three questions:\n\n1. **Is your requirement truly unique?** Build is defensible when you have workflows no vendor supports, deployment patterns no platform can meet, and genuine appetite to fund platform engineering as an enduring capability. Modern platforms, however, increasingly meet regulated organizations where they are and support cloud-hosted, self-managed, and dedicated single-tenant deployments to narrow the gap between platform convenience and enterprise control requirements. If your goals are faster code review, pipeline migration, security triage, or test automation, you're in territory where platforms are already delivering for your peers.\n2. **How much regulatory surface area can you realistically own?** Building makes you the system owner under ICT risk frameworks, the AI provider under emerging AI regulations, and the entity accountable for model behavior, documentation, and monitoring. Buying doesn't eliminate regulatory responsibility, but it offloads platform-level obligations to a vendor whose business depends on getting them right, freeing your compliance cycles for how AI is used, not how it's built.\n3. **What's your time horizon?** If your board expects demonstrable AI value across multiple teams within 12–24 months, a multi-year internal build is misaligned with those expectations from day one. \n\nThe numbers reflect this. For example, for a regulated organization of roughly 200 developers, an internal build on a cloud AI foundation typically runs ≈$1.4M in year one — engineering labor, infrastructure, integration, security, compliance — with 6–12 months before anything is production-ready and 2–3 dedicated FTEs required just to keep it stable. Time to first real use case: 12–18 months, conservatively.\n\nAn agentic AI platform like [GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo-agent-platform/) runs ≈$410K–$460K for the same population with initial deployment in days and early productivity gains of 15–25% (sample from previous implementations) once agents are embedded in everyday workflows. Time to first use case: weeks, not years. That's not a marginal difference. It's the difference between showing your board AI ROI this fiscal year or explaining why you're still building infrastructure.\n\n*Analysis courtesy of Sumedh Jigjinni and GitLab's [Business Value Services](https://handbook.gitlab.com/handbook/solutions-architects/sa-practices/business-value-consulting/) team.*\n\n## “But we need to customize”\n\nThis is the most common objection for regulated industries. The goal isn't to take customization off the table. It's to right-size where customization happens.\n\nThe best agentic AI platforms support a layered model that serves every level of the organization. Most users don't need to build anything: they access agents created by others through a shared catalog, getting immediate value within a governed environment. Power users can tailor agents to their specific context by adjusting system prompts and parameters, without writing a line of code. Teams with genuinely differentiated use cases can develop custom agent flows and publish them to the catalog, turning internal work into organizational capability. And experts can still integrate external models, domain-specific tools, and proprietary data sources through a governed interface, rather than as a parallel shadow platform.\n\nThis is what intelligent orchestration actually looks like: [not uniformity, but coherence](https://about.gitlab.com/the-source/ai/the-next-wave-of-devsecops-team-of-one-manager-of-many/). Everyone operates within the same governance layer, with flexibility that scales to need.\n\nThe lesson from DevOps consolidation wasn't \"don't use tools.\" It was \"don't let tools use you.\" Agentic AI deserves the same discipline.",[507,510,513,516,519],{"header":508,"content":509},"What is the difference between building and buying an agentic AI platform?","Building means assembling open models, cloud AI services, custom orchestration, and governance infrastructure yourself — making your team the platform vendor. Buying means adopting a unified platform that already combines models, tools, orchestration, and governance. In regulated environments, that distinction carries significant compliance and resourcing implications.",{"header":511,"content":512},"How much does it cost to build agentic AI in-house vs. buying a platform?","For a team of roughly 200 developers, an internal build typically costs around $1.4M in year one, requires 2–3 dedicated FTEs to maintain, and takes 12–18 months to reach a first real use case. A purpose-built platform like GitLab Duo Agent Platform runs approximately $410K–$460K with deployment in days.",{"header":514,"content":515},"Why is agentic AI following the same fragmentation pattern as DevOps toolchains?","Just as DevOps teams made rational, incremental tool decisions that collectively created sprawl, agentic AI teams are assembling point solutions that weren't designed to work together. The result is the same: integration burden, inconsistent governance, and no unified view across the SDLC.",{"header":517,"content":518},"What regulatory obligations does building an internal AI system create?","Under frameworks like DORA and the EU AI Act, an internally built AI system is a regulated system. The building organization owns risk classification, audit documentation, model lifecycle management, security hardening, and ongoing compliance monitoring — obligations that persist for the life of the system.",{"header":520,"content":521},"Can organizations still customize agents if they buy a platform instead of building?","Yes. Leading agentic AI platforms support a layered model: most users access pre-built agents through a shared catalog, power users adjust prompts and parameters without coding, and teams with differentiated needs can build and publish custom agent flows — all within a single governance layer.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1774034036/ulsa40ld4bz9t1rjez3y.png",{},"/en-us/the-source/ai/the-real-cost-of-build-vs-buy-for-agentic-ai-in-regulated-industries",{"config":526,"title":527,"description":500},{"noIndex":450},"Build vs. buy for agentic AI in regulated industries","the-real-cost-of-build-vs-buy-for-agentic-ai-in-regulated-industries","en-us/the-source/ai/the-real-cost-of-build-vs-buy-for-agentic-ai-in-regulated-industries","8YiHH3Xt0YoJRdQI-e6p5_nStW4YVlE9jjglEO0MqQU",[502,503,504],[533,534,535,536,537],{"header":508,"content":509},{"header":511,"content":512},{"header":514,"content":515},{"header":517,"content":518},{"header":520,"content":521},{"id":539,"title":540,"body":6,"category":541,"config":542,"content":544,"description":545,"extension":24,"meta":570,"navigation":26,"path":571,"seo":572,"slug":573,"stem":574,"type":484,"__hash__":575,"date":546,"timeToRead":547,"heroImage":548,"keyTakeaways":576,"articleBody":553,"faq":577},"theSource/en-us/the-source/platform/beyond-the-portal-hype-why-you-need-a-platform-first.yml","Beyond the portal hype: Why you need a platform first","platform",{"layout":8,"template":449,"featured":26,"author":29,"sourceCTA":543,"isHighlighted":450,"authorName":5},"source-lp-how-to-build-a-resilient-software-development-practice",{"title":540,"description":545,"date":546,"timeToRead":547,"heroImage":548,"keyTakeaways":549,"articleBody":553,"faq":554},"Discover why many internal developer portals fall short and why a platform-first approach is key to improving developer productivity.","2025-07-15T00:00:00.000Z","6 min read","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752086082/z2udikxenysukvroywvb.png",[550,551,552],"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.",[555,558,561,564,567],{"header":556,"content":557},"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":559,"content":560},"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":562,"content":563},"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":565,"content":566},"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":568,"content":569},"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.",{},"/en-us/the-source/platform/beyond-the-portal-hype-why-you-need-a-platform-first",{"title":540,"ogTitle":540,"description":545,"ogDescription":545,"ogImage":548},"beyond-the-portal-hype-why-you-need-a-platform-first","en-us/the-source/platform/beyond-the-portal-hype-why-you-need-a-platform-first","OW2CZs5fgbPtm9ytXJZFZKhI496dSEn2U-iqjk0IupA",[550,551,552],[578,579,580,581,582],{"header":556,"content":557},{"header":559,"content":560},{"header":562,"content":563},{"header":565,"content":566},{"header":568,"content":569},{"id":584,"title":585,"body":6,"category":541,"config":586,"content":588,"description":590,"extension":24,"meta":614,"navigation":26,"path":615,"seo":616,"slug":617,"stem":618,"type":484,"__hash__":619,"date":589,"timeToRead":591,"heroImage":592,"keyTakeaways":620,"articleBody":597,"faq":621},"theSource/en-us/the-source/platform/transform-your-platform-onboarding-for-higher-adoption-rates.yml","Transform your platform onboarding for higher adoption rates",{"layout":8,"template":449,"author":29,"featured":26,"sourceCTA":587,"isHighlighted":450,"authorName":5},"source-lp-devsecops-the-key-to-modern-security-resilience",{"title":585,"date":589,"description":590,"timeToRead":591,"heroImage":592,"keyTakeaways":593,"articleBody":597,"faq":598},"2025-07-01","Redesign your platform onboarding to boost adoption, reduce friction, and create seamless experiences for development teams.","4 min read","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463510/hm90bhwzptl1b2gwovhx.png",[594,595,596],"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.",[599,602,605,608,611],{"header":600,"content":601},"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":603,"content":604},"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":606,"content":607},"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":609,"content":610},"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":612,"content":613},"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.",{},"/en-us/the-source/platform/transform-your-platform-onboarding-for-higher-adoption-rates",{"title":585,"description":590,"ogImage":592},"transform-your-platform-onboarding-for-higher-adoption-rates","en-us/the-source/platform/transform-your-platform-onboarding-for-higher-adoption-rates","wUVy9rGZsRoCqArzq6O4GLy4nIR0ussomfArbloCtlM",[594,595,596],[622,623,624,625,626],{"header":600,"content":601},{"header":603,"content":604},{"header":606,"content":607},{"header":609,"content":610},{"header":612,"content":613},{"id":628,"title":629,"body":6,"category":541,"config":630,"content":632,"description":634,"extension":24,"meta":657,"navigation":26,"path":658,"seo":659,"slug":660,"stem":661,"type":484,"__hash__":662,"date":633,"timeToRead":547,"heroImage":635,"keyTakeaways":663,"articleBody":640,"faq":664},"theSource/en-us/the-source/platform/unlock-developer-potential-with-effective-platform-teams.yml","Unlock developer potential with effective platform teams",{"layout":8,"template":449,"author":29,"featured":450,"sourceCTA":631,"isHighlighted":450,"authorName":5},"source-lp-building-a-resilient-software-development-practice",{"title":629,"date":633,"description":634,"timeToRead":547,"heroImage":635,"keyTakeaways":636,"articleBody":640,"faq":641},"2025-06-24","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",[637,638,639],"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.",[642,645,648,651,654],{"header":643,"content":644},"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":646,"content":647},"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":649,"content":650},"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":652,"content":653},"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":655,"content":656},"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.",{},"/en-us/the-source/platform/unlock-developer-potential-with-effective-platform-teams",{"title":629,"description":634,"ogImage":635},"unlock-developer-potential-with-effective-platform-teams","en-us/the-source/platform/unlock-developer-potential-with-effective-platform-teams","EMJBFPu_zC-G5cLJOa2-6pawcHZA6SU2TzVqp5BmcUA",[637,638,639],[665,666,667,668,669],{"header":643,"content":644},{"header":646,"content":647},{"header":649,"content":650},{"header":652,"content":653},{"header":655,"content":656},{"id":671,"title":672,"body":6,"category":541,"config":673,"content":675,"description":677,"extension":24,"meta":700,"navigation":26,"path":701,"seo":702,"slug":704,"stem":705,"type":484,"__hash__":706,"date":676,"timeToRead":547,"heroImage":678,"keyTakeaways":707,"articleBody":683,"faq":708},"theSource/en-us/the-source/platform/building-a-communication-strategy-for-platform-engineering-teams.yml","Building a communication strategy for platform engineering teams",{"layout":8,"template":449,"author":29,"featured":26,"sourceCTA":674,"isHighlighted":450,"authorName":5},"source-lp-measuring-success-in-software-development-a-guide-for-leaders",{"title":672,"date":676,"description":677,"timeToRead":547,"heroImage":678,"keyTakeaways":679,"articleBody":683,"faq":684},"2025-06-17","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",[680,681,682],"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.",[685,688,691,694,697],{"header":686,"content":687},"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":689,"content":690},"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":692,"content":693},"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":695,"content":696},"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":698,"content":699},"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.",{},"/en-us/the-source/platform/building-a-communication-strategy-for-platform-engineering-teams",{"title":672,"description":677,"ogImage":678,"config":703},{"ignoreTitleCharLimit":26},"building-a-communication-strategy-for-platform-engineering-teams","en-us/the-source/platform/building-a-communication-strategy-for-platform-engineering-teams","uvF_arptQEkRG_XUuVS8dFEh4Msh8EF4BDvAlvXnlog",[680,681,682],[709,710,711,712,713],{"header":686,"content":687},{"header":689,"content":690},{"header":692,"content":693},{"header":695,"content":696},{"header":698,"content":699},{"id":715,"title":716,"body":6,"category":541,"config":717,"content":718,"description":720,"extension":24,"meta":747,"navigation":26,"path":748,"seo":749,"slug":750,"stem":751,"type":484,"__hash__":752,"date":719,"timeToRead":721,"heroImage":722,"keyTakeaways":753,"articleBody":727,"faq":754},"theSource/en-us/the-source/platform/platform-engineering-its-about-culture-not-tools.yml","Platform engineering: It’s about culture, not tools",{"layout":8,"template":449,"author":29,"featured":26,"sourceCTA":543,"isHighlighted":450,"authorName":5},{"title":716,"date":719,"description":720,"timeToRead":721,"heroImage":722,"keyTakeaways":723,"articleBody":727,"faq":728},"2025-06-10","Discover how platform engineering evolves beyond DevOps to foster collaboration across teams while balancing autonomy with governance.","7 min read","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463480/xeygsznqg7uo5cihn2oj.png",[724,725,726],"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.",[729,732,735,738,741,744],{"header":730,"content":731},"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":733,"content":734},"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":736,"content":737},"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":739,"content":740},"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":742,"content":743},"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":745,"content":746},"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.",{},"/en-us/the-source/platform/platform-engineering-its-about-culture-not-tools",{"title":716,"description":720,"ogImage":722},"platform-engineering-its-about-culture-not-tools","en-us/the-source/platform/platform-engineering-its-about-culture-not-tools","UAUsoiWResk2tQCiJPkXvqCi52kjFKP3Em2jEzKfXcc",[724,725,726],[755,756,757,758,759,760],{"header":730,"content":731},{"header":733,"content":734},{"header":736,"content":737},{"header":739,"content":740},{"header":742,"content":743},{"header":745,"content":746},1776438146623]