Adopting a You Build It You Run It operating model can unlock enormous business growth. It can provide greater flexibility and enhance reliability for your digital services. It can create much happier developer teams.<\/p>\n
Inevitably though\u2014like anything that offers genuine growth and value\u2014it can also come with some perceived challenges and scepticism. After all, as humans, many of us are hard-wired to resist change<\/a>.<\/p>\n Additionally, there\u2019s a sentiment from pockets of the software development community that \u2018developers don\u2019t want to do operations<\/a>\u2019, and therefore by extension, don\u2019t want to adopt You Build It You Run It.<\/p>\n Interestingly, this is a sentiment I hear from industry commentators more so than developers themselves. That said, in my experience there are<\/em> some common reservations that developers do<\/em> offer up when presented with the prospect of moving to You Build It You Run It.<\/p>\n So, here they are, with some techniques you can use to overcome them.<\/p>\n Adopting You Build It You Run It means teams will both build and support digital services.<\/p>\n When development teams suggest that a digital service is difficult to support, it\u2019s often a symptom of deeper issues.<\/p>\n The first of these issues is that the service hasn\u2019t been architected for adaptability<\/a>. So, in reality, it is<\/em> difficult to support.<\/p>\n The second is that there are no \u2018paved roads\u2019 in place. As defined in this excellent article by Equal Experts\u2019 Alan Coppack<\/a>, paved roads consist of low-friction, hardened interfaces that comprise common user journeys for Digital Service teams. Examples might include building a service, deploying a service, or service alerts. In summary, building paved roads is about removing friction from frequent processes or user journeys.<\/p>\n Without paved roads in place\u2014which abstract unnecessary complexity and cognitive load away from the team\u2019s day-to-day responsibility of focusing on a single digital service\u2014the development team has to do everything <\/em>associated with operating the service, all the time<\/em>. This means:<\/p>\n In this scenario, it\u2019s common for a team’s workload to become overwhelming because the cognitive load becomes enormous. Without correcting, teams will inevitably suffer burn out. Incidentally, you can read more about mitigating developer burn out in this article<\/a>.<\/p>\n How to overcome this challenge<\/strong><\/p>\n No prizes for guessing this one: build out the required paved roads.<\/strong><\/p>\n This allows you to abstract problems away from one development team, so they can focus more exclusively on their role in relation to a specific service.<\/p>\n Generally speaking, you can consider paved roads in relation to four broad categories:<\/p>\n Beyond removing complexity for one team, paved roads also provide valuable economies of scale. For example, when you have multiple delivery teams, these paved roads can support all of them. In that instance, you would have a dedicated platform team to solely build and run paved roads.<\/p>\n1.\u00a0\u00a0\u00a0 \u201cIt\u2019s really difficult to support the service\u201d<\/h2>\n
\n
\n