[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"sanity-BU7_NXh1HxdUk_P5XflfHl9zgn5f3TkQ0bOJFC8X-lc":3,"sanity-uk_anFRxF0GRkiPs8waLYv1OTwqwvOZiD5IppHqWYgE":737},{"data":4,"sourceMap":-1},{"latestPodcast":5,"latestReleases":14,"post":39,"recent":712},[6],{"_id":7,"publishedAt":8,"slug":9,"sponsored":12,"title":13},"7ebd76d2-cebc-4b88-82f9-3dfb2c8bc5ca","2026-07-08T04:40:00.000Z",{"_type":10,"current":11},"slug","what-s-left-for-infrastructure-as-code-after-ai-moves-in",true,"What's left for infrastructure-as-code after AI moves in?",[15,21,27,33],{"_id":16,"publishedAt":17,"slug":18,"title":20},"eb5b66eb-9410-4329-83bb-22bbff39402a","2026-04-28T13:00:00.000Z",{"_type":10,"current":19},"turn-scattered-knowledge-into-trusted-intelligence","Turning scattered knowledge into trusted intelligence: Stack Internal 2026.3",{"_id":22,"publishedAt":23,"slug":24,"title":26},"369c2401-b62e-4a37-8ff8-bf603023ecad","2026-03-02T15:03:00.988Z",{"_type":10,"current":25},"what-s-new-at-stack-overflow-march-2026","What’s new at Stack Overflow: March 2026",{"_id":28,"publishedAt":29,"slug":30,"title":32},"5e9053a4-07ea-447c-91ea-29e0b6228537","2026-02-02T15:00:00.000Z",{"_type":10,"current":31},"what-s-new-at-stack-overflow-february-2026","What’s new at Stack Overflow: February 2026",{"_id":34,"publishedAt":35,"slug":36,"title":38},"a1b538eb-a8a6-46d0-80a1-ac70ec9bb935","2026-01-05T10:00:00.000-05:00",{"_type":10,"current":37},"what-s-new-at-stack-overflow-january-2026","What’s new at Stack Overflow: January 2026",{"_createdAt":40,"_id":41,"_rev":42,"_type":43,"_updatedAt":44,"author":45,"body":62,"comments":12,"dateUrl":678,"excerpt":679,"image":680,"legacyBody":683,"product":85,"publishedAt":686,"slug":687,"sponsored":85,"tags":689,"title":711,"visible":12},"2023-05-25T09:39:18Z","wp-post-18112","dgl3SCUzppW3U2LvCoSsMu","blogPost","2023-07-13T14:55:59Z",[46],{"_createdAt":47,"_id":48,"_rev":49,"_type":50,"_updatedAt":51,"avatar":52,"bio":57,"employee":58,"name":59,"slug":60},"2023-05-23T16:27:18Z","wp-author-cap-18115","07ZbrKPSUrjrV4wQ6fDpaa","blogAuthor","2023-06-20T15:05:10Z",{"_type":53,"asset":54},"image",{"_ref":55,"_type":56},"image-8cf69a05d6ef9dfd6db2ac2da2518a7d5e4b90d1-386x426-png","reference","Daniel Orner is a Staff Software Engineer at Flipp and has previously worked at IBM. You can find his articles, ranging from musings on event-driven microservices to what Ruby can learn from Go, at his GitHub profile. He lives in Toronto with a wife and four small people who alternate between enriching and enraging him.","none","Daniel Orner",{"current":61},"daniel-orner",[63,87,112,120,130,138,146,154,162,170,178,186,195,203,216,225,241,257,269,280,292,312,320,344,349,357,369,381,393,432,444,456,464,472,480,488,496,515,523,531,547,555,563,571,579,587,595,603,611,619,627,635,643,651,659],{"_key":64,"_type":65,"children":66,"markDefs":81,"style":86},"87f5cd77ee14","block",[67,72,77],{"_key":68,"_type":69,"marks":70,"text":71},"87f5cd77ee140","span",[],"When ",{"_key":73,"_type":69,"marks":74,"text":76},"87f5cd77ee141",[75],"5e648109e692","Flipp",{"_key":78,"_type":69,"marks":79,"text":80},"87f5cd77ee142",[],", my employer, first started as a scrappy, small team, we had only a handful of systems. Every dev had the context they needed to work with those systems and the skills to do so (we were honestly lucky to have the right skillsets in the team). The same couple of people handled the software development, deployment, and troubleshooting.",[82],{"_key":75,"_type":83,"href":84,"reference":85},"link","https:\u002F\u002Fcorp.flipp.com",null,"normal",{"_key":88,"_type":65,"children":89,"markDefs":111,"style":86},"30bcc85e85e2",[90,94,99,103,107],{"_key":91,"_type":69,"marks":92,"text":93},"30bcc85e85e20",[],"As we grew, the number of things we handled grew with us. We could no longer have one or two really smart people handle everything. We started splitting up into a \"development\" team and an \"infrastructure\" team (aka ",{"_key":95,"_type":69,"marks":96,"text":98},"30bcc85e85e21",[97],"em","infra",{"_key":100,"_type":69,"marks":101,"text":102},"30bcc85e85e22",[],") to handle what many people call ",{"_key":104,"_type":69,"marks":105,"text":106},"30bcc85e85e23",[97],"operations",{"_key":108,"_type":69,"marks":109,"text":110},"30bcc85e85e24",[],".",[],{"_key":113,"_type":65,"children":114,"markDefs":119,"style":86},"a3280a0e023d",[115],{"_key":116,"_type":69,"marks":117,"text":118},"a3280a0e023d0",[],"By \"operations,\" I mean tasks involving the actual production infrastructure. Typically this includes the following:",[],{"_key":121,"_type":65,"children":122,"level":127,"listItem":128,"markDefs":129,"style":86},"3cc919922bc5",[123],{"_key":124,"_type":69,"marks":125,"text":126},"3cc919922bc50",[],"Provisioning and managing servers, storage, operating systems, etc.",1,"bullet",[],{"_key":131,"_type":65,"children":132,"level":127,"listItem":128,"markDefs":137,"style":86},"9017761018dd",[133],{"_key":134,"_type":69,"marks":135,"text":136},"9017761018dd0",[],"Deploying software",[],{"_key":139,"_type":65,"children":140,"level":127,"listItem":128,"markDefs":145,"style":86},"e1fe58cc78b3",[141],{"_key":142,"_type":69,"marks":143,"text":144},"e1fe58cc78b30",[],"Monitoring, alerting, and dealing with production issues",[],{"_key":147,"_type":65,"children":148,"markDefs":153,"style":86},"da914c04945b",[149],{"_key":150,"_type":69,"marks":151,"text":152},"da914c04945b0",[],"This worked, kind of, for a time. But we quickly realized that our infrastructure team, though they knew lots about Linux and firefighting, knew less and less about the actual systems we had and what they did as those systems expanded and changed. This impacted all three operations aspects:",[],{"_key":155,"_type":65,"children":156,"level":127,"listItem":128,"markDefs":161,"style":86},"fa91819d65f0",[157],{"_key":158,"_type":69,"marks":159,"text":160},"fa91819d65f00",[],"For provisioning, infra became more of a gatekeeper and bottleneck. To ensure they understood the use cases, teams had to provide multiple-page questionnaires and have sync-up meetings for new servers. The process could take weeks.",[],{"_key":163,"_type":65,"children":164,"level":127,"listItem":128,"markDefs":169,"style":86},"ca86d55d34e2",[165],{"_key":166,"_type":69,"marks":167,"text":168},"ca86d55d34e20",[],"Deployments became rubber-stamps on code that the team had already decided to deploy. The infra team had to be \"the person to push the button\" but had no insight into what they were deploying.",[],{"_key":171,"_type":65,"children":172,"level":127,"listItem":128,"markDefs":177,"style":86},"cf23057f85d0",[173],{"_key":174,"_type":69,"marks":175,"text":176},"cf23057f85d00",[],"Production issues multiplied because infra did not understand the systems. They largely ended up just calling the team whenever anything went wrong. Because skillsets differed, the infra and application teams often had to fix problems together, leading to finger-pointing during post-mortems.",[],{"_key":179,"_type":65,"children":180,"markDefs":185,"style":86},"02b6372590b5",[181],{"_key":182,"_type":69,"marks":183,"text":184},"02b6372590b50",[],"Something had to change. And that's when we made our big decision.",[],{"_key":187,"_type":65,"children":188,"markDefs":193,"style":194},"3275cc66359d",[189],{"_key":190,"_type":69,"marks":191,"text":192},"3275cc66359d0",[],"One team to rule them all",[],"h2",{"_key":196,"_type":65,"children":197,"markDefs":202,"style":86},"875ad641da03",[198],{"_key":199,"_type":69,"marks":200,"text":201},"875ad641da030",[],"At this point we could have gone down two paths. We could have doubled down on communication and process, ensured that the dev and infra teams communicate more effectively, spent time writing detailed playbooks, heavily involved infra in new projects, and expanded the infra team so they were less of a bottleneck.",[],{"_key":204,"_type":65,"children":205,"markDefs":215,"style":86},"6bad7b3a9f29",[206,210],{"_key":207,"_type":69,"marks":208,"text":209},"6bad7b3a9f290",[],"Instead, we went the opposite route. We decided that",{"_key":211,"_type":69,"marks":212,"text":214},"6bad7b3a9f291",[213,97],"strong"," we need to empower our development teams to do their own operations.",[],{"_key":217,"_type":65,"children":218,"markDefs":223,"style":224},"5c5782ab1066",[219],{"_key":220,"_type":69,"marks":221,"text":222},"5c5782ab10660",[],"Why?",[],"h3",{"_key":226,"_type":65,"children":227,"level":127,"listItem":128,"markDefs":240,"style":86},"9a416794cbe0",[228,232,236],{"_key":229,"_type":69,"marks":230,"text":231},"9a416794cbe00",[],"Keep the expertise for a given system ",{"_key":233,"_type":69,"marks":234,"text":235},"9a416794cbe01",[213],"within the team",{"_key":237,"_type":69,"marks":238,"text":239},"9a416794cbe02",[],". We can have \"specialists\" on a team who are \"better\" at infrastructure-y things, but only with the goal of spreading that knowledge out to the team at large.",[],{"_key":242,"_type":65,"children":243,"level":127,"listItem":128,"markDefs":256,"style":86},"ca6a7ed84285",[244,248,252],{"_key":245,"_type":69,"marks":246,"text":247},"ca6a7ed842850",[],"Ensure that devs have ",{"_key":249,"_type":69,"marks":250,"text":251},"ca6a7ed842851",[213],"production experience",{"_key":253,"_type":69,"marks":254,"text":255},"ca6a7ed842852",[]," when building systems. Without it, they simply don't know enough about how to build the system in the first place.",[],{"_key":258,"_type":65,"children":259,"level":127,"listItem":128,"markDefs":268,"style":86},"321e8ea9a582",[260,264],{"_key":261,"_type":69,"marks":262,"text":263},"321e8ea9a5820",[213],"Lower roadblocks",{"_key":265,"_type":69,"marks":266,"text":267},"321e8ea9a5821",[]," to making changes or adding features to a system. If you don't have an operations \"gateway,\" you're empowered to make your own changes on your own timelines.",[],{"_key":270,"_type":65,"children":271,"level":127,"listItem":128,"markDefs":279,"style":86},"7e3038520b73",[272,275],{"_key":273,"_type":69,"marks":274,"text":263},"7e3038520b730",[213],{"_key":276,"_type":69,"marks":277,"text":278},"7e3038520b731",[]," to creating new systems. This ensures we can move fast when building new functionality.",[],{"_key":281,"_type":65,"children":282,"level":127,"listItem":128,"markDefs":291,"style":86},"c0390449d47a",[283,287],{"_key":284,"_type":69,"marks":285,"text":286},"c0390449d47a0",[213],"Eliminate finger-pointing",{"_key":288,"_type":69,"marks":289,"text":290},"c0390449d47a1",[],". Because the system is owned by a single team, there is only one point of accountability and there is no opportunity to accuse other teams of causing problems.",[],{"_key":293,"_type":65,"children":294,"level":127,"listItem":128,"markDefs":311,"style":86},"5a9cb727abea",[295,299,303,307],{"_key":296,"_type":69,"marks":297,"text":298},"5a9cb727abea0",[213],"Motivate the team to fix problems.",{"_key":300,"_type":69,"marks":301,"text":302},"5a9cb727abea1",[]," Give the motivation to actually fix problems to the people who know how to fix them. If the team is getting woken up at night by alerts, it's ",{"_key":304,"_type":69,"marks":305,"text":306},"5a9cb727abea2",[213],"on them",{"_key":308,"_type":69,"marks":309,"text":310},"5a9cb727abea3",[]," to put in improvements to either the system or the alerts, to reduce the amount of times wakeups happen.",[],{"_key":313,"_type":65,"children":314,"markDefs":319,"style":224},"7ee6f0109f21",[315],{"_key":316,"_type":69,"marks":317,"text":318},"7ee6f0109f210",[],"How did we do it?",[],{"_key":321,"_type":65,"children":322,"markDefs":343,"style":86},"0f0fbeeff88a",[323,327,331,335,339],{"_key":324,"_type":69,"marks":325,"text":326},"0f0fbeeff88a0",[],"The major key to this was changing the role and goals of the infrastructure team. We rebranded it as ",{"_key":328,"_type":69,"marks":329,"text":330},"0f0fbeeff88a1",[97],"Engineering Capabilities (Eng Cap)",{"_key":332,"_type":69,"marks":333,"text":334},"0f0fbeeff88a2",[],", and their goal was to actually ",{"_key":336,"_type":69,"marks":337,"text":338},"0f0fbeeff88a3",[97],"build tools",{"_key":340,"_type":69,"marks":341,"text":342},"0f0fbeeff88a4",[]," to enable teams to do the sorts of things that the infrastructure team used to be responsible for. This way, as time goes on, the Eng Cap team becomes less and less responsible for manual work and transitions towards yet another development team with their own systems.",[],{"_key":345,"_type":53,"alt":85,"asset":346,"caption":348,"markDefs":85},"3fbdc22ed2ec",{"_ref":347,"_type":56},"image-26462b63d7d5b6edc115ae6f2f94d86774b720bd-445x249-jpg","Back of the envelope style!",{"_key":350,"_type":65,"children":351,"markDefs":356,"style":86},"50ca16c5a5e0",[352],{"_key":353,"_type":69,"marks":354,"text":355},"50ca16c5a5e00",[],"Key aspects of our plan included:",[],{"_key":358,"_type":65,"children":359,"level":127,"listItem":128,"markDefs":368,"style":86},"4ddd699b0a6e",[360,364],{"_key":361,"_type":69,"marks":362,"text":363},"4ddd699b0a6e0",[213],"Build a systems platform:",{"_key":365,"_type":69,"marks":366,"text":367},"4ddd699b0a6e1",[]," This dovetailed nicely with our goal to move towards a microservices architecture. We invested years of work into building a scalable platform using containers and load balancers so that creating a new system could be done with a click of a button. This took all the \"smarts\" out of what infrastructure did and put it in a system so teams could be confident that the template they chose would work for their use case.",[],{"_key":370,"_type":65,"children":371,"level":127,"listItem":128,"markDefs":380,"style":86},"4fa4af262440",[372,376],{"_key":373,"_type":69,"marks":374,"text":375},"4fa4af2624400",[213],"Use the cloud:",{"_key":377,"_type":69,"marks":378,"text":379},"4fa4af2624401",[]," Cloud services helped immensely and took many of the tasks we would do on our own (such as managing instances and databases) and handled them externally. We could focus on what our company was good at—our content and features—and leave the infrastructure and systems know-how to the companies that are built around that.",[],{"_key":382,"_type":65,"children":383,"level":127,"listItem":128,"markDefs":392,"style":86},"4405dbb7a7d4",[384,388],{"_key":385,"_type":69,"marks":386,"text":387},"4405dbb7a7d40",[213],"Spread the knowledge: ",{"_key":389,"_type":69,"marks":390,"text":391},"4405dbb7a7d41",[],"Rather than keeping all the systems knowledge in one team, we slowly spread it out to the teams that need it. In some cases we would \"plant\" someone strong in systems skills into a team, then ensure they shared their knowledge with everyone else, both through training and playbooks.",[],{"_key":394,"_type":65,"children":395,"level":127,"listItem":128,"markDefs":429,"style":86},"2eb4173ad0cd",[396,400,405,409,413,417,421,425],{"_key":397,"_type":69,"marks":398,"text":399},"2eb4173ad0cd0",[213],"Embrace ",{"_key":401,"_type":69,"marks":402,"text":404},"2eb4173ad0cd1",[403,213],"2e43619c3946","continuous deployment",{"_key":406,"_type":69,"marks":407,"text":408},"2eb4173ad0cd2",[213],":",{"_key":410,"_type":69,"marks":411,"text":412},"2eb4173ad0cd3",[]," Having a continuous integration tool do the deployments helped reduce fear of deploys and gave more autonomy to the teams. We embraced the idea that the ",{"_key":414,"_type":69,"marks":415,"text":416},"2eb4173ad0cd4",[213],"merge button",{"_key":418,"_type":69,"marks":419,"text":420},"2eb4173ad0cd5",[]," replaced the ",{"_key":422,"_type":69,"marks":423,"text":424},"2eb4173ad0cd6",[213],"deploy button",{"_key":426,"_type":69,"marks":427,"text":428},"2eb4173ad0cd7",[],". Whoever merges the code to the main branch implicitly approves that code to go live immediately.",[430],{"_key":403,"_type":83,"href":431,"reference":85},"https:\u002F\u002Fstackoverflow.blog\u002F2021\u002F01\u002F19\u002Ffulfilling-the-promise-of-ci-cd\u002F",{"_key":433,"_type":65,"children":434,"level":127,"listItem":128,"markDefs":443,"style":86},"5160a1966fbc",[435,439],{"_key":436,"_type":69,"marks":437,"text":438},"5160a1966fbc0",[213],"Widespread monitoring and alerting:",{"_key":440,"_type":69,"marks":441,"text":442},"5160a1966fbc1",[]," We embraced a cloud provider for both monitoring (metrics, downtime, latency, etc.) and alerting (on-call schedules, alerts, communication) and gave all teams access to it. This put the accountability for system uptime on the team themselves—and allowed them to manage their own schedules and decide what is and isn't considered an \"alert.\"",[],{"_key":445,"_type":65,"children":446,"level":127,"listItem":128,"markDefs":455,"style":86},"4688ce7138d6",[447,451],{"_key":448,"_type":69,"marks":449,"text":450},"4688ce7138d60",[213],"Fix alerts:",{"_key":452,"_type":69,"marks":453,"text":454},"4688ce7138d61",[]," Teams were encouraged to set up a process around reviewing and improving alerts, making sure that the alerts themselves were actionable (not noisy and hence ignored) and that they put time towards reducing those alerts as time went on. We ensured that our product team was on board with having this as a team goal, especially for teams that managed legacy systems that had poor alert hygiene.",[],{"_key":457,"_type":65,"children":458,"markDefs":463,"style":86},"8d8b06a79909",[459],{"_key":460,"_type":69,"marks":461,"text":462},"8d8b06a799090",[],"Note that Eng Cap was still available as \"subject matter experts'' for infrastructure. This means that they could always provide their expertise when planning new systems, and they made themselves available as \"level two\" on-call in case more expert help was needed in an emergency. But we switched the responsibility—now teams have to call Eng Cap rather than the other way around, and it doesn't happen often.",[],{"_key":465,"_type":65,"children":466,"markDefs":471,"style":194},"1aef46f33c38",[467],{"_key":468,"_type":69,"marks":469,"text":470},"1aef46f33c380",[],"Roadblocks and protests",[],{"_key":473,"_type":65,"children":474,"markDefs":479,"style":86},"301ed5bdb73e",[475],{"_key":476,"_type":69,"marks":477,"text":478},"301ed5bdb73e0",[],"Like any large change, even a long-term one, there's no silver bullet. When you're dealing with dozens of devs and engineering managers used to the \"old way,\" we had to understand the resistance to our plans, and either make improvements or explain and educate where needed.",[],{"_key":481,"_type":65,"children":482,"markDefs":487,"style":224},"f88b47a55d20",[483],{"_key":484,"_type":69,"marks":485,"text":486},"f88b47a55d200",[213],"Security and Controls:",[],{"_key":489,"_type":65,"children":490,"level":127,"listItem":128,"markDefs":495,"style":86},"cde64caf52a1",[491],{"_key":492,"_type":69,"marks":493,"text":494},"cde64caf52a10",[],"Q: If there is no separate team pressing the \"deploy button\", doesn't that violate segregation of duties and present issues with audits?",[],{"_key":497,"_type":65,"children":498,"level":127,"listItem":128,"markDefs":512,"style":86},"695c5fbf032c",[499,503,508],{"_key":500,"_type":69,"marks":501,"text":502},"695c5fbf032c0",[],"A: ",{"_key":504,"_type":69,"marks":505,"text":507},"695c5fbf032c1",[506],"46ceae81383e","Not really.",{"_key":509,"_type":69,"marks":510,"text":511},"695c5fbf032c2",[]," Especially since those pressing the \"deploy button\" don't have context into what they're allowing, all it does is add needless slowdown. A continuous deployment process has full auditability (just check the git log) and should satisfy any reasonable audit.",[513],{"_key":506,"_type":83,"href":514,"reference":85},"https:\u002F\u002Fdevops.com\u002Fdevops-getting-past-audit\u002F",{"_key":516,"_type":65,"children":517,"markDefs":522,"style":224},"e7b8bc16422b",[518],{"_key":519,"_type":69,"marks":520,"text":521},"e7b8bc16422b0",[213],"Developer Happiness:",[],{"_key":524,"_type":65,"children":525,"level":127,"listItem":128,"markDefs":530,"style":86},"77deec6b6fe4",[526],{"_key":527,"_type":69,"marks":528,"text":529},"77deec6b6fe40",[],"Q: Devs don't want to wake up in the middle of the night. Won't moving this responsibility from a single team to all teams mean devs will be more miserable and increase turnover?",[],{"_key":532,"_type":65,"children":533,"level":127,"listItem":128,"markDefs":546,"style":86},"f0c8446e774a",[534,538,542],{"_key":535,"_type":69,"marks":536,"text":537},"f0c8446e774a0",[],"A: By moving the pain into the dev teams, we are giving them the motivation to actually fix the problems. This may cause some short-term complaints, but because they are given more autonomy, in the long-term they have a higher satisfaction with their work. However, it is ",{"_key":539,"_type":69,"marks":540,"text":541},"f0c8446e774a1",[97],"crucial",{"_key":543,"_type":69,"marks":544,"text":545},"f0c8446e774a2",[]," to make sure our product roadmap gives time and effort into fixing them. Without that, this step would likely cause a lot of resentment.",[],{"_key":548,"_type":65,"children":549,"markDefs":554,"style":224},"83ebf018b526",[550],{"_key":551,"_type":69,"marks":552,"text":553},"83ebf018b5260",[213],"Skill Gap:",[],{"_key":556,"_type":65,"children":557,"level":127,"listItem":128,"markDefs":562,"style":86},"7239e004cfa3",[558],{"_key":559,"_type":69,"marks":560,"text":561},"7239e004cfa30",[],"Q: Learning how to handle servers and databases are specialized skills. If we make the application teams responsible, won't we lose those skills?",[],{"_key":564,"_type":65,"children":565,"level":127,"listItem":128,"markDefs":570,"style":86},"1e11998c03fe",[566],{"_key":567,"_type":69,"marks":568,"text":569},"1e11998c03fe0",[],"A: Teaching teams how to handle specific technologies is actually much easier than trying to teach an infrastructure team how every single system works. Spreading the knowledge out slowly, with good documentation, is much more scalable.",[],{"_key":572,"_type":65,"children":573,"markDefs":578,"style":194},"197414487903",[574],{"_key":575,"_type":69,"marks":576,"text":577},"1974144879030",[],"Where are we now?",[],{"_key":580,"_type":65,"children":581,"markDefs":586,"style":86},"c632b0696606",[582],{"_key":583,"_type":69,"marks":584,"text":585},"c632b06966060",[],"This was a five-year process, and we're still learning and improving, especially for our legacy systems, a few of which are still on our old platform. But for the most part, the following statements are now true:",[],{"_key":588,"_type":65,"children":589,"level":127,"listItem":128,"markDefs":594,"style":86},"5c442da76a15",[590],{"_key":591,"_type":69,"marks":592,"text":593},"5c442da76a150",[],"Teams are now empowered and knowledgeable about their systems, how they behave in production, how to know when there is a problem, and how to fix those problems.",[],{"_key":596,"_type":65,"children":597,"level":127,"listItem":128,"markDefs":602,"style":86},"4a243df11963",[598],{"_key":599,"_type":69,"marks":600,"text":601},"4a243df119630",[],"They are motivated to build their own playbooks to spread the knowledge, so that new team members can share the load of being on call.",[],{"_key":604,"_type":65,"children":605,"level":127,"listItem":128,"markDefs":610,"style":86},"73ff4e3a957c",[606],{"_key":607,"_type":69,"marks":608,"text":609},"73ff4e3a957c0",[],"They are motivated to make their alerts \"smart\" and actionable, so that they know when systems have problems and can remove noisy alerts.",[],{"_key":612,"_type":65,"children":613,"level":127,"listItem":128,"markDefs":618,"style":86},"58dceb8b29f2",[614],{"_key":615,"_type":69,"marks":616,"text":617},"58dceb8b29f20",[],"They are motivated and empowered to fix things that cause alerts by building it into their product roadmap.",[],{"_key":620,"_type":65,"children":621,"level":127,"listItem":128,"markDefs":626,"style":86},"fc9c8ea876da",[622],{"_key":623,"_type":69,"marks":624,"text":625},"fc9c8ea876da0",[],"Often, the number of alerts, time to fix, validity, etc. are part of sprint metrics and reports.",[],{"_key":628,"_type":65,"children":629,"level":127,"listItem":128,"markDefs":634,"style":86},"e6f0b31d16d4",[630],{"_key":631,"_type":69,"marks":632,"text":633},"e6f0b31d16d40",[],"Alerts and emergencies are generally trending downwards and are not part of everyday life, even for legacy systems. As a whole, when an alert happens, it's nearly always something new that the team hasn't seen before.",[],{"_key":636,"_type":65,"children":637,"markDefs":642,"style":194},"b24684687b22",[638],{"_key":639,"_type":69,"marks":640,"text":641},"b24684687b220",[],"Conclusion",[],{"_key":644,"_type":65,"children":645,"markDefs":650,"style":86},"afbb2a442d9a",[646],{"_key":647,"_type":69,"marks":648,"text":649},"afbb2a442d9a0",[],"Empowering your teams to do their own operations can pay big dividends down the road. Your company needs to be in the right place and be willing to make the right investments to enable it. But as a decision, it's one that I'd urge any company to continually revisit until they're ready to make the plunge.",[],{"_key":652,"_type":65,"children":653,"markDefs":658,"style":86},"f5f3dcec51bd",[654],{"_key":655,"_type":69,"marks":656,"text":657},"f5f3dcec51bd0",[],"---",[],{"_key":660,"_type":65,"children":661,"markDefs":675,"style":86},"3454d775342f",[662,666,671],{"_key":663,"_type":69,"marks":664,"text":665},"3454d775342f0",[],"You can visit my ",{"_key":667,"_type":69,"marks":668,"text":670},"3454d775342f1",[669],"1a2dcd54e280","GitHub profile page",{"_key":672,"_type":69,"marks":673,"text":674},"3454d775342f2",[]," for more articles!",[676],{"_key":669,"_type":83,"href":677,"reference":85},"https:\u002F\u002Fgithub.com\u002Fdorner","2021\u002F05\u002F24","Many companies run parallel development and operations organizations. But what if you just ran one team that did both?",{"_type":53,"asset":681},{"_ref":682,"_type":56},"image-146fced0e4f8589a7256ca72a4b2247456283b6f-2400x1260-jpg",{"code":684,"language":685},"\u003C!-- wp:paragraph -->\n\u003Cp>When \u003Ca href=\"https:\u002F\u002Fcorp.flipp.com\">Flipp\u003C\u002Fa>, my employer, first started as a scrappy, small team, we had only a handful of systems. Every dev had the context they needed to work with those systems and the skills to do so (we were honestly lucky to have the right skillsets in the team). The same couple of people handled the software development, deployment, and troubleshooting.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>As we grew, the number of things we handled grew with us. We could no longer have one or two really smart people handle everything. We started splitting up into a \"development\" team and an \"infrastructure\" team (aka \u003Cem>infra\u003C\u002Fem>) to handle what many people call \u003Cem>operations\u003C\u002Fem>.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>By \"operations,\" I mean tasks involving the actual production infrastructure. Typically this includes the following:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>\u003Cspan style=\"color:#0aa46b\" class=\"has-inline-color\">Provisioning and managing \u003C\u002Fspan>servers, storage, operating systems, etc.\u003C\u002Fli>\u003Cli>\u003Cspan class=\"has-inline-color has-vivid-cyan-blue-color\">Deploying \u003C\u002Fspan>software\u003C\u002Fli>\u003Cli>Monitoring, alerting, and dealing with \u003Cspan class=\"has-inline-color has-vivid-red-color\">production issues\u003C\u002Fspan>\u003C\u002Fli>\u003C\u002Ful>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>This worked, kind of, for a time. But we quickly realized that our infrastructure team, though they knew lots about Linux and firefighting, knew less and less about the actual systems we had and what they did as those systems expanded and changed. This impacted all three operations aspects:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>For \u003Cspan style=\"color:#0aa46b\" class=\"has-inline-color\">provisioning\u003C\u002Fspan>, infra became more of a gatekeeper and bottleneck. To ensure they understood the use cases, teams had to provide multiple-page questionnaires and have sync-up meetings for new servers. The process could take weeks. \u003C\u002Fli>\u003Cli>\u003Cspan class=\"has-inline-color has-vivid-cyan-blue-color\">Deployments \u003C\u002Fspan>became rubber-stamps on code that the team had already decided to deploy. The infra team had to be \"the person to push the button\" but had no insight into what they were deploying.\u003C\u002Fli>\u003Cli>\u003Cspan class=\"has-inline-color has-vivid-red-color\">Production issues\u003C\u002Fspan> multiplied because infra did not understand the systems. They largely ended up just calling the team whenever anything went wrong. Because skillsets differed, the infra and application teams often had to fix problems together, leading to finger-pointing during post-mortems.\u003C\u002Fli>\u003C\u002Ful>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Something had to change. And that's when we made our big decision.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-one-team-to-rule-them-all\">One team to rule them all\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>At this point we could have gone down two paths. We could have doubled down on communication and process, ensured that the dev and infra teams communicate more effectively, spent time writing detailed playbooks, heavily involved infra in new projects, and expanded the infra team so they were less of a bottleneck.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Instead, we went the opposite route. We decided that\u003Cstrong>\u003Cem> we need to empower our development teams to do their own operations.\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-why\">Why?\u003C\u002Fh3>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>Keep the expertise for a given system \u003Cstrong>within the team\u003C\u002Fstrong>. We can have \"specialists\" on a team who are \"better\" at infrastructure-y things, but only with the goal of spreading that knowledge out to the team at large.\u003C\u002Fli>\u003Cli>Ensure that devs have \u003Cstrong>production experience\u003C\u002Fstrong> when building systems. Without it, they simply don't know enough about how to build the system in the first place.\u003C\u002Fli>\u003Cli>\u003Cstrong>\u003Cspan class=\"has-inline-color has-vivid-cyan-blue-color\">Lower roadblocks\u003C\u002Fspan>\u003C\u002Fstrong> to making changes or adding features to a system. If you don't have an operations \"gateway,\" you're empowered to make your own changes on your own timelines.\u003C\u002Fli>\u003Cli>\u003Cstrong>\u003Cspan style=\"color:#0aa46b\" class=\"has-inline-color\">Lower roadblocks\u003C\u002Fspan>\u003C\u002Fstrong> to creating new systems. This ensures we can move fast when building new functionality.\u003C\u002Fli>\u003Cli>\u003Cstrong>\u003Cspan class=\"has-inline-color has-vivid-red-color\">Eliminate finger-pointing\u003C\u002Fspan>\u003C\u002Fstrong>. Because the system is owned by a single team, there is only one point of accountability and there is no opportunity to accuse other teams of causing problems.\u003C\u002Fli>\u003Cli>\u003Cspan class=\"has-inline-color has-vivid-red-color\">\u003Cstrong>Motivate the team to fix problems.\u003C\u002Fstrong> \u003C\u002Fspan>Give the motivation to actually fix problems to the people who know how to fix them. If the team is getting woken up at night by alerts, it's \u003Cstrong>on them\u003C\u002Fstrong> to put in improvements to either the system or the alerts, to reduce the amount of times wakeups happen.\u003C\u002Fli>\u003C\u002Ful>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-how-did-we-do-it\">How did we do it?\u003C\u002Fh3>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The major key to this was changing the role and goals of the infrastructure team. We rebranded it as \u003Cem>Engineering Capabilities (Eng Cap)\u003C\u002Fem>, and their goal was to actually \u003Cem>build tools\u003C\u002Fem> to enable teams to do the sorts of things that the infrastructure team used to be responsible for. This way, as time goes on, the Eng Cap team becomes less and less responsible for manual work and transitions towards yet another development team with their own systems.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:image {\"id\":18120,\"sizeSlug\":\"large\",\"linkDestination\":\"none\"} -->\n\u003Cfigure class=\"wp-block-image size-large\">\u003Cimg src=\"https:\u002F\u002Fstackoverflow.blog\u002Fwp-content\u002Fuploads\u002F2021\u002F05\u002Fgraph.jpeg\" alt=\"\" class=\"wp-image-18120\"\u002F>\u003Cfigcaption>Back of the envelope style!\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003C!-- \u002Fwp:image -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Key aspects of our plan included:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>\u003Cstrong>Build a systems platform:\u003C\u002Fstrong> This dovetailed nicely with our goal to move towards a microservices architecture. We invested years of work into building a scalable platform using containers and load balancers so that creating a new system could be done with a click of a button. This took all the \"smarts\" out of what infrastructure did and put it in a system so teams could be confident that the template they chose would work for their use case.\u003C\u002Fli>\u003Cli>\u003Cstrong>Use the cloud:\u003C\u002Fstrong> Cloud services helped immensely and took many of the tasks we would do on our own (such as managing instances and databases) and handled them externally. We could focus on what our company was good at—our content and features—and leave the infrastructure and systems know-how to the companies that are built around that.\u003C\u002Fli>\u003Cli>\u003Cstrong>Spread the knowledge: \u003C\u002Fstrong>Rather than keeping all the systems knowledge in one team, we slowly spread it out to the teams that need it. In some cases we would \"plant\" someone strong in systems skills into a team, then ensure they shared their knowledge with everyone else, both through training and playbooks.\u003C\u002Fli>\u003Cli>\u003Cstrong>Embrace \u003C\u002Fstrong>\u003Ca href=\"https:\u002F\u002Fstackoverflow.blog\u002F2021\u002F01\u002F19\u002Ffulfilling-the-promise-of-ci-cd\u002F\">\u003Cstrong>continuous deployment\u003C\u002Fstrong>\u003C\u002Fa>\u003Cstrong>:\u003C\u002Fstrong> Having a continuous integration tool do the deployments helped reduce fear of deploys and gave more autonomy to the teams. We embraced the idea that the \u003Cstrong>merge button\u003C\u002Fstrong> replaced the \u003Cstrong>deploy button\u003C\u002Fstrong>. Whoever merges the code to the main branch implicitly approves that code to go live immediately.\u003C\u002Fli>\u003Cli>\u003Cstrong>Widespread monitoring and alerting:\u003C\u002Fstrong> We embraced a cloud provider for both monitoring (metrics, downtime, latency, etc.) and alerting (on-call schedules, alerts, communication) and gave all teams access to it. This put the accountability for system uptime on the team themselves—and allowed them to manage their own schedules and decide what is and isn't considered an \"alert.\"\u003C\u002Fli>\u003Cli>\u003Cstrong>Fix alerts:\u003C\u002Fstrong> Teams were encouraged to set up a process around reviewing and improving alerts, making sure that the alerts themselves were actionable (not noisy and hence ignored) and that they put time towards reducing those alerts as time went on. We ensured that our product team was on board with having this as a team goal, especially for teams that managed legacy systems that had poor alert hygiene.\u003C\u002Fli>\u003C\u002Ful>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Note that Eng Cap was still available as \"subject matter experts'' for infrastructure. This means that they could always provide their expertise when planning new systems, and they made themselves available as \"level two\" on-call in case more expert help was needed in an emergency. But we switched the responsibility—now teams have to call Eng Cap rather than the other way around, and it doesn't happen often.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:block {\"ref\":17976} \u002F-->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-roadblocks-and-protests\">Roadblocks and protests\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Like any large change, even a long-term one, there's no silver bullet. When you're dealing with dozens of devs and engineering managers used to the \"old way,\" we had to understand the resistance to our plans, and either make improvements or explain and educate where needed.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-security-and-controls\">\u003Cstrong>Security and Controls:\u003C\u002Fstrong> \u003C\u002Fh3>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>Q: If there is no separate team pressing the \"deploy button\", doesn't that violate segregation of duties and present issues with audits? \u003C\u002Fli>\u003Cli>A: \u003Ca href=\"https:\u002F\u002Fdevops.com\u002Fdevops-getting-past-audit\u002F\">Not really.\u003C\u002Fa> Especially since those pressing the \"deploy button\" don't have context into what they're allowing, all it does is add needless slowdown. A continuous deployment process has full auditability (just check the git log) and should satisfy any reasonable audit.\u003C\u002Fli>\u003C\u002Ful>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-developer-happiness\">\u003Cstrong>Developer Happiness:\u003C\u002Fstrong> \u003C\u002Fh3>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>Q: Devs don't want to wake up in the middle of the night. Won't moving this responsibility from a single team to all teams mean devs will be more miserable and increase turnover?\u003C\u002Fli>\u003Cli>A: By moving the pain into the dev teams, we are giving them the motivation to actually fix the problems. This may cause some short-term complaints, but because they are given more autonomy, in the long-term they have a higher satisfaction with their work. However, it is \u003Cem>crucial\u003C\u002Fem> to make sure our product roadmap gives time and effort into fixing them. Without that, this step would likely cause a lot of resentment.\u003C\u002Fli>\u003C\u002Ful>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3 id=\"h-skill-gap\">\u003Cstrong>Skill Gap:\u003C\u002Fstrong>\u003C\u002Fh3>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>Q: Learning how to handle servers and databases are specialized skills. If we make the application teams responsible, won't we lose those skills?\u003C\u002Fli>\u003Cli>A: Teaching teams how to handle specific technologies is actually much easier than trying to teach an infrastructure team how every single system works. Spreading the knowledge out slowly, with good documentation, is much more scalable.\u003C\u002Fli>\u003C\u002Ful>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-where-are-we-now\">Where are we now?\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>This was a five-year process, and we're still learning and improving, especially for our legacy systems, a few of which are still on our old platform. But for the most part, the following statements are now true:\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>Teams are now empowered and knowledgeable about their systems, how they behave in production, how to know when there is a problem, and how to fix those problems.\u003C\u002Fli>\u003Cli>They are motivated to build their own playbooks to spread the knowledge, so that new team members can share the load of being on call.\u003C\u002Fli>\u003Cli>They are motivated to make their alerts \"smart\" and actionable, so that they know when systems have problems and can remove noisy alerts.\u003C\u002Fli>\u003Cli>They are motivated and empowered to fix things that cause alerts by building it into their product roadmap.\u003C\u002Fli>\u003Cli>Often, the number of alerts, time to fix, validity, etc. are part of sprint metrics and reports.\u003C\u002Fli>\u003Cli>Alerts and emergencies are generally trending downwards and are not part of everyday life, even for legacy systems. As a whole, when an alert happens, it's nearly always something new that the team hasn't seen before.\u003C\u002Fli>\u003C\u002Ful>\n\u003C!-- \u002Fwp:list -->\n\n\u003C!-- wp:heading -->\n\u003Ch2 id=\"h-conclusion\">Conclusion\u003C\u002Fh2>\n\u003C!-- \u002Fwp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Empowering your teams to do their own operations can pay big dividends down the road. Your company needs to be in the right place and be willing to make the right investments to enable it. But as a decision, it's one that I'd urge any company to continually revisit until they're ready to make the plunge.\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>---\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>You can visit my \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fdorner\">GitHub profile page\u003C\u002Fa> for more articles!\u003C\u002Fp>\n\u003C!-- \u002Fwp:paragraph -->","html","2021-05-24T14:08:23.000Z",{"current":688},"how-developers-can-be-their-own-operations-department",[690,698,702,707],{"_createdAt":691,"_id":692,"_rev":693,"_type":694,"_updatedAt":691,"slug":695,"title":697},"2023-05-23T16:43:21Z","wp-tagcat-code-for-a-living","9HpbCsT2tq0xwozQfkc4ih","blogTag",{"current":696},"code-for-a-living","Code for a Living",{"_createdAt":691,"_id":699,"_rev":693,"_type":694,"_updatedAt":691,"slug":700,"title":404},"wp-tagcat-continuous-deployment",{"current":701},"continuous-deployment",{"_createdAt":691,"_id":703,"_rev":693,"_type":694,"_updatedAt":691,"slug":704,"title":706},"wp-tagcat-continuous-integration",{"current":705},"continuous-integration","continuous integration",{"_createdAt":691,"_id":708,"_rev":693,"_type":694,"_updatedAt":691,"slug":709,"title":710},"wp-tagcat-devops",{"current":710},"devops","How developers can be their own operations department",[713,719,725,731],{"_id":714,"publishedAt":715,"slug":716,"sponsored":85,"title":718},"76c9771b-34e6-4d98-8641-ecefc711f0ef","2026-07-06T15:23:34.559Z",{"_type":10,"current":717},"when-the-sensor-starts-thinking-snortml-agentic-ai-and-the-evolving-architecture-of-intrusion-detection","When the sensor starts thinking: SnortML, agentic AI, and the evolving architecture of intrusion detection",{"_id":720,"publishedAt":721,"slug":722,"sponsored":85,"title":724},"28e560af-f0aa-4d46-bd90-f435ad604aa7","2026-06-26T14:00:27.102Z",{"_type":10,"current":723},"paging-charity-how-can-engineering-leaders-avoid-becoming-bond-villains","Paging Charity! How can engineering leaders avoid becoming Bond villains?",{"_id":726,"publishedAt":727,"slug":728,"sponsored":85,"title":730},"4b22c2a3-3779-4966-93eb-5230391dbdce","2026-06-23T14:08:58.595Z",{"_type":10,"current":729},"your-ai-shipped-a-backend-that-boots-that-is-the-whole-problem","Your AI shipped a backend that boots. That is the whole problem.",{"_id":732,"publishedAt":733,"slug":734,"sponsored":85,"title":736},"5cf362e1-fe7b-45af-b69c-914731c6a052","2026-06-23T14:00:00.000Z",{"_type":10,"current":735},"the-2026-developer-survey-is-now-open-for-human-developers-only","The 2026 Developer Survey is now open (for human developers only)!",{"data":738,"sourceMap":-1},{"count":739,"lastTimestamp":740},11,"2023-05-25T09:47:33Z"]