When we talk about DevOps, we talk about addressing technical debt. We talk about how modern delivery processes and solutions might help you cure that technical debt of monolithic systems that are built on obsolete technologies, using antiquated development methodologies. But that jumps past the first critical step toward transformation, as technical debt is not the biggest inhibitor to DevOps or faster delivery. By far the biggest inhibitor to companies moving forward is what I call the skills debt.

I constantly hear this when talking to executives: “I’d like to move forward with a change, but … my team is …” and that statement always represents a skills debt. The primary limiting factor is not the systems in play, it is that the people aren’t ready or positioned to make the necessary changes. We need to make sure we have a strategy for eliminating the skills debt before addressing technical debt. This is the single-biggest risk to DevOps inside the organization.

Why is the skills debt so endemic? It’s not that people don’t care about their jobs, or that they are not smart or capable enough. It is a self-fulfilling prophecy for most companies because people accrue habits, usually over the course of a decade or more, in the way things are done.

Changing Mindsets to Fill the Skills Gap

Ossified attitudes. Just like we talk about addressing the technical debt of hardwired, inflexibly constructed monolithic apps, organizational structures naturally will harden and develop into ossified attitudes as people favor procedures and skills that are already in place. An organization behaves according to Newtonian physics when it comes to change: An object in motion wants to stay in motion, an object at rest wants to stay at rest.

It’s not as though companies want to have a skills debt, but over time they come to value “the way things are done around here” as part of their identity, and the way corporate structures handle career advancement can even play into this ossification. Think about the technical leadership of the company, the people who rise to the top might have managed successful projects in the past, and while they may not crack open an IDE and code anymore, they will still tend to advise teams to stick to what worked in the past.

New people and ideas can’t stick. Let’s say you have this established skills debt running through your halls, and you bring in a new hotshot to shake things up. Once this person tries to introduce change, they will immediately find themselves lacking traction at every point. The skills debt is like a Teflon coating around the organization’s IT practices, protecting the core of the business from its own ability to change. A new person with new ideas will just skate off the top and bounce right off.

If you work for a cutting-edge startup, or someplace like Google or Apple that naturally has innovative engineers lining up to get in, you probably don’t have a problem with recruiting and allowing new hires to make an impact. But what if you work at a big bank, or a large retailer or a consumer goods manufacturer? Changing attitudes and new skills will largely have to be cultivated from within.

Consulting doesn’t address your skills debt. So if you can’t change fast enough, or hire the right people, how about getting some outside help, some “Pros from Dover” to do that transformation for you?

Consultants will approach an engagement from two angles. Many times, the consultants are very academic. They’ll come in and show you a fancy PowerPoint, maybe teach a class on Agile Methodology and tell you what’s wrong with your processes, without a practical starting point. That solves neither the technical debt, nor the skills debt.

Or in the outsourcing model, the consultant can offer to take all your problems away, and have their own resources do all the work in the project for you, even implement a whole new system. That may solve your short-term technical debt, but it will simply allow the skills debt to continue to accrue. You now have a permanent dependency on this external team, unless you allow the project to end. In any case the people responsible will someday move on to other projects and away from your company.

Digging Your Own Grave

So, give up and stand pat? Remaining static is a huge mistake in today’s economy. I don’t have to explain that standing still means certain death for your company. On average, a firm in the S&P 500 gets replaced every two weeks. You’ve got to be able to constantly outpace competition—and even your own past results—on a consistent basis.

What you need to do is take the people that are stuck and unstick them. Yes, sometimes specific people will need to be replaced, but by and large the skills debt is something your whole team has to own responsibility for as a first priority before we talk about the technical debt of DevOps. You have to start breaking skills debt down from the inside out, because doing it from the outside in has been proven to fail.

Start changing the DNA. You have to start somewhere. Nobody will be motivated by hearing that the way they are is “no bueno.” If you go and mandate a sweeping cultural transformation across the whole company, everyone’s heads will explode.

The linchpin to making transformation work? A single project. A real piece of work done a different way, by a representative group of the people who need to change. You know how gene therapy is done? One project that allows teams to use the right tools for the job and modern techniques will insert a bit of code into that organization’s DNA. That replicates into beneficial changes elsewhere in the organization as the success and better experience of that team is propagated.

Skills debt is only paid down through direct transference during actual work. This doesn’t happen without effort, but few worthwhile things are achieved without a little struggle. You can’t just tell people about it, or teach them about it—you have to get people involved in projects that resolve the skills debt of DevOps, before you solve the technical debt.

One technology executive at a big media company who made this change said his teams used to ship code to release every seven months, and now they are shipping once every two weeks, with an eye to releasing once a week. That’s a huge impact that would not happen without paying down the skills debt. There’s not any one magical piece of software the company installed to make that change; in fact, it is still working on the technical debt side of the equation today. It made the change happen within, starting with one project done the right way.

Getting people ready for DevOps-style transformation takes a focus on activity and real action on a real project. Non-passive learning cycles, and hands-on work with the new technologies and new methodologies can cure your skills debt, and then you can start paying down your technical debt.