This message was deleted.

Hey, I went through the two scenarios you mentioned. However, please note it happened in the context of one customer engagement and might provide limited context. Building SRE capability from the ground up The relatively small engineering team built and instantiated the platform, and eventually we moved them to the next customer engagement. Initially we tried to hand over this to the existing IT ops team, however, it didn’t go well. In result, I had to hire and train people to operate and continuously improve the platform. It was difficult and time consuming activity, but eventually we got the the point it was efficient and self-organising. It involved large number of knowledge sharing activities, fire drills, travels, etc. The most important aspect is to make this decision at the relatively early stage of development. You need to invest more into runbooks, developer guides, establishing processes around monitoring, release management, disaster recovery, etc. Promoting SRE internally This happens organically, as some people naturally gravitate towards this kind of work (it’s always good to do this kind of assessment in the existing team). However, not everyone on the team is interested/capable of doing this (they’d rather focus on engineering work more). It’s understandable because it requires different mindset. I think it’s not fully possible, you will have to hire someone anyway to fill the gap. Esp. someone who will be managing this team, establish measurements (SLA, SLO, etc.). The biggest advantage in this scenario is that, people already know how to navigate and can distribute the knowledge in a more effective way by doing pair programming, etc. To summarise, I’d start internally and eventually fill gaps over time by external hiring.