How do you adopt a cultural change within a historically command-and-control environment?
IBM® has been undergoing a major transformation, mirroring the changes many corporations have undergone or will have to undergo to remain relevant and competitive. Instrumental to this transformation has been a change in thought leadership and culture, most notably through the adoption of agile methodology and practices.
See what Sean Reilley of IBM’s Digital Strategy practice says about this transformation.
As VP of the Global Technology and Data Strategy practice, I am responsible for driving transformation strategies for clients across the C-suite. Additionally, I have spearheaded the agile transformation within IBM’s CIO organization, and am intimately familiar with the challenges and efforts needed to adopt a cultural change within a historically command-and-control environment. As part of leading an agile transformation, our role is making people understand what it means to embrace the concept and the behavioral cultural change that comes with it. Often, people start with the methods and tools associated with agile, but to build a solid foundation for cultural change, there are core concepts that need to be understood and put to work first. The following is an introduction, including thoughts, details and advice in terms of what we’ve accomplished at IBM and what I’ve seen with other clients from big companies around the world.
The core concepts
Companies often promote ideas like openness, trust, respect, empathy and courage – all of which are important values most companies would want embedded in their cultures. The issue that can arise with living these values is they are often viewed to be counterintuitive to work. Using openness as an example, many companies and employees tend to hoard information and think of it as a source of power and control. Our goal is to change this mindset.
The basic framework to change this mindset is encouraging transparency and striving to make people feel comfortable. We want to promote the idea of courage – sharing ideas and possible solutions – even if there’s a possibility they won’t work. It’s learning from experiences and trying again. At IBM, we kicked off our transformation with a town hall led by our CEO, demonstrating the commitment to these values with direct support from leadership.
“Committing to the core values of openness, trust, respect, empathy and courage in a visible and inspiring manner is the foundation to a successful agile transformation.”— Sean Reilley, Vice President Global Technology and Data Strategy Practice Leader, IBM
The defining agile principles and practices
Most people hear agile transformation and think it is not for them – that it is too tech specific. To combat this, we have three principles that we focus on as part of the work we do. The first is all about clarity of outcomes and achieving clarity over certainty. Begin when you have enough clarity, don’t wait for certainty. So much time is wasted on charts describing a project before it even gets started, when the reality is items will change the second you’re finished publishing them. Beginning with clarity means focusing on outcomes, or the level of measurable value for your end user, rather than outputs.
The second principle stems from how we want teams to work. We want teams to know what is most important to work on, and how that fits into the bigger picture. This means breaking big problems into small problems, and then working on those smaller problems in a more iterative manner. When you hear people talk about sprints, which are typically two weeks long, it is this same concept of breaking big ideas into digestible chunks. However, it is not just important to break things into two-week cycles, you need to then observe something based on what you deploy. You want to deliver something, observe it and then make a change! This constant tweaking based off of observations and insights is what makes the work teams output noticeably different under agile.
The final principle is all about the team. We want small, co-located teams, and we want them self-directed and dedicated. We want to avoid one person working on 17 different projects at the same time.
It is within the values and principles that the “feel good” initiatives reside. Where it became real for us is in the IBM practices. In some people’s minds, we manipulated the definition of agile since we took our practices from anywhere – software development practices, Kanban, value stream mapping and so on - but they are all part of how we want to work differently.
The main goal is to remove ourselves from any given method and think in a different mindset. When people believe in the process, we can change the team model, the structure in which they work, what people do and how they work. Essentially, implementing a culture change.
Plotting the path
Vision and strategy
One of the most common questions I have received is how to make sure things run smoothly while implementing change. It is important that all teams are working in this new way, but we recognize that on the IT side your mainframe teams probably aren’t going to adapt as quickly as teams working in cloud development. Quite honestly, it’s a byproduct of the mindset. For example, you can go to Silicon Valley and question the startups about their agile program and you’ll most likely hear “What agile program?” They are of the mindset to hire people and let them fit in as and where needed – how they work is just baked into their culture. At bigger companies, this process change can be fought simply because of the nature of the organization. Our goal is to get the entire company energized and excited about this new way of working. Realistically, the idea of daily deployments or hourly deployments probably won’t happen in the immediate near term. What will happen are teams using these practices within their own development cycles and learning what works for them. Ultimately, this will change the way they think and engage with other teams, which can lead to longer-term change, increased synchronization and coordination.
IBM had to challenge its own mindset and make sometimes uncomfortable decisions in the pursuit of a more productive environment, specifically when it was announced that remote employees would be brought back into the office. The goal was to co-locate workers who need to collaborate on a regular basis. The environment we are striving to create cannot succeed if people haven’t met coworkers or managers face to face. There are always exceptions - projects or programs that are short term - and like all things, logic needs to be applied. Success depends on being transparent and consistent.
In addition to physically getting people together, it’s important to consider how you put them together. It’s rethinking the space they work in and striving to create an energetic work environment. Personally, there was a time, due to the location and configuration of my cubicle, that I could physically be in the office and not see anyone at all. Productivity increases when the right people are in the right place – creating an energetic work environment and structure.
Form and scale teams
One of the leadership practices that we introduced was “Listen, Learn, Leverage.” Meaning, are you learning something from the outside? Are you participating in thought-leadership activities and sharing insights? It holds our leaders accountable. It puts into place a new leadership model by which we’re going to assess people. This is important in any organization. If you’re going to implement this big change, then typically the team design should change, but the leadership role and design must change as well. Employees do not want to feel like they are the issue and that leadership is protected or solely on the right course. Everyone is in it together.
We started this process approximately three years ago with roughly 80 executives in the CIO organization. We are down about 50 percent but have also brought in new employees and promoted internally. In terms of leader turnover and direct reports, there’s only one person that was previously a direct report to the CIO still employed. We shook things up.
We are still in the process of shifting the mindset of leadership to create productive work environments, develop talent among our people, set clarity of purpose, remove blockers and then set them free to succeed. About 10 months into this big company-wide push, we redesigned our approximately 500 teams from around the world, but as part of this, we also made a big push with leadership to go through training. We reviewed what it means to be an agile leader, how to lead in this new environment or setting in a way that was different from before.
Within the CIO organization, we re-interviewed “everyone” for his or her job. We formed teams of three, sat down and interviewed executives and potential next-generation leaders. It was our opportunity to essentially put everyone in the right position moving forward. It was not well received by most.
We were very consistent, transparent and upfront in our design principles. When you look at it, I think we created a lot of adoption options because we wanted to increase the level of transparency - and with that comes foresight. There was a great deal of anxiety for many people, especially those not located near the 13 delivery centers, where the concept of co-location would be more difficult.
Traditionally, this type of process would not be announced, it would go through corporate HR. In the end, the decision to be fully transparent was based on preventing backdoor conversations. We tried to soften the blow, but it is a hard thing to soften. There was a possibility that the best and brightest could leave, but we found that the excitement of the new direction superseded it. The group that left was predominantly those who weren’t comfortable with the new direction or who did not want to relocate.
Training plays an important role in collaboration. The awareness of consistent messaging is critical, especially when you are driving transformation and scale. The people who participated in training, especially with team members, were more energized and enthusiastic. You must keep in mind, however; not all people want change. Many people working at IBM had been a part of the company for a long time, or had a mindset based on working from home. From leadership’s perspective, it’s great to bring people together and revel in the energy that creates. To others, this wasn’t what they had initially signed up for. It is the new employees who tend to be most pleased to see the new tools, training and newer environments – so changes like this take time.
As an example of changing culture and overall mindsets, when we initially kicked off training (basic two- hour agile training), I was in the presentation boardroom with another member of IBM. When I explained part of the training process, simply applying sticky notes to a wall, I was immediately told it wasn’t allowed and that we would have to use a white board. As mundane as this example is – it also brings up the point of mindset. Who was it that said sticky notes couldn’t go on walls? They don’t do any damage. It is this learned helplessness in organizations, these unwritten rules that need to be pushed back on. My advice is to stay within legal, ethical and regulatory rules, but beyond that, push the boundaries. Some things are for an actual purpose or reason, but others need to be reconsidered. Just because something “was” done in a certain way, doesn’t mean it must continue in that same manner.
We have slightly touched on the process of handling teams, but the bottom line is we had to completely redo our team model. We had to consider and organize role definitions. We had to make sure we were educating people and accept that it would be impossible to reach everyone. Additionally, there was no incremental budget, we had to carve one out and scale it without adding people. This led us to do online education and create the Agile Academy. We also created a Champions Program to help with awareness which is intended to be a more grassroots effort with people giving some of their time to share and help others learn.
Enable and measure
It can be very tricky when you think about measurements. How do you measure what percentage of the CIO was agile? A lot depends on the definition. There’s no exact tipping point on when it happens, so we tend to measure team composition, team co-location (how many teams are beating our design principle?), and we will track maturity of teams based on a maturity assessment. Ultimately, we want to measure outputs, so we have introduced more MPS scoring and then tie it back to teams. Employee engagement can be difficult, and we measure it twice a year. As part of the transformation, we’ll also measure time to market and speed to deliver.
Enterprise agility – beyond IT
Where you start and how things are handled depend on the mindset of different teams. Much of the change happens on the IT side, with teams that are energized, especially at scale in an organization, and make headway. Then, at some point in the process, they will be unable to take the next step without the business becoming involved and it is then that a product owner role or other prioritization role steps in until the next issue arises. It is the different processes within the organization, items like audit, compliance, regularity, enterprise architecture and so on, that force you, to some degree, into a waterfall model as they require very specific actions. The key proponent is to keep momentum high and remember it is still an IT story even though business has evolved. Your role is to transcend this process, take that mindset shift and link it to pieces that do not touch IT. This is the next level of thinking and where enterprise agility happens.
I’ve seen many companies succeed by taking a small number of teams and placing them in a type of sectioned-off utopian environment – almost as a pilot or test. However, I encourage people to pick something aggressive and that will really touch the core business or a vertical slice of the organization. If you create a nurturing environment that works well sectioned-off, you may not find that same success in the real organization.
You will not see culture change if you address agile transformation as a method deployment. Ensure that you are consistently paying attention to the leadership side to avoid simply sliding back to old habits. Focus on the role of the business and product owner since their involvement in the business shifts in this environment.
People often ask me if I am trying to change the culture of IBM. The idea is that we want to change people’s “mindset”– and culture change is a byproduct. It’s not something that you can just set out and do overnight. It’s what we are striving to do, whether it’s called agile or enterprise agility, the wording itself isn’t what is important – it is what we are trying to drive from a mindset and new prospective.
Building a better business
Adopt a cultural change in a command-and-control environment.
Innovating with emerging tech
Gain business value by adopting emerging technology.
Creating the agile enterprise
Change the way your company works and its ability to sustain change.