Interviews

James Woolfenden recently joined Contino as a Technical Principal. James has extensive experience in DevOps, having worked in the industry for over ten years, so we sat down with him to find out more of his thoughts on the major enterprises challenges that he has seen during his career as well what the future holds for digital disruption in the enterprise.

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

I’m a second generation IT professional, my dad ran an IT systems house in the 80s (Digitus) and I worked there as a teenager, putting together IBM XTs, Compaqs and Macintoshes and sending them off to customers. I then went off to be a scientist (I’m an oceanographer by training!), spending time analysing satellite imagery with NASA. We used these awesome Silicon Graphics machines to model the properties of the ocean. They were great big things that looked like something out of Silicon Valley. Mainly because they were from Silicon Valley. They were powerful 3D graphics machines we’d used to process then very large image data-sets. This was the nascent days of the internet so in-between we’d be goofing off on xMosaic (1994), it felt like the future!

But being an Oceanographer doesn’t pay very well! So I switched to IT. I saw a niche for myself because, although there are many incredibly smart people in science, they’re totally f*cking disorganized. You get Professors who can write amazing hacky code, but can’t structure it in a way that other coders can even remotely understand. I realized that you don’t have to be the cleverest, you can be the fairly-clever-but-organized one and succeed that way!

I knew enough about tech from my oceanographic education to get started in the industry in warehouse management systems. Automating what goes on at Tesco behind the scenes, that kind of thing. Then in the dot com era I then started working as a developer working on web-based CRMs. At the company I worked at, we would use the software we sold (which tracked defects) to track the defects in our own software delivery pipe. Doing technical things that weren’t the “actual thing” but rather the “thing that helps to build the thing”. So I was taught to be organized in terms of tracking, and this became my main role at a number of future firms. My job was to consolidate best practice so that, instead of having spreadsheets flying about everywhere, we had a controlled, automated system.

The next phase was working in configuration management/technical release management back around 2002. This was basically DevOps, but before the cloud. I never worked as an Ops guy, I was always working with application teams to deliver software. Always enabling and trying to avoid the “Department of No”. This meant building relationships and becoming the one trusted person that the Ops team would deal with. Each side thought that the others were “f*cking w*nkers” and I moved into the role of the gatekeeper that could understand both parties.

Then came the cloud! It gave us the ability to take away the Department of No’s control - so, as you can imagine, we jumped into that with both hands: “we can script that! And that! And that!”. So my role evolved to encompass provisioning the infrastructure as well as building and deploying the application.

But this became a bit samey after a while. The problem is that, as a contractor (which I had been for the past 11 years before joining Contino) the expectation is that you go in and give the client a “technical reset”. They tell you that the problem is “deployment” or “infrastructure” and you go in and fix something. But the real problem is why the company made the decisions that led to the “problem” in the first place, or why their company is structured in a way that leads them to pay no attention to critical issues. So, in practice, what you’re doing is giving them a break for a few years until they end up in a similar situation because the root problem has been left unaddressed. As a contractor you can’t address that root problem, even though you know what it is. I wanted to properly solve these problems, rather than just get paid to implement quick(-ish) fixes. As a contractor you become more technically competent from the range of work you do and the different environments that you work in, but it would be nice to progress the art, to move the ‘thing’ ahead. And that can only really happen from the top down.  

And how did you end up at Contino?

When I decided I wanted to change direction, I made myself known at various Meetups to find out what was going on and realized that there were other people doing the same thing as me. I met Ben Wootton (Contino Co-founder and CTO) and was initially slated to start on a Contino project three years ago but the day before I was due to start the project fell through! A few weeks ago I quit a previous job and within half an hour of posting my availability on LinkedIn, Luke Gunn, Contino Talent Manager, was on the phone to me. And where else would I work?!

What is the kind of work you go into enterprises to do?

You’ve got to remember that what we’re trying to do is make an organization better.

There’s a pulse to every company’s ability to deliver: a heartbeat. With a low-performing company that pulse beats once every six months. You have to enable that pulse to speed up. The company still has to develop the ideas and write the code, but you can remove all the other barriers to making that happen. Remove the barriers that take them from being slow, clunky outfit to a scenario in which it’s only their imagination that holds them back.

