A fascinating article by Bill Higgins, the IBM Distinguished Engineer that lead a major project to revolutionise the company’s approach to product development:
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 and Mural, and best-of-breed continuous delivery tools like GitHub Enterprise and Travis CI to continuously 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.
Bill goes on to explain the methodology the project utilised, along with some of the challenges and issues they faced, and the subsequent advantages that were enabled by the new technology. It’s a really interesting read, particularly when you’ve seen many of the challenges that IBMers have faced over the past decade or so. I highly recommend that you take the time to consume the entire article.
However, there are a couple of passages that I wanted to pull out here…
The first is on why ‘tools’ are not the answer. Or rather, why tools alone are not the answer. We’ve all seen this in our work, but the way in which Bill puts it is particularly succinct (emphasis mine):
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.
So organisations don’t just need to provide their staff with great tools, they need to utilise them within new working practices that make the most of the capabilities that they offer.
Secondly, user adoption will likely never be a constant or even growth curve – it relies on a a series of linked but unpredictable events that enables the spread of the new working practices across the organisation. Again, Bill explains this brilliantly:
I think of tools as a catalyst because – if you manage to communicate and execute well – 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), 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.
As I mentioned above, the entire piece is worth your attention.
It’s clear that there is a much-needed revolution taking place inside the walls of IBM’s development and design labs.
From the partner and consultant perspective, the first half of this decade had seen product development and innovation appear to slow to a crawl with products that were heavy, difficult to deploy and provision, and unappealing to users and business leaders. Something needed to be done.
We’re now hearing of new approaches being taken to all aspects of the software (and service) development process, and the benefits are being seen in the planning and delivery of products across the portfolio.
What’s enlightening from articles like these is that descriptions of IBM’s efforts to revolutionise internal collaboration are missing one obvious component… IBM’s own collaboration tools!
Whilst the Notes to Verse migration has most likely improved email, this isn’t where the cultural change is anchored.
Instead of hearing about Connections or Sametime as the tools that are enabling developers to embrace new ways of working, it’s Slack and Mural that are taking the plaudits. Not that there is inherently anything wrong with that – IBM should be using the best tools that can support their business.
However, it’s tough for IBM and its ecosystem of partners and ISVs to be recommending their own solutions to customers when they are not using (or rather exploiting them fully) internally. For example, there’s barely been a mention of Watson Workspace in the press since the announcement last year, whilst IBM has been referencing their use of Slack on a regular basis – and Slack even used IBM as a launch reference for their enterprise solution.
So where does this leave IBM Connections and it’s related solutions? In a 6-9 month lull waiting for these new development practices to evidence themselves fully in the delivery of Connections Pink…
We’re already hearing of massive changes in the build and delivery approach for Pink, and the first element (OrientMe) was shipped in the recent Connections 6 release. It’s clear that this is a sea-change from the glacial pace of development that we’ve seen over the past few years, and I’d pin this at least partially on the cultural changes that Bill Higgins and others have implemented.
My hope is that the improvements delivered in Pink are enough to make the Connections solution effective at enabling true collaboration across teams and between individuals, in such a way that the IBM development teams themselves find it essential for their own use. That will be a true test of its value in modern tech-based organisations.
