DevOps, Interviews

Tom Cunliffe recently joined Contino as an Account Principal. Anthropologist-turned-entrepreneur, he has had a diverse career to date, with lots of insights to share. So I sat down with him to talk about anthropology, DevOps and the enterprise. 

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

I studied anthropology at university and was planning to do a PhD, but decided to change tack.  I realized how limited my career options would be as an academic in a fairly niche discipline.

Instead, I joined a startup as a junior project manager working with an Agile team. I started to pick up random technical skills along the way: the basics of application development with Python, Linux systems administration and how to build CI pipelines. I started out managing agile teams and delivering products, and have become more and more technical over the years.

After the startup, I had a great opportunity to build an in-house Agile development team from scratch. I learned how to introduce Agile delivery into an organization that had an established waterfall process, manage stakeholders during that transition and educate the business about new ways of working and technologies.

I became an evangelist for Agile and managed to deliver a supply chain management platform used by 30,000 suppliers and buyers globally in a more or less Agile fashion. To sum up, I learned the hard way how to bring new ways of working into established, process-heavy, multi-stakeholder organizations.

One of the challenges we came across during that project was around how to develop and test individual microservices in isolation. Microservices depend on other microservices and if you can’t develop, test and deploy just one then you risk building a ‘distributed monolith’.

This experience lead, in a roundabout way, to me co-founding a product startup focused on solving this problem. We raised investment, built an open source testing tool that became quite popular, and started to build a commercial SaaS version. However, we struggled to secure a reference customer and further investment – partly because we were a tiny company going after the large enterprise market. But it was a great experience and I learned a huge amount about building relationships with VCs, managing investors, developing a business strategy and engaging with the open source community.

How did you end up at Contino?

I had my eye on Contino since the beginning. It seemed like the next logical step given my hybrid business/technology background and experience with DevOps technologies and digital transformation. Also, because of my background in technology startups, I have plenty of experience of building and enabling teams, which is a crucial part of all our engagements.

How did you make the transition from anthropology to technology?

Anthropology is all about the study of people and culture. Software engineering is all about people and culture, too. Technology is relatively straightforward – you can do anything with computers these days – the bigger challenges lie in how people use the technology.

As a principal consultant, you have to learn about each client’s business domain, their organizational structure, the language they use, their motivations, their rituals and what words like ‘Agile’ and ‘DevOps’ mean to them. Your job is to find consensus between cultures: a shared understanding of meaning between your world and their world. This empathy and understanding is what drives success.

Let’s talk about some of the challenges involved in building an agile team.

Sure. A major challenge is often finding a strong and skilled product owner. You need to find someone who has a deep enough understanding of the business and who is experienced and empowered enough to make the right decisions (often within a day) to keep the team delivering. This person must be able to manage stakeholders at different levels of the organization and must be able to prioritize ruthlessly (saying ‘no’ is really important!). Many people can do parts of the role, but it’s rare to find all those qualities in one person. It requires a delicate balance of being opinionated on the one hand, and diplomatic on the other.

The next challenge within the enterprise is reconciling an organization’s traditional ideas of how projects are managed and run with Agile ways of working – this is not easy! The key lies in empowering and nurturing your people: giving them autonomy within a trust-and-verify approach.

But an Agile approach is never going to work unless it occurs within the context of wider organizational change. We often see teams within a traditional operating model being told that they are now ‘Agile’. This means they start performing the standard Agile rituals and ceremonies – holding stand-ups, coming up with user stories and so on. But because they are doing these within their own ‘silo’ it means that they are optimizing in isolation. The work just gets bottlenecked elsewhere. Unless you adapt the whole operating model you get pockets of optimization that do not scale and you don’t see the benefits throughout the value stream. To get that wider change it’s imperative that you get buy-in from senior leadership. It’s the only way!  

What are the common enterprise DevOps challenges you see?

People often see DevOps as a set of technical tooling, a thing you can ‘have’. In reality, it encompasses people, processes and tooling, with the latter really just enabling the change in people and process. It’s the people that really drive the change, not tooling. And that is often misunderstood. Many of our customers get this, but a lot of their stakeholders don’t. In these cases our job is to help them to educate their stakeholders.

Another challenge is that a lot of organizations see moving to the cloud or adopting DevOps as a way of saving costs on data centres. “Data centres cost loads and are a bit old-fashioned so let’s move all of our VMs to AWS.” They then try to apply traditional security models and traditional ways of working to the cloud – and it just doesn’t work like that! It’s very possible that you won’t see any added value if you just lift-and-shift to the cloud without rethinking your value stream and how you architect applications.

What, then, is the best way of maximizing the benefits of the cloud?

You need to think about how your applications are designed and architected. Some might be well-suited to containers in the cloud, some might best be replaced by a SaaS service. There are often tough decisions to make regarding sunk costs on vendor products.

You also need to be working in a cross-functional way to get any real benefit out of the cloud. Start with the value stream and the operating model and understand that DevOps and the cloud are simply ways to get you to that better way of working.

Finally, it’s important to maintain focus on why you are doing this. Is it to build higher-quality software, faster? To develop a culture of engineering excellence? To build a digital business? In all cases you must remain focused on the actual outcomes of transformation. Pick measurable business outcomes (e.g. faster release times, greater adoption of new services by end users etc.) and work backwards from there. This sounds obvious, but it’s very easy to get focused on the idea that everyone needs to be using the latest tooling for the sake of it.

What would your message to C-levels undergoing this transformation be?

You have to be prepared to make some very fundamental changes. It’s called disruption for a reason. You can’t just chip away at an existing process if the process is not fit for purpose anymore. It’s a big, scary thing to change structures and to reskill people. But if you shy away from the scope and depth of the task at hand then you’ll have some success but it won’t scale.

Your organization needs to change as fast as the world is changing. The rate at which consumer expectations are changing is scary and so is the rate at which your organization needs to change.

Thanks, Tom!