DevOps, Cloud

Joel Parks, who joined Contino last July, is a veteran Cloud Architect and DevOps champion with over 20 years of experience in the industry.

He’s seen it all, so Contino US President Jason McDonald sat down with him for a chat about his background, how he stays up-to-date with the latest tech, how to build cross-functional teams, how to avoid the biggest transformation pitfalls, what the most rewarding aspect of transformation work is, how to manage conflicting transformation needs and his message to C-levels!

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

My background is a little weird. I was an audio engineer for a long time, which is really just a systems engineer in another guise. I bounced around the entertainment business for a while, but at a certain point after I had had my first child I realized that working in that industry wasn’t fun anymore! So I decided to spin my career in a slightly different direction.

Coincidentally, when I had been at high school a guy in my home town in Texas built a local ISP and my high school job was running around trying to maintain it...so I had to learn about networking and fractional T1s and dial-up modems and setting up email servers and all the stuff you had to do to set up a local ISP. I then graduated to maintaining the campus computer network at university so I had been around tech most of my life and figured that I knew enough to get my foot in the door. I knew the owner of a small civil engineering firm that had offices across Texas. It was growing rapidly and struggling to scale its IT. I said: “How about you hire me as your IT department of one and I’ll help you solve these problems”. I worked there for three years and in that time developed the IT infrastructure into a service that they were selling as part of a project management suite for other subcontractors. So IT began to leave the cost side of the balance sheet, or at least started paying for itself.

I then transitioned to larger and larger enterprises. For example, I worked at a large multinational manufacturing company where I was responsible for their global network and compute footprint before becoming a cloud architect for a large insurance company. But at a certain point I got a bit fed up of being married to one organization. I love the transformational work, which, in just one organization, essentially amounts to seasonal work. You can’t be constantly flipping paradigms...the place would blow up! So a transition to consulting made sense, which is how I ended up at Contino!

You’ve moved between lots of different roles and skillsets, how do you keep your knowledge up to date?

Firstly, I’m a really quick reader and secondly, but more importantly, I have been really fortunate to have been able to surround myself with people who are much, much smarter than me.

I see a lot of junior guys making the mistake of not only wanting, but needing to be the smartest person in the room. This is the worst thing you can possibly do. Much better is to put yourself in a room in which you are not the smartest by a considerable margin.

In my first job when I was by myself, for example, if an idea didn’t occur to me then there was no way that it was going to happen. By comparison, a former boss of mine wrote operating systems for satellites...and he’s just a never-ending source of interesting thoughts and a fountain of new ways of doing things. I moved to Contino because I figured that I had the best chance of upping my skills and following my own advice here!

What are the main enterprise issues that really grind your gears?

One thing that drives me crazy is when people make bizarre statements implying that their conception of DevOps is nothing more than ‘tooling’. These people and I need to spend some time together!

Another common one is when executives are bought into DevOps, but they still think in terms of projects they have worked on in the past. They think “Excellent, in a year we will ‘be DevOps’”. That’s not how it works! Thinking about DevOps adoption in terms of typical IT projects is an excellent way to make fundamental mistakes early on. It becomes just another artificially time-bound project on the annual plan that you have to tick off and you miss the essential continuity that underpins it! If it becomes ‘just another project’ then you get a PMO on it and it gets moved into a giant Waterfall project plan. The PMO will do a resource estimation and will see who maybe has the bandwidth to do some tasks here and there they won’t consider the transformational aspect at all. DevOps is an ongoing initiative and the first step is getting people to understand that it is not another project! If you think you can spend a year doing a Waterfall project and – poof – you’re DevOps, you’re in for a shock. DevOps is a new operating model centred on continuous improvement. You’re never done with this, it’s a new way of doing business.

The single biggest mistake that people make when going through this change in operating model is thinking that they can do it one department at a time. Or making the mistake of creating the ‘DevOps Team’, that’s another anti-pattern. I’ve seen it done both ways: some start by making the Ops team DevOps first, sometimes Dev. But the whole point is that we’re trying to change communication patterns, doing that intra-team is fine, but if you miss the inter-team communications, then you’re missing the biggest piece!

What’s the most rewarding aspect of this work?

The most impactful moment in a DevOps transformation is building that first, core cross-functional team that has representation from all the relevant teams. I especially love to move them together geographically working on a lighthouse project. It’s amazing to watch what happens. In their siloed teams, they each think they have unique problems within the organization: people are always pushing stuff on them, they’re always drinking from the firehose, no one properly explains requirements, etc. It’s funny to watch how, by proxy, they slowly realize that the whole organization is like that! Everyone has the exact same problems and it’s incredibly rewarding to watch the discussions evolve and the lightbulb to come on for everyone. Once they establish some camaraderie and visibility of their common problems the conversations change and take on a much more personal and productive tone. They stop talking about tickets and start talking about how to fix their problems and they’re doing it as a group! They unite around common problems rather than thinking that the other teams are the problem.

In the DevOps world people get obsessed with tool chains and that’s interesting in its own way...but that’s not what motivates me. It’s matching everyone up into teams and watching the conversations evolve - perhaps with some prodding here and there - that keeps me coming back.

