Company Announcement, Interviews

James recently joined Contino in the role of Principal Consultant. Given his wide experience and expertise we thought it would be very valuable to sit down with him to talk all things DevOps.

Why don’t you tell us a bit about your background?

Sure. I’m from a farming background originally, I grew up on sheep farms in sunny west Wales.

Now, there is no obvious link between DevOps and sheep farming, but there are a few similarities... there’s a lot of automation in the farming industry, based on the simple fact that it’s incredibly useful. Much like in large organizations, the cost benefit of automation makes it a bit of a no-brainer most of the time. In fact, with farming it is a lot easier to mathematically calculate the benefits that automation will bring you. The context is simpler so it’s more black and white.

I then took the not-so-well-trodden path from sheep farming to IT…after taking a degree in software engineering I ended up in London in 2002 as a software developer. I was extremely fortunate with my first job to be drafted into a project that was already four years late. I say “extremely fortunate” here because that job taught me how not to do software development. The company in question was trying to release a piece of educational software and had brought on a few fresh faces to drag it over the finishing line, but as the release date drew closer more problems cropped up because they were doing everything in Waterfall. Not only that, the project was so late that the most recent software released in that space was superior to what they would be releasing.

So, four years after the project start date, we rewrote the whole thing in the latest .NET and adopted this crazy thing called “Agile” - and there weren’t many people doing agile back in 2002! The team was mainly using Extreme Programming and it did just about work...there was an increase in quality, certainly.

I quickly left the company, however, to pursue a new development called “Continuous Integration” (CI). We wanted a way of merging everyone’s code changes and I was tasked with creating something like what we would now call a CI System. I had a local client that would compile changes on your laptop from the main trunk. It was pretty rubbish, but it was the best I could do at the time!

Then I discovered a CI tool called CruiseControl that was originally developed by ThoughtWorks. I dropped my project and began using that instead. I ended up becoming a Continuous Delivery (CD) consultant after working on a CD system at uSwitch. At the peak, in 2007, they were deploying seven times a day - I didn’t know of anyone other than Flickr or Amazon that were doing more deploys per day.

Looking back it’s quite interesting to consider our motivation. We were certainly very detached from the business concerns driving these new ways of working, we just thought it was a cool thing to do! It was great to be able to get stuff out into production quickly...and get people off of our backs! Eventually it became clear that this tool has real business value - being able to get changes out in time for TV ads for example. That was a lightbulb moment: that CD is not just for keeping geeks happy, but hugely affects business value!

A bit of consulting in the financial industry followed. Crazy sums of money were being thrown into projects, which wouldn’t really deliver anything and the response would be ‘oh, well!’. This was in 2010, those were the early adopters, who were very much experimenting at that point. In the financial services industry at the minute DevOps is starting to take off. They feel as if they should be part of the mainstream but in their own industry they’re innovators - just like with CD in 2010.

I moved on to management roles, looking after infrastructure, DevOps and release management teams before starting my own little consultancy, DevOps Ninjas. It was a two-man show we put together to test the waters, to see what organizations really wanted. We attended DevOps Days, went to a lot of meetups, UNICOM seminars, and so on. It became clear that many companies had a huge interest in DevOps because they didn’t really know where to begin, so the consultancy became our full-time focus.

It’s worth noting here that DevOps is an interesting concept - it suffers from a kind of identity crisis. It has no official definition so anyone can make it anything they want it to be. So I have spent a lot of time explaining what DevOps is and then explaining why it’s beneficial. Technology is emerging at a faster rate than ever, and every new thing seems to be subsumed by “DevOps”. Lambda? That’s DevOps. Docker? That’s DevOps.

So my approach was - and is - to remain resolutely solution focused, remembering that DevOps is a means to an end, not an end in itself. Organizations will always want help and support in how they work, and understanding how to help them do that is a skill that will always be in demand.

I then joined forces with DevOpsGuys about two-and-a-half years ago. James Smith is a friend of mine and he eventually convinced me to join. It was an opportunity for me to move back to Wales and spend a couple of hectic years building out that company while delivering work for my own clients at DevOps Ninjas!

My last movement before Contino was to start another business of my own. I created a product to educate and train people in the ways of DevOps and automation, geared slightly towards a C-level audience. The purpose is to help organizations with their transformations and to get them prepared.

Over the last few years I had been bumping into Contino all over the place. I’ve known Ben Wootton since the early days (we met at DevOps Days in 2013) and run into each other at DevOps dinners and various conferences.

What tipped the scales in the direction of working at Contino?

It was an eye-opener to get to know a few of the people at Contino and to get to grips with their approach - there’s certainly a lot of alignment with my own style. There’s far more empathy with the unique situation of each organization and an emphasis on education and training, rather than hammering down on selling as much automation as possible.

The folks I’ve met are very interested in actually helping organizations rather than just solving a problem for them. I definitely feel that just solving someone’s problem doesn’t help, what does help is teaching people how to solve their own problems. I had also heard anecdotal stories about the level of focus on handovers and the engagement model with clients as well, which is very much aligned with my own philosophy.

What kind of enterprise problems do you think are most prevalent?

There are problems across the board, really. The largest of which is often figuring out what their problems are. Really nailing down what’s not working well and what needs to be improved. To make things worse there’s a lack of case studies demonstrating how transformation is properly executed. And, even if there were, organizations shouldn’t look to just follow exactly in the footsteps of other companies...cliched as it sounds, it’s a journey that each organization needs to go on by itself! You can’t use someone else’s transformation blueprint and succeed.

But unfortunately a lot of people want to take shortcuts. It’s our job to teach people about the mistakes and pitfalls that they will likely face, rather than telling them how to copy other organizations. They have to figure this stuff out by themselves - work out their own KPIs and objectives etc.

Once they figure out their problems, a lot of organizations then find that they are way behind the curve in terms of technology, it’s evolving much faster than people can possibly keep up with. Somewhere in your industry there’s another (much smaller) organization that can keep up with these rapid changes - or just got lucky and by chance rode the right technology - that has a big technology advantage. Here, larger organizations are hamstrung because they can’t just adopt the latest technology all the time. Knowing which levers to pull - and when - to move forward consistently is crucial.

Technology hasn’t changed this fast ever before so there are no models for how to leverage new tech changes - and smart organizations are starting to realise the necessary conclusion that emerges: you need to have a model for innovation! A model for being more agile and more responsive to change, rather than for adopting particular changes.

The key message to get across here is that DevOps is a huge enabler for agility and innovation! It’s no longer the 1990s, you need to be very, very agile and extremely capable of changing and innovating - otherwise before long someone will design a product that will put you out of business.

I find that organizations are struggling mainly because they haven’t come to terms with this reality yet. They’re frustrated that their strategies aren’t working and asking “why are the processes and tech we used 20 years ago no longer working?”. The answer is in the question!

What do you want to achieve at Contino?

I’d love to push and evolve the educational side of the business - making sure that we actually help organizations, that we disseminate information and skills that will enable organizations to fix their own problems. This certainly won’t put us out of a job - there are many, many organizations that need that kind of support!

But the rate of change in the industry is massive, as it is in DevOps itself. It was originally about Dev and Ops, now it’s about a holistic concept-to-cash model - and there’s so much play and room for manoeuvre in that massively broad definition! We need to be on our toes to keep up with where DevOps is headed!

Thanks, James!


Interested in working with us? We’re hiring! Check out our current vacancies across the UK, US & Australia.



DevOps Insights Directly to Your Inbox!

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