DevOps, Software

Ryan Lockard recently joined Contino. Through his career Ryan has gained vast experience in product delivery, leadership, and technical practice excellence. Ryan has transformed teams, organizations and mindsets in various industries and has established himself as part of the new voice of technical product delivery. He is also co-founder of the popular Agile Uprising podcast, which features guests like Martin Fowler, Mary Poppendieck and Bob Martin.

He has a hell of a lot of experience to share so Contino’s US President Jason McDonald sat down to chat with him about enterprise software delivery!

Hey Ryan, why don’t you tell us a bit about your background?

I’ve been in the tech industry for about 17 years, doing almost every possible configuration of technical jobs. Most recently I was at Elsevier, a global information and analytics company and one of the world's major providers of scientific, technical, and medical information. I was Director of Engineering, managing a team of 35 delivery folks and building out a clinical learning management system that is used in about half of the hospitals in the US. It’s used to certify staff on the ground and to provide insights to hospital administrators and improve clinical outcomes for patients.

The Group was having difficulties releasing features and software, so when I arrived I took a step back to focus on principles and practices and to implement more modern, more resilient and higher standard approaches. I optimized the people, processes and tooling at my disposal to achieve these goals in a responsible fashion. Pretty much everyone in the US will touch that application at some point and its quality will have had implications for their health, so I wanted to ensure that it is given the kind of treatment that we would expect for our family and loved ones ourselves. This meant a quality-first mindset: building quality into the process. We built out a pipeline based on modern tooling, infused with a continuous improvement attitude and founded on the Least Privilege Principle, which means ensuring that every component (program or person) must be able to access the resources needed to complete its role.

This brought the group into a much more modern and more effective space. We introduced LeanUX concepts to incorporate clinician feedback, we introduced technical practices like TDD and pairing, we modernized the build and deploy pipelines, better instrumented the code and added robust analytical tagging.  These technical changes made for a much more delightful user experience and measureable improvements in patient outcomes by monitoring the HAI (hospital acquired infection) and CAUTI (Catheter-associated Urinary Tract Infections) rates of our institutional users.

That job gave me an injection of confidence to put myself out there and to talk publicly about how we can make enterprise transformation a more accessible topic and to help others to do it. I got involved doing talks at local conferences and they really caught fire, which led to more and more, bigger and bigger events...eventually I connected with a group of like-minded practitioners and formed a community called Agile Uprising, which spawned a community and a podcast that is listened to by thousands around the world.

That public shift came at the right time: I had had 15 years of getting enough failures under my belt and have the scrapes and scars to know what wrong looks like. And you’ve got to have that experience - that’s the only way to really learn.

Things really accelerated when I interviewed Martin Fowler, author of 8 books on software development and co-author of the 2001 Agile Manifesto, on the podcast.

As a result of these talks and podcasts I took a trip to the UK and gave a few presentations, including one at the RightMove office, where one of the attendees was a certain Contino recruiter called Steve Smith, even though he wasn’t at Contino at the time.

And is that how you ended up at Contino?

Yeah, well, Steve and I stayed in touch over 18/24 months and talked about things. Eventually I spoke to Matt Farmer, the CEO, and it was the most organic conversation I’ve ever had! He was keyed into the things that should be ingrained into the fibre of the enterprise: people, process, operating model - we didn’t step into tooling at all in the first conversation.

I then spoke with Andrew Gordon-Brooks, VP of Engineering, and it was a continuation of the conversation with Matt. No talk whatsoever about tooling! We were completely aligned on mindset, approach and so on, and even got talking about beer and metal! We started the beer discussion with a Suffolk (UK) IPA called Ghost Ship and real ales, before moving into more bold American IPAs and sour beer. For metal, the debate was over the best Joey Jordison project was and my recent affinity for Artificial Brain!

I wasn’t expecting to be wooed away from my safe enterprise gig where I was well-respected and was rapidly getting promoted through the ranks. Most consultancies use the words ‘agile’ and ‘DevOps’ and ‘cloud’ and I get angry…because usually they don’t know they’re talking about! I talked to Vicente, the US-based CFO, and that drove the nail home. I resigned the next Monday.

It’s not where I wanted to go, it’s where I knew I needed to be...I think it’s the only job I’ve taken without actually meeting anyone in person!

Why did you feel like you needed to be here?

You can get really good at technology in one enterprise, or good at technology across the enterprise landscape. I didn’t get into this industry to bring value to just one system, but to many systems.

We’re attempting to do something that’s meaningful to the industry, to the biggest, baddest, hardest enterprises - those that are sometimes seen as too big to transform. I really think that there’s great value we can bring, to help these organizations to change their people, processes and tech to make them great again!