I’m probably atypical in that the Ops aspects of DevOps, whilst incredibly important, is less interesting to me. The applications side of the house is looked at first in most DevOps transformations because there’s such a lack of people with outside perspectives who know how to speak app devs language and I can sort of speak Ops and Dev because I’ve worn both hats. Typically, everyone thinks that Ops is stuck in the stone age and that Dev is out there being really innovative...this is usually not the case in my experience. That’s the perception, but it doesn’t match reality. Most of the time devs are fighting just to avoid getting completely buried in feature requests. Normally, there’s no proper gating or sprint planning and requests are coming in from a hundred different sources and they’re trying to reconcile functionality on the fly as they’re coding...and that’s how you end up with a big ball of mud.

I find working with those strained app dev teams and showing them different, more sustainable approaches is really rewarding.

What are the best approaches for building the kind of cross-functional teams that you have been talking about?

From the outset I’m looking to identify the right people who I want to stack my deck with. During the initial assessment I usually get the broad cut of people within the organization. It’s usually pretty clear who I need to focus on when talking to any specific functional team. If there are 10 people in a room, there will be two that are the most engaged and switched on that would make for the most insightful and informed teams within my Centre of Excellence (CoE).

The things I want to identify are: one, do they have the respect of their team members? Two, are they change driven? There are change-driven people and there are status quo people and we need both! I’m not knocking anyone at all, but, for this effort specifically, you need change-driven individuals.

Identity the key players early and once things have progressed past the first assessment I then start to reveal my hand to the line managers and others higher up the food chain. It’s important to get their buy-in and explain exactly what this assignment means. You’re asking for all of their best people, so make sure they know that it’s an investment, you’re not going to burn time or money: “If you want to do this, I need all the good people that have the skills and influence!”.

The next step is to begin the process of coming together as a team and begin the conversation between all of these different people by bringing them together geographically.  

How do you stop that team becoming the DevOps Team you warned against earlier?

You have to time-box it. Otherwise it does become the DevOps department and that’s the danger. Give the team specific delivery targets. Once they’ve delivered a specific lighthouse project then we take everyone who was part of the original CoE and cross-pollinate them into three DevOps team to further propagate the skills and federate them throughout the business.

But if there is no time-box on the team it will never go away!

Any other pitfalls to watch out for?

Changing too much, too fast. Executives decide to do DevOps and think “Great, we’ll do it in a year”. No! Don’t! You’re changing some fundamental properties of the way that your organization operates. You’re pulling on some of the fundamental threads in the organization and the risk is that if you change too much too fast you can really damage an organization.

That’s why it’s so important to understand that this is a long-term continuous effort and not just a flash project. If you’re in a hurry you will unwittingly damage the organization. You can sustain a couple of cycles of very rapid change but then cool out for a while. Your people need time to absorb what they have learned and to reflect. If you continue to push you run the risk of burning people out, exceeding their ability to absorb change or just confusing the hell out of them. Some people might not be able to contextualize changes and they will look at the constant changing of requirements and will get frustrated and leave. And you probably really need those people!

A major pillar of DevOps is creating a culture of ownership not only of applications but also of infrastructure, processes, security etc. There’s a bizarre occurrence in enterprise IT that I’ve seen over and over. One team will have ownership of an app or process for about six months, then it moves to another team, and then another. This is really disheartening for individuals who have that pioneer spirit! And those are the people that you really need and if you continuously grant and revoke ownership you’ll see it reflected in your staff turnover. Don’t be fickle in the way that you deal with ownership!

How do you manage these different needs? How do you time-box people without putting too much pressure on them with rapid cycles of change?

I’m really making the case for small iterations. Cycle times should be really short.This gives you predictable reflection points to see what’s working and what’s not. That’s also why the year-long plan doesn’t work. If your first reflection point is a year down the line then your project could be done with before you get there. Give yourself time and space to reflect and adjust frequently.

This also helps to foster communication. Having the opportunity to pivot or change tack every few weeks, at least early on, is beneficial. Especially given that you’re going to be learning a lot about the organization that you didn’t know.

I’ve never seen an organization really embrace these ideas and walk away after six or nine months and say “nope, we didn’t really learn anything”. It’s a massive learning experience right across the board.

What message do you have for C-levels looking to transform their organization?

My message is: you’re not excluded! Your involvement is required.

Another transformation anti-pattern I see is individuals thinking that this is an IT transformation and it doesn’t really have anything to do with the business. It has everything to do with the business! And if the business is excluded it probably won’t work out well. If the operating model within IT is DevOps but from the business to IT is Waterfall then very little will have been gained.

It’s crucial to talk together to calibrate the functions of the IT organization against business outcomes and objectives.

Lastly, what do you get up to in your free time?

I’m one of the organizers of DevOps Days Nashville, I also run the Nashville Kubernetes Meetup and I’m heavily involved in the DevOps Meetup and the Nashville Tech Council. Otherwise I’m an amateur radio operator (callsign is N5JJP), a member of the Audio Engineering Society and a Cub Scout dad with three kids and an incredibly patient wife!

Thanks, Joel! If anyone wants to hear Joel talking more about DevOps you can find him on the Cloud Unfiltered podcast.   

  • Jason McDonald

    President

    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