Most companies don’t realize the amount of work required to fully transform their approach to creating and caring for software. Scaling up the improvements learned and put into place by your initial teams relies on building trust and understanding in the overall organization. For whatever reason, most people in large organizations are resistant to change and, what with the frequent introduction of process improvement programs, skeptical of the flavor of the week of the syndrome. A large part of scaling up digital transformation, then, is internal marketing. And it’s a lot more than most people anticipate.
Once you nail down some, initial, successful applications, start a program to tell the rest of the organization about these projects. This is beyond the usual email newsletter mention, often quickly leading to internal “summits” with speakers from your organization going over lessons learned and advice for starting new cloud native projects.
You have to promote your change, educate people, and overall “sell” it to people who either don’t care, don’t know, or are resistant. These events can piggyback on whatever monthly “brown-bag” sessions you have and should be recorded for those who can’t attend. Somewhat early on, management should set aside time and budget to have more organized summits. You could, for example, do a half day event with three to four talks by team members from successful projects, having them walk through the project’s history and advice on getting started.
This internal marketing works hand-in-hand with starting small and building up a collection of successful projects. As you’re working on these initial projects, spend time to document the “case studies” of what worked and didn’t work, and track the actual business metrics to demonstrate how the software helped your organization. You don’t so much want to just how fast you can now move, but you want to show how doing software done in this new way is strategic for the business.
Content-wise, what’s key in this process is for staff to talk with each other, about your organization’s’ own software, market, and challenges faced. I find that organizations often think that they face unique challenges. Each organization does have unique hang-ups and capabilities, so people in those organization tend to be most interested in how they can apply the wonders of cloud native to their jobs, regardless of whatever success they might hear about at conferences or, worse, vendors with an obvious bias. Hearing from each other often gets beyond this sentiment that “change can’t happen here.”
Once your organization starts hearing about these success, you’ll be able to break down some of the objections that stop the spread positive change. As Amy Patton at SPS Commerce put it, “having enough wins, like that, really helped us to keep the momentum going while we were having a culture change like DevOps.”
Winning over process stakeholders
The IRS provides an example of using release meetings to slowly win over resistant middle-management staff and stakeholders. Stakeholders felt uncomfortable letting these detailed requirements evolve over each iteration. As with most people who’re forcedencouraged to move from waterfall to agile, they were skeptical that the final software would have all the features they initially wanted.
While the team was, of course, verifying these evolving requirements with actual, in production user testing, stakeholders were uncomfortable. These skeptics were used to comfort of lots of up-front analysis and requirements, exactly spelling out which features would be implemented. To start getting over this skepticism, the team used their release meetings to show off how well the process was working, demonstrating working code and lessons learned along the way. These meetings went from five skeptics to packed, standing room only meetings with over 45 attendees. As success was built up and the organizational grape-vine filled with tales of wins, interest grew and with it, trust in the new system.
The next step: training by doing
Scaling up from marketing activities is often done with intensive, hands-on training workshops called “dojos.” These are highly structured, guided, but real release cycles that give participants the chance to learn the technologies and styles of development. And because they’re working on actual software, you’re delivering business value along the way: it’s training and doing.
These sessions also enable the organization to learn the new pace and patterns of cloud native development, as well as set management expectations. As Verizon’s Ross Clanton put it recently:
The purpose of the dojo is learning, and we prioritize that over everything else. That means you have to slow down to speed up. Over the six weeks, they will not speed up. But they will get faster as an outcome of the process.
Scaling up any change to a large organization is mostly done by winning over the trust of people in that organization, from individual contributors, to middle-management, to “leadership.” Because IT has been so untrustworthy for so many decades — how often are projects not only late and over-budget, but then anemic and lame when finally delivered? — the best way to win over that trust is to actually learn by doing and then market that success relentlessly.
This post is an early draft of a chapter in my book, Monolithic Transformation.