Four “knows” about driving transformation

Perhaps you’re a CIO managing the transformation to a DevOps environment. Or implementing new collaborative business models with business stakeholders. Or reorganizing your IT department into a business-centric IT-as-a-Service model.

The word “transformation” is synonymous with “radical change,” and rightfully so. It’s an extreme and thorough difference from the accepted or traditional form of business activities. It’s disruptive. It’s loaded with complex challenges often fraught with intense emotions. And it takes place outside people’s comfort zone. Would you like a formula for success in driving transformation in your organization? Here are four things you need to know. 

1. Know your company’s business and the scope of the change.

You need to understand the business well enough to go through a broad rethink of the approach to business processes. The transformation journey will take your company through a fundamental shift in strategic intent. Accomplishing the transformation will require wide-ranging systemic shifts as well as changing policies and philosophies. 

We need look no further for an example than when American Express transformed the slow waterfall software development approach to agile and DevOps in its Enterprise Growth business about four years ago. Neal Sample, who is now president of Enterprise Growth, was at that time the CIO who led the transformation. I spoke with him about how he handled the changes.

Agile and DevOps are business processes, not just technology delivery. So the scope of the transformation required changes on three fronts: people, process and technology. 

Neal recalls that one of the biggest challenges was making sure everyone – from the software development team to the compliance and legal group, marketing and the C-suite – was on board with the transformation, understood its potential and understood they would have to go on the transformation journey with the IT team. 

The scope also included a complex challenge because Amex had just recently acquired a startup, Revolution Money, and was in the process of integrating it from a technology perspective and a product perspective. Sample describes it as a tale of two cities. The startup was obviously young, used the agile development practice and had continuous delivery. Amex was more than 160 years old at the time and using a sluggish waterfall practice in a fairly conservative world. 

The transformation charter included unlocking the full potential of that acquisition while at the same time updating and modernizing Amex’s software stack and practices for some legacy products that had been around for decades. 

2. Know how to design a phased approach to disruptive change.

Don’t present your technical team and business community team with a one-year or two-year road map for the transformation journey. You will need to build credibility and morale in both teams and also minimize the impression of disruption. An effective way to do this is to break up the journey in a series of manageable phases with three-month time frames. Each phase should have realistic goals that the teams can not only accomplish but also exceed in the time frame.  

At Amex, Sample also did a preplanning phase where he sought to understand the journey, laid it out and understood what he would do in each phase. 

In phase one, he educated the organization and started laying a foundation for changes in policy, process and toolsets. He also slowed down throughput to accommodate the transitions. In phase two, the teams started using the new tools, policies and processes and then refined them. The goal by the end of the second three months was to have caught up to the quality level and throughput level that they had prior to the transformation. In the third phase, the goal was to accelerate processes and increase productivity. In phase four, they refined processes to get up to the new standards they wanted to achieve. 

3. Know how to pare back the expectations.

Expectations around agile and DevOps are that development will be cheaper and faster and achieve higher quality. But transformations don’t happen overnight, so you as CIO need to correct those expectations as to when the capabilities or capacity will be available. Make sure the business knows you won’t have the capacity during the first phase to make changes that will materially impact the business at the top line. The transformation could put the ability to release customer-facing features at a standstill or a rapidly diminished pace for at least a quarter.

Sample explains that their IT team continued working at the same pace, but they slowed down throughput for the first three-month phase because they needed to spend time doing a lot of cleanup work, componentization, building out APIs and other tasks of getting into the swing of agile and DevOps. 

4. Know how to achieve the transformation without employees feeling threatened.

As Sample did in his preplanning phase, you need to spend time to understand what the journey will involve. Certainly if your organization is switching to a new business model, your existing IT staff will undergo changes and likely will feel their jobs are threatened by the change. 

Sample wisely avoided a wholesale change-out of the IT team. He worked at several companies in Silicon Valley and had experience in helping companies stay nimble and react quickly to changing market needs. He understood what he needed to bring for the new environment. It required establishing a strategic intent regarding talent and laying out a clear path. 

Under his leadership, Amex made a significant investment in training the existing staff and seeded the team with talent from companies like Netflix, Yahoo!, eBay and Zynga – people that had previously worked with agile and DevOps processes.

Thus, he seeded his organization with just enough talent to show them the way but didn’t need to replace or do wholesale changes. So he was able to capture the hearts and minds of his organization, show them a better way and not threaten them. He was able to bring them forward and uplift his team rather than replace them. 

It was a bold journey that faced numerous obstacles; but because of the four “knows,” Sample led the transformation to produce measurable success in just nine months. And after 18 months, their productivity approximately doubled with no increase in investments and with better quality. I’d say that’s a huge success story.