What are the biggest enterprise challenges, in your view?

Well, there are two schools of practice when it comes to DevOps/cloud/agile. The first group is extremely focused on tooling. They want to talk about containerization and orchestration, and they’re cloud dogmatists - they think the cloud will solve all their problems. And that’s fine - after all, we have more tools coming out at a greater velocity than ever before.

But tools are not the answer! The answer is taking a holistic view. And that’s the second approach. Focusing on people first, then process, then tooling - all permeated with the right culture and security concerns. Shifting to this mindset is probably the greatest enterprise challenge.

Security is a separate issue from tooling because it’s more of a mindset. Security-first principles must be built into the mindset of the teams that are building the product. You can see how this causes problems in larger organizations that get very comfortable in their way of doing things and think that security-first principles are for smaller companies. The figurehead of the CISO makes them feel like everything is under control, which opens them up to attacks. Take HBO, for example, who were hacked last July with advance episodes of Game of Thrones, amongst other scripts and videos, being leaked. Or Equifax, the credit monitoring agency that in May lost the personal data of 143 million US customers.

But security happens at the front line, it’s coded into the people and practices at the cultural coalface. It’s crucial that this human element isn’t marginalized when DevOps is being introduced. People and processes are foundational for CI/CD and cloud-native apps and so on.

Another major enterprise challenge that is rarely considered is that as we increase the speed of software delivery, we increase the speed of the other areas of the business. The tooling and delivery folks now move faster but business people are now also getting feedback faster and as a consequence should be able to make decisions around overall strategy faster, i.e. “are we now going down a less/more lucrative path given what we have now learnt from these insights?”.

So a DevOps operating model extends far beyond IT into the strategic and business tier (“Dear stakeholders, here’s the data, and here’s how to act on it”) and really changes the whole business from top to bottom.

Finally, I think the phrase “change or die” that we hear quite a lot really is true. Enterprises are getting slowly chipped away. Take the FinTech scene - more and more startup banks are completely digital and based on blockchain. These were initially incubated in the startup world as edge cases, as outliers that would never rise to prominence. But now they’re about to change the paradigm of financial markets and how we think about investing. Those large enterprises that realize that this is serious will be best positioned to thrive in the future.

What should enterprise look to change to face these challenges?

I think taking a holistic view is key. Whenever I interview people or give a talk I start by asking what DevOps is. If you ask ten people you get ten different answers. But you can gauge where each person is on their journey based on their answer. If they give a tooling-related answer, that person will be good, but they’ve only covered the easy part. The rest (people, process, culture etc.) is the hard part - because tools do what you tell them to, people don’t.

Large enterprises have a particular psychological character that’s interesting to observe. Tribal groups exist that have been established over decades. These have become comfortable with the bureaucracy and complacency and, although they’ll say they need to get more efficient, there’s a kind of paranoia around change that means that nothing really ever changes.

I like to say to them: “Suspend what you know for a few minutes...if we were going to start over today with more modern approaches, what would that look like?”. Then we take that vision, compare it to where they are today and identify concrete steps for how we can get closer to the vision.

The next stage is to prove that it’s possible to get incrementally better at something like an individual application or service. It’s when you take those small improvements and scale them horizontally and vertically that you start lifting the modus operandi of an enterprise. Technologically speaking, a rising tide lifts all boats.

There is no turnkey solution. There are no quick wins. Which is why it’s so important to have the right mindset and an open attitude to change. Willing something to happen isn’t going to work. You need to make change happen. To bring in experts. You need a loose plan of action and a tolerance for having been, and being, wrong. If it were possible to create a blueprint for all this stuff, it would be out there already - so instead you need fault-checking to be built into your systems, speed and agility to move when you find out you are wrong.

‘Being wrong’ is interesting. I have previously worked for an organization that was extremely dysfunctional. I was not successful there! But the biggest takeaway was what I learnt from my and their failure. In only six months I learned how not to staff a leadership team, how not to try to make change (peo0ple were constantly afraid of losing their jobs) etc. It was a masterclass in how bad it can get...and probably the best learning experience of my career. Enterprises take note!

Thanks, Ryan!

Thank you!



DevOps Insights Directly to Your Inbox!

Join thousands of your peers and subscribe to our best content, news, services and events.

  • Jason McDonald


    Jay is a former International Equity Trader turned IT Pro. Prior to Contino, Jay spent four years leading the Professional Services Practice at Amazon Web Services. Jay has 20 years of diversified IT and Business experience leading Enterprises through complex Cloud and DevOps transformations across financial, healthcare, life science, manufacturing and CPG industries. 

    More Articles by Jason