5 Ways To Bring Change to Your (Big, Slow-Moving) Organization
If your organization can't change with the times, technology and marketplace, it's not going to last. That’s a simple — and largely accepted — notion, but it's easier to talk about keeping up with the Joneses than it is to actually do it.
Overcoming inertia and legacy systems is hard — especially in large organizations, or organizations that have been around for a long time, and have built up a lot of technical debt. Organizations like these likely also have a lot of protection around technology choices and processes.
Gareth Rushgrove, now a senior software engineer at Puppet Labs, has a lot of experience making changes in traditionally slow-moving environments. In a recent podcast, he spoke to us about his time working for Government Digital Services in the U.K., and how his team created and scaled a central publishing platform for all U.K. agencies. I’ve pulled out some of the themes from the talk below.
Build on success, lead by example — and prove you're not special
One of the hardest parts of making change in a large organization might be convincing people that it's possible. Gareth touched on how to extend changes from your team to the wider organization:
"The best way of building momentum, of convincing people we were right, was just by doing it, because not everyone believed what we were doing was possible. I think once we got past a certain point of demonstrating it was possible by doing it, it then became about softer skills, around convincing people that how we were able to do it wasn't because we were hugely special. It was about convincing people that the way we were working was the thing that was allowing us to do this work. Once people bought into that, it was convincing them that they could do that as well.”
Organize your teams logically, not by function
This may not always be an option for every project, but look for opportunities to work in smaller, inter-departmental teams on a shared goal.
"Most of the product teams might be nine to 10 people at most; they wouldn't be all designers, or all developers, or all user research people, or all content designers. Depending on the domain that the product team was working in, it would be a mix of those things. Rather than a much more traditional breakdown with everyone in separate teams by discipline, our structure was very much teams centered around products. It forced people to work together much more efficiently and effectively, and to deal with the day-to-day small issues very quickly, which lead to lots and lots of incremental improvements, rather than hoping everything comes together at the end."
Prepare to conquer the barriers to change
Some barriers are universal, and some are much more likely to come up in a large, risk-averse environment.
"Part of the obstacles are just if the organization has been there a long time — and obviously the U.K. government has been there a long time — it's already done a lot of the things we were doing. Probably several times, through different generations of technology, different generations of people, different generations of organizational structure. And there can be a sense of, 'Oh, but that's not how we do things.' Making the room to demonstrate that new ways of working, or new approaches, or new technology, actually is viable in this environment, can work. One thing we ran into a number of times was this idea that government was ‘different.’ In reality, what we were doing was often applying good practice from the technology industry as a whole, and coming against this idea that that wouldn't work because government was different. I've seen similar things in other large organizations that have their own center of gravity, it's that mental barrier more than anything else."
Get your ideas in front of the public early and often
User feedback is critical to the success of your products, especially in the early stages.
"Getting things out into the public earlier is crucial. Rather than taking two years to build something quite complex, actually ship early, ship often. Ship something — that's maybe not quite finished, not ready for everyone yet — to a smaller audience, or to a private group. Do user research up front, get in front of people earlier and often. Once you can get into a public state, a beta release, then really pay attention to the numbers. How are people using it? Where are people having problems? Getting something into the public domain was Day 1, that's not the end of the journey, that's the start of something. It's only at that point you can really start iterating and learning from usage."
Share your metrics
Metrics are important, but aren't worth much when people don't have access to those measurements.
"One area we were really focused on was the performance platform, which was some work some colleagues did. It had all the key performance indicators for a lot of the projects that we were working on, but also that the rest of government was working on, and making them very public. It wasn't taking data and locking it behind a special document only execs could read, or only collecting data occasionally. It was saying, ‘Let's make this real-time information and let's make it available to everyone, not just inside the organization but outside the organization.’ That helped with us being transparent, and it helped with people being able to hold us to account. They could point to our data and question whether we were doing the right thing, which is a really good incentive for doing the right thing, and for reacting to things where you're wrong."
- Listen to our full conversation with Gareth (it's got tons more good stuff we couldn't fit here)
- Read the uk.gov design principles
- Download the 2015 DevOps Report, which amplifies these findings and adds a lot more about the relationship between DevOps, IT performance, and overall organizational performance.
- See more stories of effecting positive change or reach out to firstname.lastname@example.org to tell your own