So, imagine that frustrating place where you know that you’re being held back. And you’re just thinking: “Come on, guys! These aren’t technology issues! They’re process issues!”. In this context, my job is to go: “stop that, and that...and that!”. A key strategy is to keep asking for the justification for everything. Why? Why? Why? You don’t find many people asking ‘why’ in the enterprise. For example, if someone says a change is a security risk I sometimes ask “who said it was a security risk?” and the reply, more often than not is, “well, I assume it is”. People make the assumption that there’s some kind of problem - all the time! It’s a communications issue again.  

Do you think disruption is coming soon for enterprises?

Well, you can judge for yourself. Go to some hackathons and listen to some of the conversations. The other day, I was at an Open Banking Hackathon and there are people standing around asking whether this or that is a good idea and I’m thinking “Monzo has already done that! I’m pretty sure you should get cracking.”

And where are the weaknesses that will be exploited by the next generation of companies?

Well, there’s so much cruft in enterprises still! ITIL and Prince2...all these people, like release managers - why do release managers exist? Because we don’t trust the release! Why don’t we trust the release? Because we don’t trust the engineers. Why don’t we trust the engineers? Because no one is paying any attention to them! No one is training them or giving them the tools they need. People think that all engineers are the same (they haven’t read The Mythical Man-Month). This is categorically not true! Putting twice as many devs on a project does not mean that it will get completed twice as fast. If anything, it will be completed more slowly. Think about Conway’s Law: the software that companies make reflects how they’re structured. And all these managers are single points of failure...this is reflected in the final product!

At Contino, there’s a game we play with client teams to show them how this works. First, we create four teams, which are all tasked with building an object (which is the same across each team). They try three times, each time with different levels of communication: first, everyone is blindfolded; second, one person can communicate on behalf of each team with the other teams; third, everyone can communicate freely.

Which level of communication results in the best projects? The best result is with everyone communicating freely between teams. Surprisingly, the second best is with no communication. The worst is with one person communicating between the teams, which is what a project manager does!

Enterprises have a tendency to treat people as interchangeable resources that need to be micromanaged. But if you’re a smart manager, you trust the people that work for you to be smart and give them the tools that they need to work. If you treat people like grown-ups then they generally behave like grown-ups.

The result doesn’t have to be perfect, just good enough. Look at ASOS, their technology isn’t cutting edge, but it’s good enough. And they’re raking it in!

In your view is there anything like an established way of doing DevOps? Or is it completely bespoke to each company?

I think there are some basic ideas that are always applicable to companies that are struggling to transform. Often teams are so overwhelmed by the basics - can you deploy safely? Can you restore things in a crisis? - that they’re in crisis mode all the time. Everyone’s only doing operational stuff and no one has room to breathe.

A common starting point should always be giving people some space and some decent processes so that they have the energy to work the rest out themselves.

How can enterprises get the talent they need?

The people they have are good enough in principle. But they need to be given that space and empowered a bit. If they were trained more and trusted more it would go a long way!

If enterprises gave their people the impression that they’re as interested in the well-being of the teams as much as the well-being of the project that would be a good start. I have this hunch that motivated people might do a better job! It’s not crazy is it!

What would your message be to C-levels who are looking to transform?

No problem: find a way to encourage mid-level engineers! Because there’s no pathway for them. They go from junior engineer, to mid-level, to management (which is not technical at all!). But there’s no necessary overlap in skills between a good manager and a good engineer. This isn’t a proper career pathway and it just results in turning good engineers into bad team leads, because there’s no other way for them to earn more money. And becoming a contractor is the only way out!

What do you think the next 5 years holds for enterprise DevOps?

Well, if they don’t adapt...they’ll die. They’re dinosaurs and they’ll end up like Blockbuster. Disruption could happen fairly rapidly in all these industries once some of the key hurdles are solved. I can feasibly imagine a digital insurance company disrupting the insurance industry, for example. I mean, ask yourself: what happens when Amazon starts doing insurance or banking? “Alexa, can I have a mortgage, please”. Without all the extra servers and managers who aren’t adding value, imagine how much cheaper it would be. We’ve seen that disruption happen before and I see no reason why any existing industry couldn’t suffer the same sort of disruption.

And what do you get up to outside of DevOps?

I used to spend a lot of time doing watersports and I still swim fairly regularly, but unfortunately not as much surfing as I used to.

These days I’m a family man! I have three daughters, two youngish and one grown up, so that keeps me busy. My youngest daughter goes to an awesome special school, she is autistic with learning disabilities and sensory challenges. She was non-verbal so we had learn and pay attention to alternative non-verbal forms of communication. So that has made me see the world in a very different light. That’s something that’s very important to me.

Thanks, James!

Thanks :)