Dear CIOs: Stop beating yourselves up for being behind on transformation

Let’s break down three misconceptions about digital transformation for CIOs racing to make progress
1131 readers like this.

CIOs, the next time you're sitting at a conference, look to your left or look to your right. It’s likely that neither one of you has finished your digital transformation. Most likely, neither one of you is even close. One of you may have barely started.

It’s the unspoken truth of the “digital transformation” age, based on my conversations with CIOs: Everyone thinks they are horribly behind their peers. 

Fact is, you read story after story about the companies at the head of the pack – the born-in-the cloud startups, the Netflixes of the world, or the occasional enterprise IT company already running a large percentage of production apps in the public cloud. You don’t read many stories about the manufacturing company making steady progress building a hybrid cloud architecture while managing a large, existing data center infrastructure. 

Many IT leaders begin initial transformation conversations with me in almost a hushed tone. They don’t want to talk about transformation on the record – because they don’t consider themselves shining examples of fast progress. And no one wants to admit they’re just getting started, or that they are “behind” their competition.

You are not as far behind as you think you are.

Good news: You are not as far behind as you think you are. That’s the first of three misconceptions about digital transformation that you can let go.

While you may be tiring of the very phrase “digital transformation,” as it is being used to describe everything from business model revamps to process tweaks, your marching orders from the business remain clear. You need to gain speed, from faster dev cycles to faster time to market. You need to be agile: When a competitor serves up a twist, you must respond. You need to tap into technologies such as cloud, mobile, and big data for a reason: To get closer to customers faster, and stay there. Digital transformation is just another way to say business transformation by exploiting technology.

In May 2003, Nicholas G. Carr famously proclaimed in Harvard Business Review, that “IT doesn’t matter” – arguing that IT is a non-differentiating cost of doing business that should be minimized and de-emphasized. And many, many companies subscribed to this notion – only to discover in the last few years that most any industry can and is being disrupted by new digital (IT) investments and market entrants. Time is of the essence, but you’re probably not behind all your competitors. 

Even if you dislike the term digital transformation, you’re executing on the implicit business mandate every day. Let’s examine this and some other misconceptions about how to get transformation done.

Misconception 1: You’re a transformation slowpoke 

Why do CIOs have the feeling of being so behind? First, there’s much admiration of (and popular press around) the fastest transformers, but little critique of how hard transformation is or how long it may take for a typical Global 2,000 company.

For example, I met with a manufacturing company two years ago as it grappled with a business mandate: Reinvent customer service in a digital world. The customer service organization needed a new portal, for starters. 

The IT group wanted to create it in a nimble, fast way, using DevOps principles and cloud tools. But this traditional IT organization worked within the common 80/20 dynamic, where 80 percent of IT budget went to maintaining existing projects and 20 percent went to innovation. They were a textbook example of the impact of the Nicholas Carr philosophy.

This manufacturer was convinced it was hopelessly behind because it didn't have a cloud strategy, never mind a DevOps strategy, yet.

The first question for this company was: Do you have the corporate will to become more agile? Without strong will, transformation won’t work. This company’s brand reputation included customer service strength, so they had the will – and the company and the IT organization were fully committed.

Then the question becomes, how can you start to transform without throwing too much in the blender at once?

The first answer for this company, which had long ago outsourced much of its development overseas, was to do agile learning. They sent key people inside the organization to learn to become scrum masters. They requested that the outsourcing partner put agile experts on each development team. In short, they built an agile overlay onto their existing business processes, as a way to start.

This company didn’t own its own data centers, either. They wanted the flexibility of public cloud, but couldn’t rush in. So they started with select business processes, using a hybrid cloud model. 

Today, containers make a hybrid approach even more appealing. You get an abstraction layer that gives developers the flexibility and speed of public cloud services, while giving Ops control over security and a single view of all application assets. Containers and a multi-cloud strategy will help ensure portability and protect against vendor lock-in. 

Like the manufacturing company, if you’re serious about transformation, start by rethinking your application development process. Start modestly: Perhaps pick an HR widget to solve a problem that drives people crazy inside the organization. Then show you can scale the answer to solve other problems.  

Misconception 2: One technology will be key to transformation success

You may agonize over one part of the technology portfolio – or even one tool in particular – that you'll use during the transformation. Digital transformations involve many tools, including cloud infrastructure, container management platforms, management and automation tools, mobile, analytics, etc. The key to success will more likely be your DevOps architecture – so take an architecture-first approach.

The key to success will more likely be your DevOps architecture.

