Yesterday, iO’s Theo Borek hosted a DevOps Leaders Breakfast Briefing on 'Growth & Self-Service'. Read his summary below:

Today I hosted the next in our series of DevOps Leaders Breakfast Briefings, focusing around the growth and self-service of DevOps teams. We had an excellent and diverse group of DevOps Leaders for the session; Bogdan Grigorescu, Gurumoorthy Raghupathy, Isaac Perez Moncho, Liam Gulliver, Oliver Whiteman, Simon White, Tim Isted and Tr Thambi who used their wealth of experience to create an open discussion. A great number of brilliant ideas were bounced around, unfortunately I am unable to summarise all of them here, so have endeavoured to summarise a few of the key points.

We started by discussing how our leaders look to grow their DevOps teams and the challenges associated with this. Gurumoorthy mentioned early on that he isn’t keen on referring to their teams as ‘DevOps teams’ and that the teams should be business or product aligned, with DevOps as something of a necessary evil when it comes to delivery of product and services – this perspective was agreeable across the group. Bogdan listed coaching as one of the most important things when building and developing DevOps teams, having worked with many brilliant engineers who struggle to take initiative and make decisions on their own, suggesting that for the teams to grow well, they have to be coached to be involved in decision making.  

There was quite a bit of discussion on the value of defining what DevOps really is. Bogdan volunteered a fascinating perspective, that all great minds in mankind’s history were ‘DevOps Engineers’, such as Marie Curie and Michelangelo because they knew the tools, picked up the tools and used them well to devise new processes and approaches – for example Michelangelo using scaffolding to paint Sistine Chapel ceiling. 

It seemed common among the group for the title ‘DevOps Engineers’ to not be used, with Liam suggesting that DevOps shouldn’t exist as its own unit because it can often become a dumping ground for all errors and anything that development teams don’t want to do and basically ends up getting treated like a help desk. Both Simon and Liam mentioned that they typically had Cloud Engineers and Site Reliability Engineers instead. 

Tr took a bit of a different view-point regarding growth of DevOps teams, saying the most important thing for him was leadership; to establish a clear goal and strategy to build business success. As all businesses differ, the approach has to be different in each case too – Tr gave examples of different approaches he took to grow DevOps teams at Sainsbury’s and Unruly. He iterated the importance of the use case and the need to hiring to fill the gaps in the existing teams, to support the business and adjust to the landscape. 

For Tr, one of the main challenges in growing teams was trying to make sure that everyone has a uniform and similar idea on DevOps – DevOps is building the entire pipeline from development onward, not just automation! Liam agreed with this challenge, as often people don’t end up on the same page in regards to what DevOps is. 

Talking about the challenges in growing teams lead to talking about the difficulty in interviewing for DevOps Engineers and all agreed that there are a lot of problems with the bias of interview processes. Isaac suggested that to build good teams, you need to hire for potential, principles and culture – which is much harder to identify than simply technical know-how with AWS for example. Bogdan also agreed that tooling is much less important than principles and solid CICD experience. Tim and Tr both mirrored this, and mentioned the difficulty of understanding candidates’ vision and style of DevOps just from interviews. 

We talked about the impact of remote working on interview processes; Tr mentioned this had led to them having to totally rethink their pair programming exercises. Bogdan brought up the point that, typically, many hiring managers aren’t trained in recruitment or understand how to write job specifications or interview properly – he thinks that businesses would benefit from coaching their managers on this, or relying more on those with more recruitment experience.  

Next, we spoke about how to ensure that wider IT teams have a DevOps culture. A unanimous point here was the importance of buy in, and – as Liam pointed out – its needed from the very top to the very bottom level of the business, not just in pockets. The topic of DevOps culture brought up the theme of psychological safety and the need for a collaborative, open environment where good communication is key. In order to have functioning DevOps teams, people need to feel comfortable speaking out and volunteering ideas and (constructive) criticisms.  

Isaac mentioned that the book ‘Team Topologies’ (https://teamtopologies.com/ ) gives great information on how to structure teams. One concept he mentioned is to tie the success of one team with the output of another team. Tr thought this could be a bit of a double-edged sword. He tried a matrix topology to build skill sets so that each person becomes recognised in the team to have a specific skillset and speciality - when someone feels they are a specialist in the team then they are engaged better.

We then moved on to talk about the challenged faced when establishing self-service models, which caused the themes of DevOps culture and psychological safety to resurface. Liam suggested that the challenges are greater in larger, more established organisations, as people become accustomed to their daily responsibilities and are uncomfortable with the idea of promoting self-service and automating some of their tasks, fearing that if they automate these tasks then they may lose value as an employee and be out of the job. It was unanimous that this isn’t the case, and that it is – typically – the less interesting tasks being self-serviced so that the teams can do more interesting work. Tr also mentioned the concerns from upper management that promoting self-service could cause problems for the business financially or from a control perspective at a business level rather than individual. Isaac suggested that businesses often think self-service will lead to a massive amount of EC2 instances, but this need not be the case. Tim explained that the key to the self-service model is consistency and routine, and that this also improves the security.

We, at iO, thoroughly enjoyed getting insights into other sectors, other organisations and perspectives. We hope everyone who attended also got something out of the breakfast briefing to aid their future strategies regarding the growth and self-service of DevOps teams. If anyone would like to get involved or has ideas on future topics we could cover, please get in touch!