Just a few years in the past, I sat in a postmortem that I nonetheless take into consideration. We’d had a manufacturing incident the place a routine deploy had quietly shipped with the mistaken configuration, and it took us longer to note and roll again than anybody was snug admitting. However after we traced the foundation trigger, virtually none of it was the characteristic code. It was the scaffolding round it: a Kubernetes manifest not matched our cluster, a CI pipeline whose inexperienced checkmark didn’t truly confirm the factor we assumed it did, and a secrets-management step that three completely different providers every did three alternative ways. The code itself had been positive for every week. The whole lot round the code is what failed us.
I’ve seen some model of that retro at practically each firm I’ve labored at over the past 15 years throughout a big IT providers agency, a medical-device maker, a healthcare-technology firm, a cloud-migration startup, and now a big SaaS platform. The names and the tech stacks modified. The sample didn’t. Good engineers spending a startling share of their week not on the issue they have been employed to unravel, however on the unintended complexity of delivery it.
For a very long time, I assumed the reply was higher documentation, or a stricter DevOps tradition, or simply hiring individuals who have been extra snug with YAML. I used to be mistaken on all three counts. What truly modified my thoughts was reframing the issue completely: the friction wasn’t a information hole or a self-discipline hole. It was a product hole. No one owned the developer’s expertise of delivery software program the way in which a product supervisor owns a buyer’s expertise of utilizing an app. And the self-discipline that closes that hole now has a reputation: platform engineering, which Gartner describes as having “emerged in response to this growing cognitive load ensuing from the complexity of recent software program instruments and architectures.” Gartner isn’t shy about how briskly it’s spreading, both: the agency predicts that “by 2026, 80% of enormous software program engineering organizations will set up platform engineering groups,” up from 45% in 2022. If that quantity is even near proper, the attention-grabbing query is not whether or not to construct a platform group however whether or not you’ll construct a great one.