This starts with an assessment of what applications you have, what can be retired, what can be automated, and what can be made relevant in a hybrid cloud architecture. What existing and new workloads make the most sense as cloud-native? A key consideration here is the strategic nature of the application, and its ability to be re-built as a stateless, containerized, cloud-native one. 

Hybrid cloud and DevOps go together. Companies that become DevOps organizations known for speed understand the importance of architecture.

The order of what those successful transformers tackle as they move to DevOps looks like this: Philosophy and culture, process, technology. I say philosophy and culture, because while culture matters in DevOps organizations, it’s a living dynamic that starts with a decision, a philosophy: We must change. The decision starts you down the path to a new culture.

Some people wrestle with the first step because they can’t stomach a part of DevOps culture they’ve been told is key. For example, maybe the idea of continuous integration is appealing, but continuous delivery scares them or doesn’t work for their application model. If your release process can’t handle continuous delivery, don’t do it. You can still do agile development leveraging continuous integration, separate from how you choose to do delivery.

SunTrust Banks CIO Anil Cheriyan, who is successfully using cloud and DevOps to help his IT organization and company gain speed, put it this way in a recent interview: “We’ve learned not to get too hung up on the ultimate, 100 percent purist view of what DevOps is, but rather put our focus and energy into changing the culture and driving outcomes.”

Misconception 3: Accelerating the dev cycle is the hardest part

Don’t underestimate the work needed to create and nurture cross-functional teams.

In fact, culture change proves the hardest part of a company’s transformation. How hard your culture change will be depends on the existing IT and company culture, of course. If your IT organization already has a seat at the C-suite table and credibility with line of business leaders, that puts you at a good starting point.

But don’t underestimate the work needed to create and nurture cross-functional and collaborative teams that pull skills from many corners of the organization. Then you have to learn to put up and take down those teams quickly, to solve problems at speed. 

This is why some people feel DevOps actually introduces complexity at the outset. A pilot program can help you find answers without introducing a ton of complexity across the organization.

Some best practices for managing the culture change associated with agile/DevOps:

  • Hire agile experts from outside to bring their knowledge to your teams. Or, get help from a consulting organization that can infuse that knowledge.
  • Don’t worry too much about titles as you hire. Few people have DevOps as a job: You’re looking for problem-solvers. 
  • Remember that your definition of DevOps will evolve with time: The handoff between many Dev and Ops teams has changed in many organizations. 

While the initial view was that Ops took too long to get Devs what they need, Ops teams now use cloud services to deliver that speed. Devs get the speed they want, while Ops guarantees security and consistency. 

In a way, Ops has re-established its relevance. If they can add automation on top of that, Ops experts become heroes to development and the company, supporting rapid application development and delivery.

The will to take transformation all the way

IT leaders should have a sense of urgency about transformation, certainly. But don’t get caught up in feeling hopelessly behind. 

If you see transformation as essential to the health of the business, then you have the will to get transformation done. And you can find the will to take it all the way – including the culture change. 

In the case of the manufacturer that felt so behind on transformation, they carried out their plans to add agile experts to their dev teams. And they won new respect from line of business leaders for the reimagined customer service portal, delivered with speed and flexibility, using cloud services and DevOps methodologies. They tackled DevOps in a wise order:  Philosophy and culture, process, technology.

Now they can bring the same speedy, nimble approach to other business problems.

That’s what transformation is all about, right?

Want more wisdom like this, IT leaders? Sign up for our weekly email newsletter.

Tim Yeaton brings more than 35 years of software and technology management and marketing experience to Red Hat. More recently, Yeaton was CEO at Black Duck Software. Under his leadership, the company experienced more than 30% annualized year-over-year growth, completed 3 major acquisitions, created a joint venture in greater China, and built a worldwide operation with presence in 23 countries.

Comments

Completely well stated. Transformations and strategies are processes, whereas the goals should be overall improvement, and not at all races to completion. Maintain the steady educated focus.

Also, I would have to agree that outside consultants are necessary components (contributors). Choose well.

Paxxon Brown
Advantec Global Services Inc.

Tim, what Nicholas G. Carr meant by 'IT Doesn't Matter' is often misunderstood. If you go back and read his prescient commentary, you'll discover that he actually had the foresight to envision the need for digital transformation that's truly focused on differentiated business outcomes.

Tim,
Excellent insights. I particularly like your observations on culture change. This goes well beyond the CIOs - for businesses to react to the rapid change caused by digital, they must digitize their approach to identifying and developing their highest value digital opportunities. Analog incubation processes don't give you the speed of digital.