# Delivery Engineering vs. DevOps — vad är skillnaden? - Författare: [Jonas Odencrants](https://paperphyte.com/konsulter/jonas-odencrants), [Paperphyte](https://paperphyte.com) - Publicerad: 2026-05-07 - Kategori: DevOps - Etiketter: DevOps, Delivery Engineering, Plattform, Roller - Källa: En av de vanligaste frågorna vi får. Korta svaret: DevOps är ett arbetssätt, Delivery Engineering är en disciplin. Här är det längre svaret — utan fluff. Vi får frågan ofta — i upphandlingar, på intervjuer och i kafferaster: ”Är inte [Delivery Engineering](https://paperphyte.com/ordlista/delivery-engineering) bara ett nytt namn på [DevOps](https://paperphyte.com/ordlista/devops)?” Korta svaret är nej. Längre svaret är värt fem minuter. ## DevOps är ett arbetssätt DevOps växte fram som en motreaktion på den klassiska väggen mellan utvecklare som skriver koden och operations som driftar den. Idén är enkel: samma team som bygger funktionen ska också ansvara för att den funkar i produktion. ”You build it, you run it.” Det är inte en roll — det är ett sätt att organisera ansvar. Praktiskt innebär det att utvecklingsteam äger automation, [observability](https://paperphyte.com/ordlista/observability), on-call och infrastrukturen kring sin egen tjänst. Inte hela molnplattformen — bara sin del av den. Och fördelningen mellan ”sin del” och ”någon annans del” är ett av de viktigaste designbesluten en organisation gör. ## Delivery Engineering är en disciplin Delivery Engineering handlar om vägen från commit till produktion. Pipelines, byggsystem, artefakt-hantering, release-strategier, [feature flags](https://paperphyte.com/ordlista/feature-flags), [progressive delivery](https://paperphyte.com/ordlista/progressive-delivery). Det är inte en filosofi — det är ett hantverk. Och det är ofta ett eget team som bygger plattformen som låter alla andra team leverera snabbt och säkert. Tänk på det så här: om DevOps säger ”team X äger sin tjänst hela vägen ut”, så säger Delivery Engineering ”här är spåret som tar dig dit utan att du behöver uppfinna det själv”. ## Var överlappar de? I praktiken: [CI/CD](https://paperphyte.com/ordlista/ci-cd). Båda disciplinerna investerar tungt i pipelines, men av olika skäl. Ett DevOps-team bygger pipelines för sin egen tjänst. Ett Delivery Engineering-team bygger pipelines som plattform — så att 50 andra team inte behöver bygga sin egen variant. Det är där förvirringen kommer ifrån. Verktygen är samma. Syftet är olika. ## När behöver man vad? Liten organisation, ett fåtal team — då räcker DevOps-tankesättet. Varje team äger sin grej från ände till ände och bygger precis så mycket pipeline som de själva behöver. När ni växer och hamnar med 10+ team som alla löser samma deployment-problem på 10 olika sätt, då börjar Delivery Engineering bli en investering som betalar sig snabbt. Inte för att teamen inte klarar sig själva — utan för att det är slöseri att alla uppfinner samma hjul, och för att en gemensam plattform gör att de tjatigaste delarna av leveransen blir någon annans problem. ## Vårt korta svar > DevOps berättar hur ni delar ansvar. Delivery Engineering berättar hur ni delar verktygen. Båda behövs — men inte alltid lika mycket samtidigt. Om någon påstår att det är samma sak — fråga vad de menar med båda. Ofta menar de bara CI/CD. --- Det här är Markdown-versionen av ett inlägg i [Paperphytes anteckningsbok](https://paperphyte.com/anteckningsbok). Originalet finns på . © Paperphyte AB. Ange källan med länk när du citerar eller sammanfattar texten. Frågor om innehållet? [Kontakta Paperphyte](https://paperphyte.com/kontakt).