How IBM’s agile, design-first approach increases employee productivity

During my first conversation with Fletcher Previn, IBM’s CIO, he told me that his approach to IT is to “lead with design.” I followed up for a full interview and learned that key to Previn’s “design first” philosophy is embedding design and user research deeply into IT, organizing into small nimble teams, defining the metrics that matter, and driving agile at scale. 

As CIO of IBM, your philosophy is to “lead with design.” What do you mean by that?

Fletcher Previn: Our mission as an IT organization is to create a productive environment for IBM employees. We do that by leading with design to drive simplicity and ease of use. I believe that the state of your IT landscape is a daily reflection of what you, as an IT organization, think and feel about your employees. So, we’ve made visual and user experience design teams a critical part of IT. These teams act as a cross-functional department that apply user experience (UX) expertise into everything we do, and they create the end-to-end user experiences our employees interact with every day.

IBM

We’ve embraced design as a core component of our agile approach. While traditional agile does not have a design requirement for the team, our approach does. But just hiring a bunch of designers alone will not lead to delivering good design. You also have to have the right feedback loops in place and a commitment to continuous improvement. Yes, you need to hire people who are passionate and committed to design; but you also need adoption-based metrics because usage, adoption, and advocacy are the ultimate arbiters of success.

In 2018, employees cannot experience a disparity between technology in their personal lives and technology at work. Our job in IT is to make sure our working environment reflects IBM’s commitment to our employees, and to good design.

Can you give an example of how good design impacts the employee experience?

Think about all of the different touchpoints that an employee experiences in a large enterprise: a web app, a mobile app, emails, and even a sign that hangs on an elevator. All of these touchpoints are designed by UX people who have been involved in creating that capability from inception to delivery.  

Through our design teams, we’ve done a lot of work to clean up our system-generated emails and to build mobile apps that make it easier to join conference calls, do expense reporting, book travel, and perform many other kinds of tasks. When we deliver solutions to our employees, we have a pretty simple litmus test: Are we making things easier for IBMers? Because every minute our employees spend grappling with an IT system is a minute they are not delivering value to our customers.

How are you using agile at IBM?

Agile, as we have implemented it at IBM, is a little different than a traditional agile approach. For us, the 12 practices of agile are bookended by organizational design on the left and metrics on the right — creating the most comprehensive agile program possible.

Let’s start with organizational design, and walk through a piece of discovery work. If you are a CIO, and you put all of the things that people are responsible for on a board, you can start thinking through which functional roles or capabilities belong together. You might, for example, find that you have mobile development emerging in different parts of the organization. Should those be brought together into one group? Those questions form the basis of how you organize.

We’ve adopted a modified Spotify model, where each one of my direct reports is a domain leader, and people with similar job functions form guilds and coordinate their efforts across the domains. Whatever model you choose, the right implementation of agile de-layers the organization, increases throughput and velocity, pushes decision rights down to the teams, improves quality, reduces recovery time, and, ultimately, creates happier more engaged teams.

How do you decide which solutions require an agile approach?

We use agile for almost everything we do at IBM. We do not believe in a “two-speed IT” or “run and transform” model. This construct can create environments where some groups — infrastructure and legacy teams in particular — are not expected to drive change, and new development teams get to innovate and do the fun things. At IBM, every team, including our infrastructure, mainframe, and networking groups, are expected to continuously transform.

For example, the infrastructure teams are using software-designed networking to transform how they build networks. It comes back to organizational design. Having agile teams, where people who understand networks and people who understand software development work together side by side, we can drive real infrastructure innovation.

While our agile journey started in IT, we have seen such compelling benefits that we are scaling agile across all of IBM. We are applying agile more broadly across the business, and we are seeing similar outcomes in every department and function. 

What advice do you have for CIOs looking to optimize their agile approach?

Put the right organizational structure in place: A complicated organizational structure manifests itself in complex solutions. Simplify the organizational structure and how the work gets done, and you get simpler solutions that are easier to use.

Hire great people: I’m looking for people who are kind, passionate about their craft, and dedicated to IBM’s purpose.

Measure your results: On a team basis, we measure all the agile metrics that you’d expect, including velocity, quality, and throughput. But if I had to pick one key metric to focus on, it would be Net Promoter Score (NPS). You can measure NPS down to the squad level, manager level, or even individual contributor level. We NPS ourselves heavily, and our stakeholders provide NPS feedback on the products and services we deliver to them.

Get the support from the top down: Our CEO is the biggest agile champion in the company. When you have that kind of support, don’t make it optional and you can start big. For others who may not be as fortunate, my advice would be to start with a specific team, demonstrate that agile isn’t only for innovation teams and then continue to scale out as you build more trust with the business stakeholders.

About Fletcher Previn

Fletcher Previn is CIO for IBM, where he creates secure global IT for a workforce of 400,000-plus IBM employees and contractors. Previously, he was vice president of workplace as a service, as well as director of workplace and collaboration solutions for the company, which he joined in 2006. Previn holds a BA in political science from Connecticut College and various technical certifications.

Read more about CIO leadership challenges: