N Brown Group

Paul Cooper, Head of Service, Infrastructure & Cloud, N Brown Group

Many digital companies have already taken steps into the world of DevOps, be it with just a pilot, with platform-oriented teams, or using more scaled approaches across the technology organisation. Quite a few with significant success that you often hear about however there are just as many, if not more struggling to scale this across the wider technology organisation. Over the years I have taken a keen interest in this and what I like to call “Growing Pains” or common areas that often catch people out when trying to get the best out of a DevOps transformation.

The first and most important is the cultural change needed to scale, a pilot will help to create some of the foundations, but after that, senior leaders need to start to take a lot more ownership on the type of behaviours they want to see within their teams. A great example would be the focus on creating value and reducing wasteful tasks. Value can always be quite subjective so it needs careful consideration, but once you are clear you can set objectives, coach teams and structure conversations to reflect this change in focus and behaviour.

On the subject of value, revenue, profit and customer experience quite often come up first which is easy to understand, however within a technology department reducing risk, improving operational resilience and technology performance are all valuable activities and need to be represented in that same conversation. If you don’t find the balance you will start to take on technical debt that will eventually slow you down, cause distractions and issues down the line that could easily have been resolved early on if the teams had a more balanced view on what to prioritise.

The second area would be to consider how you structure your teams as this will also have an impact on the overall flow and productivity within the department. In theory there is a right answer but in practice you can spend far too long here trying to design the perfect organisational structure. In my experience you will make more progress in agreeing that the structure will need to evolve as your maturity increases and then start establishing teams with a clear purpose and listening to their feedback as you go.

“Value can always be quite subjective so it needs careful consideration, but once you are clear you can set objectives, coach teams and structure conversations to reflect this change in focus and behaviour.”

For example, I've seen leaders struggle in the past with the difference between teams that have a focus on value streams and ones that are more focused on enabling other areas of the department. Quite often you will have people within your teams whose background is just focused on releasing the value of the work they are doing, for example a feature that increases conversion rate on a website. Frequently companies move people from a more generic website project team into a conversion rate optimisation team but as you scale you will need people to focus on the underlying platform: how it performs, how it can automatically test and validate changes, how easy it is to deploy to etc, which is where you should consider establishing platform teams whose sole purpose is to ensure the technology being implemented scales to meet expectations and the demands of a growing business.

The third and final area would be to have data at the heart of any transformation. You need to promote a clear understanding of the quality and value of the services you are providing to your company, establishing a relationship between business service and the value that service provides to your business. For example, a company may have a product line that supports £10 million in revenue that relies on a set of core networking components. Ideally the transactions that go through these services are tracked in a way that their contribution to that revenue is logged and monitored so if for example 10 percent of those transactions were lost the scale of the problem would be understood by the support teams in real-time.

Data can be complicated so always try and keep it simple: ask yourselves what you expect to be different in your organisation in a year's time when you are through a large part of your transformation and how do you know you are being successful. Be clear on those measures of success and start to bake them into your team objectives, get a baseline understanding of the data metrics behind those measures and structure your conversations around them.

Natural human behaviour means that if you measure something that is straightforward to understand we will naturally look to try to improve it. Take this into consideration when you start out and I’m sure you will start to see a transformation that follows a continuous improvement, delivers business benefits early on and creates more engaged teams that is essential through the journey.