Surfing The Devops Demand Wave
Like any good engineer, I am always looking to be more efficient whilst being better enabled to do my job.
So I was a DevOps advocate before I even knew what it was.
And I am lucky to be working for Nationwide Building Society. DevOps is a natural fit for our organisation; we aspire to build long lasting solutions, safe in the knowledge that we can pivot quickly to do what’s right for our members. And with such talent in our teams, empowering our Engineers to make real change to our business outcomes is really important to us.
So, with the Financial Services sector currently going through such a high level of change it isn’t difficult to see how DevOps adoption is critical.
And therein lies the challenge. My experience of delivering solutions has taught me to be mindful of two potential outcomes; (1) new solutions may land with barely a ripple (i.e. less take up than expected), or (2) they will land with huge demand and interest. DevOps at Nationwide certainly falls into the latter category (of the two outcomes, this is the preferable one). But this urgency to adopt DevOps has meant some confusion over what it is, what problems it will solve, and who manages prioritisation. Perhaps most interestingly, we have seen tooling demand overtake the methodology and understanding of true end-to-end DevOps adoption.
I don’t think we are the only organisation to experience this. But it has meant that locking down a DevOps enablement strategy has been challenging; with a number of stakeholders advising differing needs (what comes first? Test or Infra automation/IaC, help with code branching strategies, security automation…?). And these issues can be compounded by Engineers proactively identifying localised tooling solutions; which we cannot scale until we can establish the correct funding approach to deliver as an enterprise.
While we have discovered a methodology that has captured the imagination, the challenge is to get it to all our engineers quick enough.
So we are addressing this in a number of ways. We have built a central enablement capability; Engineers who deliver key tooling outcomes and work alongside our wider Engineering community to support the exploitation of DevOps methodologies. We are adapting the way we work, embracing Agile principles to ensure flow, learning how we identify and remove impediments and handoffs across Engineering teams. We are forging closer working collaboration with our Product Owner and business leads, ensuring a business-first approach as we measure what matters (we are learning it is critical that we get the right metrics to demonstrate true business value in what we are doing as early as possible). And to meet immediate demand we have delivered an MVP tooling set. All the while not forgetting that the critical aspects of DevOps (People and Process) doesn’t get lost amongst the clamour for tools.
Of course, DevOps hasn’t seen universal demand. Where pockets of confusion or reluctance exist, we have learnt that the best way to address this is to arrange ‘myth-buster’ sessions; open conversation on what DevOps is (and isn’t!). And we are learning that celebrating each example of progress is a truly effective way to take our story from the theoretical, into the practical.
So now we have business-wide awareness of what DevOps can do for our organisation. Our ethos is not to mandate DevOps, or how it should be implemented. But we do ensure appropriate controls and guardrails are adhered, our business areas have access to our patterns and standards, and our centralised function can act as conduit to ensure knowledge sharing, tooling economies of scale.
And we have learnt some key things as we develop our People and Processes; there is no ‘right answer’. Each business area will have an area of focus that can deliver them benefit. We have found success whenever we have been honest with ourselves on where process efficiencies can be realised.
It hasn’t been easy, but we are well on the way to making DevOps become a natural way of working.
Ride that wave!