In my latest RedMonk Conversation I had the opportunity to talk to IBM Director of Engineering Bill Higgins, about how the company has driven culture change in its software delivery organisation by adopting the most modern tools, platforms and approaches. One big play in turning the super tanker around has been Inner Source. At IBM Inner Source isn’t just about software, it’s also part of the company’s focus on diversity and inclusion in delivering better business outcomes.
IBM is often the biggest customer for platforms that are redefining the infrastructure stack for software delivery. Thus for example, IBM was one of GitHub’s biggest customers early one. Same for Slack. IBM is effectively a testing ground for technology at scale, with gnarly enterprise use cases, and helped these vendors get ready to sell to the likes of Citibank, Vodafone or HSBC. Meanwhile IBM itself is modernizing its operations. Higgins has been at the heart of that.
Transformation involves changes of the entire socio-technical system. Higgins has been driving this change at IBM for nearly a decade. Now he’s applying what he’s learned to new delivery approaches for the company’s AI and machine learning platforms, with the launch of Watson Libraries and big plans for the years ahead. It’s an interesting conversation about process and platform change at scale. Any traditional development shop can learn a lot from the work done at IBM by Bill and his team.
RedMonk has written about the interplay of platforms, tools and culture before. For example my colleague Rachel Stephens had this to say – DevOps: Tools Can Lead The Culture Change. Or in my follow up:
The lesson here is that IT change is never one thing, it’s a complex interrelated set of changes based on people, platform and personnel. But – and here is the kicker – the platforms that enable culture change at scale come first. A pattern is identified, instantiated in tooling, and that enables a far-reaching change in how people work. Tools lead culture change.
It’s interesting to see the ways Bill learned mapped to our research.
One of the primary reasons that we rolled out those new toolchains is that, beyond enabling better practices we wanted to make it much easier for IBM teams to work together. One of the inspirations was the Pixar building, where they deliberately design it so that people bump into each other to foster cross project and interdisciplinary collaboration. But what happened was when we first rolled out GitHub, it actually caused that to happen, but within divisions. So for example within the security division, they worked much better together within say the group handling data or UI. And that’s basically because of Conway’s Law.
Bill is very intentional about learning from others. It was great to hear how he visited Etsy to learn from the organisation about better software delivery and ops, invited by super platinum friend of RedMonk Rafe Coburn.
I visited Etsy a couple of times to see how they worked, and it really blew my mind. It just it just seemed like they were living in the future. And, and so I had this idea that if I could make IBM development operate more like Etsy, it would have a positively transformational effect.
So what about that GitHub choice? Becoming a lighthouse customer of the platform? IBM had a choice to make.
Did we want to kind of go with the enterprise tools of the world that were designed with IBM complexity in mind, or should we go with the tools that people actually wanted to use, like the GitHubs, the Slacks, etc.? And we chose the latter approach because in my experience, you can’t take a product that’s not delightful and retroactively make it come to life, but you can take a product that’s delightful and scale it in terms of number of users and complexity. But it was a major risk because back then there was no GitHub enterprise, so we had to use the GitHub enterprise appliance and at the time it was only qualified for 10,000 users and we weren’t even sure how many users we were going to have inside of IBM. It turned out that the population kind of topped out with about 75,000 people using GitHub.
That’s pretty amazing. A big risk, and not necessarily what you expect from IBM. A similar pattern asserted itself with Slack.
I remember the first time I talked to Stewart Butterfield and Cal Henderson from Slack, they couldn’t imagine in 2014 running at IBM’s complexity. And indeed we had to work really closely on the design of Slack Enterprise Frid so that it could reach, it could work with our complexity both in terms of size but also compliance requirements, etc.. So we took some significant risks of being considerably more advanced on scale.
IBM also needed repeatable methodologies – which is why it adopted the Inner Source Patterns work. Most attempts at a new methodology fail but Higgins said IBM was careful and intentional, and iterated and within about 18 months had built an approach and stack that saw significant internal adoption..It was adopted by 13 IBM products in the first eight months, very different from previous efforts that had seen significant overlap and very little reuse. That work led to the just launched Watson Libraries. Here’s another video we recorded about that.
Anyway here’s the video about cultural transformation at scale, and IBM as an innovator in adopting software for building software – enjoy.
IBM sponsored the making of the video, but editorial control is entirely RedMonk’s.
No Comments