Tools as a catalyst for culture change
Over the past two and a half years, I’ve led a project at IBM that deployed a new set of tools to help improve the company’s product development efforts. What is the benefit of providing better tools to employees? A first answer is that it helps increase employee productivity. While this is true and part of the answer, it is much too narrow. The broader answer is that giving employees great tools is an excellent way to concretely affect positive culture change.
In this article I’ll summarize what the team did and what I learned.
A quick summary of the project
A few years ago, my part of IBM shifted its software delivery model from on premises to as-a-service [1]. To do this well, you must be able to rapidly evolve your service based on your changing understanding of user needs, while ensuring excellent operational quality – always on, always fast, always secure. Teams that excel at this tend to use a set of practices that we capture under the umbrella term of “continuous delivery” [2].
In late 2013 and early 2014, I led a project called “IBM Service Engage” that eventually (after I left) grew into the IBM Marketplace [3]. One of the reasons the Service Engage project was successful was because we were good at continuous delivery, having studied and emulated how the best continuous delivery companies like Etsy and Netflix worked. A critical contributor to our success was that we built a good, modern continuous delivery “toolchain” that included a good git-based source control system, a good continuous integration engine, a good continuous deployment system, and good monitoring and alerting tools.
When our CEO Ginni Rometty hired Jeff Smith as IBM’s CIO, with the mandate to help IBM achieve better business and technical agility, I proposed to Jeff that we provide the entire company with a great continuous delivery toolchain that fostered radical collaboration across disciplines. Jeff agreed and for the past two and a half years, that’s what my team and I have been working on.
We chose and deployed best-of-breed collaboration tools like Slack, Mural, and ZenHub, and best-of-breed continuous delivery tools like GitHub Enterprise and Travis CI to continously deploy their services to the IBM cloud. About a year into the project, we’d seen some amazing uptake, but we’d also realized that providing great tools was a means to an end, but not the real goal.
A fool with a tool is still a fool [4]
About a year into the project, we realized that we had three distinct internal market segments:
- One set of users were elated to have access to tools like Slack and GitHub, which they had already used successfully in previous jobs and/or at universities. These folks jumped onboard, saw an immediate performance and happiness boost, and were champions for the tools in their respective parts of the company.
- Another set of users weren’t familiar with the new tools, but became curious about them and gradually adopted them after witnessing the improved performance and happiness of the early adopters. This group tended to struggle a bit in their adoption, because they tended to use the tools “wrong.” I’ll have more to say on this in a moment – it’s critical.
- The final set of users either ignored or actively fought against adopting the new tools, as they preferred sticking with the tools that they knew.
By now, some of you have probably realized that we were simply observing the normal “diffusion of innovations” adoption curve.
Hindsight bias says “this should have been obvious”. Fine. What I believe wasn’t obvious then – and remains non-obvious now – was that tool adoption was not the real problem to solve. The real problem to solve was getting teams to discover and adopt the modern practices that the tools enabled.
The tools we picked all had good surface usability – attractive UIs, good performance, etc. – but the magic was in the new workflows and collaborations that they enabled. For instance, you can use GitHub as just a more attractive Git UI, but it becomes magical when you fully buy into its pull request workflow to support peer reviews and social coding across teams. As another example, you can use Slack as simply a more attractive instant message client, but it becomes magical when it becomes the cockpit for your human colleagues and continuous delivery tools to collaborate on updating a production application.
The magic is in the new, better practices that the tools enable. A tool is a vehicle for practices. Practices directly shape habits and tacit assumptions. Habits and tacit assumptions are the foundations of culture.
We realized that our early adopters typically had learned both the tools and the better practices in some previous context. The laggards were, well, the laggards. We decided to focus our energies on the early majority, who wanted to do better, and saw the tools as key ingredient for this, but were missing the critical insight that the tools were the vehicles for new, better practices which they would need to learn and ultimately master.
With this new understanding we developed and adopted a new mission statement:
We help teams learn, adapt, and apply modern product delivery practices in order to deliver great outcomes. We use technology to drive the adoption and mastery of modern practices at scale.
Tools as a catalyst for culture change
From the last section, one might draw the conclusion that “tools are an implementation detail.” This is completely wrong. Tools are critically important for many reasons, but especially these two:
- Some tools are much better than others at supporting the right practices
- In the quest to change culture, providing the right tools is a great concrete first step
Hopefully the first bullet is obvious by now. To explain the second bullet, I’ll share a fun and analogous story.
A friend of mine is CTO at a company that is respected in the industry for its healthy culture and excellent modern continuous delivery practices. A few years ago, his boss, the CEO, walked into his office and posed an unusual question: “I’ve been asked to spend 15 minutes with President Obama to provide recommendations on how he should fix HealthCare.gov. What would you say?” This was right after the original launch that most observers had considered a disaster. There were a myriad of problems, and many of them ran deep – to the culture of the organization creating the system.
My friend said “Suggest to President Obama that the team should deploy to production every day.” When I first heard this story, I laughed, because it seemed so simplistic – especially when you’re talking to the leader of the free world. But as I thought more about it, I came to understood the genius of it. It is genius, because it is a very concrete, measurable recommendation that you can only achieve if you solve hundreds of problems, small and large, ranging from technical, to practice, to policy, to culture. If he had instead said “Let’s talk about changing your culture,” it might have resulted in a stimulating and thought-provoking 15 minute conversation, but would have failed to have any concrete impact.
Deploying great tools to your company has a similar, concrete effect, that acts as a catalyst for positive culture change. It’s all well and good for a leader to stand up and say “we want you to adopt DevOps culture” or “we want you to become great at continuous delivery”, but these statements are fuzzy and hand-wavey. It’s a very different thing for a leader to say “you now all have access to Slack, GitHub Enterprise, ZenHub, Travis CI, and Safari Books Online to support your adoption of DevOps culture and continuous delivery.” I think of tools as a catalyst because – if you manage to communicate and execute well [5] – you can set off a positive chain reaction:
- Your top folks think “wow, our leaders are clueful, and they’re serious about transforming our culture.” They jump on board and immediately experience and demonstrate better performance and better morale. They view you as a clueful leader that they will trust vs. an unhelpful pointy-haired boss. They also become your champions and sources of local support with later adopters.
- The next set of folks see the improved performance of the early adopters and say “I want some of that!” If you help frame the problem as adopting modern practices, and make it clear how the tools support these practices, this group will ultimately change behavior, and experience the benefits of this change with their own improved performance and happiness.
- The more productive and happy employees do a much better job recruiting great talent from college and industry, as they rave about their excellent set of tools, their modern ways of working, and their clueful leadership.
- As more long-time and new employees gain mastery of the tools and the practices, you hit the diffusion curve’s critical mass point (the yellow line’s first inflection point in the diagram above), where your early adopters and early majority become a self-sustaining force for the diffusion of the practices and tools to everyone else, allowing you to move on to the next whitespace where you can add unique value.
Some important details
It’s hard to compress two and a half years of experience into an article, but what I described above is the gist of what I learned. Before closing, I thought I’d share some important details that support the above approach.
Picking the right tools
We did not perform thorough analysis to select the early tools, yet they’ve been wildly successful inside IBM. Did we get lucky? Nope – the secret is that we had good taste in who we followed [6]. One major lesson I’ve learned from our IBM CIO Jeff Smith is “find what best looks like, and learn from it” [7]. We looked around the company and around the tech industry for people who we thought were “doing it right” and simply asked them what tools they were using and why. Some tools and practices kept coming up again and again, with compelling success stories, so we went for those.
Two years into the project, with some more experience under my belt, I distilled a balanced scorecard based approach to provide a more rigorous set of assessment criteria, in support the “find what best looks like” principle [8].
Building an “army of awesome”
We discovered very early in the project that we could leverage diffusion effects to accelerate adoption and amplify our small team’s impact. Specifically, we identified key communities and opinion leaders within those communities, who would advocate for our tools and act as local sources of support. One such community was the IBM front-end development, or FED community. This was a thriving community of practice that was populated by top developers from around the company who cared deeply about designing and building delightful and modern web experiences for their respective products. The leaders of this community immediately loved our project because we made it safe and possible to use the same modern tools for their day jobs that they were already using for their non-IBM nights-and-weekends projects.
As an intra-IBM community they shared best practices with each other, and educated newer community members. Within their particular business units, they advocated for the new tools and practices, and became existence proofs that it was possible to use these tools and practices within IBM, even if it was quite different than what had come before.
Fostering continuous learning
One risk of a strong internal community is that you may become cut off from improvements in the world outside your company. One of the underlying premises of Jeff’s “find what best looks like” principle is that in a world with more than 6 billion people, there’s inevitably someone doing whatever you’re doing better than you. As a leader, you should recognize and reward your employees for adopting and promoting better ideas from outside your company. Also, it’s powerful to put your money where your mouth is and invest in your people’s external learning, by funding their travel to visit other excellent companies and investing in their continuing education. One of the investments I’ve been most happy with is our subscription to Safari Books Online, which gives our employees access to a vast library of excellent books as well as the ability to watch replays from all O’Reilly conferences, where top industry experts share their most recent insights and practices.
Working with senior executives
Since none of this is free, it’s also important that senior executives from around the company buy into what you’re doing. We had the fortunate structural advantage that our most senior stakeholder – CIO Jeff Smith – had both a passion for driving positive culture change and a mandate from the top [9]. But mandates only go so far – you also need buy-in from other senior stakeholders. We learned that just as it’s very effective to have champions at the grassroots level, it’s also very helpful to have champions in the executive ranks. After a year or so, we formed very effective relationships with senior leaders like David Kenny and Beth Smith from Watson, Rob Thomas from Analytics, and Arvind Krishna from Research and Hybrid Cloud. These folks saw the value, and became key partners whose advocacy for the tools and methods gave air cover to the early adopters and early majority, and helped to pull along the later adopters. They also acted as a sort of board of directors, sharing their wisdom and perspective with us to guide the path forward and course correct when necessary.
In summary
As the saying goes, culture eats strategy for lunch. But “changing culture” is not directly actionable. However, by picking and deploying great tools, and guiding a community to embrace and teach modern practices, you can start a positive chain reaction that results in meaningful and significant contributions to positive culture change.
Footnotes
[1] If you’re not familiar with software delivery, here’s an analogy. Netflix used to provide movies by physically mailing DVDs to your house, and then you’d play them on your DVD player. This is like on premises software delivery – you download it, you install it, you run it. These days Netflix provides movies by making them available on-demand, streamable over the Internet. This is like as-a-service software delivery – you never download anything – you run it over the Internet.
[2] To learn more about continuous delivery, Jez Humble has a web site that provides great insights, as well as links to several great books he has written on it.
[3] For a description of the early days of the Service Engage project, you can read my article “Working like a startup at IBM” on O’Reilly Radar.
[4] Credit for this aphorism to the great Grady Booch.
[5] Good execution of deploying new tools at scale is actually very difficult. I have some scars to prove it! Please don’t take the positive tone of this article to imply that we got everything right. We made plenty of mistakes along the way and these could form a whole other article!
[6] I shared the origin story for one of the early tools – Slack – in my Medium post “Listen to the wild ducks: How IBM adopted Slack.”
[7] Jeff talked about “finding what best looks like” and several other of his key leadership and transformation techniques in this 2016 CIO Leadership Exchange talk. If you liked this article, I highly recommend listening to Jeff’s talk, since many of his ideas influenced our work.
[8] This scorecard has three main set of criteria: capability, operational quality, financial sustainability. Capability includes things like “improves employee productivity and happiness”, operational quality covers things like availability, performance, and security, and financial sustainability talks about TCO at scale and how to offset new investments with take-outs.
[9] The project was originally co-sponsored by Jeff and IBM Design General Manager Phil Gilbert, who has a similar change mandate in the realm of design, as described in this excellent New York Times profile.
Bill Higgins is a Distinguished Engineer at IBM based in Raleigh, North Carolina, USA.
