For years, I’ve focused my efforts on sustainability in software delivery practices. I asked the question, again and again, “How can we eliminate unnecessary drama and reduce the need for heroics, so that doing great things doesn’t come with such a high human cost?”
The answers I found were: shift left testing, continuous integration, and continuous delivery. These “new” ways of making software made sense to me because they significantly reduced the cost of making change at scale, whether measured in time, talent, or treasure. Sustainability, it turns out, is really about becoming more efficient at adapting to change.
Now the world is calling on us all to rapidly adapt to challenging circumstances in a whole new way. Should we abandon sustainability and efficiency and just “push through” or “suck it up?” Should we re-embrace heroism and accept more burnout as the inevitable cost of survival? No. Instead, we need to re-visit how adaptability is truly achieved. My hypothesis is that many of the same tools and practices that make modern software delivery sustainable and efficient are exactly what our organizations need to achieve greater adaptability.
In this post, I’ll lay out three examples of organizations that have trained and tooled up to go beyond sustainability and efficiency to achieve adaptability. All three focus on “go” instead of “no” by empowering local teams to take informed action through experimentation. First, let’s start with a brief history lesson.
Change is Trending, Still
Nearly a decade ago there was broad consensus that change, not stability, was the new normal. It was becoming clear that success would go not to the largest incumbents, but rather to those teams that could most rapidly adapt to change, whether that be a change in business plans, a change in customer preferences or a massive shift in the entire marketplace.
I’ve written and recorded talks elsewhere on being able to read and act on signals of change and experiment to define the path to success for your organization. What tends to surface over and over again is that the ability to mobilize, or take effective action, relies upon being really good at making sense of real-world data. Data, not opinions, and experiments, not surveys, are what put teams into a virtuous feedback loop towards greater success.
Adaptability Through Local Team Autonomy at Whole Foods
In 2011, Martin Reeves and Mike Deimler wrote a piece for the Harvard Business Review on the theme of managing uncertainty (aka change), titled Adaptability: The New Competitive Advantage. In that piece, they said companies “need to create environments that encourage the knowledge flow, diversity, autonomy, risk-taking, sharing and flexibility on which adaptation thrives.”
They also specifically called out the need for flexible structures that disperse decision rights out as close as possible to where customers are impacted by what you deliver. The example they gave was from Whole Foods, and while you might not think software delivery has a lot in common with working the floor in a brick and mortar store, consider how well this approach puts decisions and incentives close to the customer:
- Each store has ~8 teams
- Each team, not national buyers, make decisions about which products to carry
- Teams have veto rights over new hires
- Teams are rewarded for their performance, with bonuses based on store profitability over the previous four weeks
In order for each team to move faster and to capitalize on the insights at a local level (with the least dilution from groupthink or bureaucracy), Reeves and Deimler recommend that organizations replace rigid hierarchy with “simple, generative rules to facilitate interaction, help people make trade-offs and set the boundaries within which they can make decisions.” We see this perfectly in this Whole Foods example: the power (and incentives) to directly impact product content and customer experience are focused at the local level, not spread across multiple teams around the nation or concentrated in a senior management layer.
Hiring for Adaptability, Bias for Action at Netflix
Let’s move to a technology example that more directly represents the challenges facing organizations who are planning for or undergoing a digital transformation: Netflix. You might already be familiar with Netflix’s approach, which is to hire top-notch talent, give them a small list of core values, and focus on giving them tools and data and getting out of their way so they can produce.
While many organizations decide to add rules and increase structure as they grow, Netflix intends to “increase employee freedom as we grow, rather than limit it, to continue to attract and nourish innovative people, so we have a better chance of long-term continued success.”
Onboarding at Pinterest: Informed Action Training on Day One
But hey, we can’t all be Netflix, pay salaries at the top of the range to attract top talent, and send folks off with a 6-month severance to look elsewhere when they don’t fit in. Maybe it’s more about how we empower our teammates after they are hired. Have a look at what Jeremy King, SVP and Head of Engineering at Pinterest had to say when asked, “Do you have to hire different kinds of people to support an experimentation-driven culture?”
“I’m not sure we hire differently, but it does require a different kind of onboarding. Companies like Facebook, Google, and Pinterest are famous for their long onboarding processes. I have friends at Facebook, where new employees spend two full weeks going through data training so that everyone understands what kind of data is available, how to access it, and how to best use it to support decision-making. That kind of training requires a huge investment.”https://hbr.org/2020/03/productive-innovation#the-power-of-these-techniques-is-only-getting-stronger
Write Queries, Not Tickets, to Scale Informed Action
I like Pinterest. I’ve been in the building a couple of times and was fortunate enough to present a talk and share a lunch there with their experimentation team. The entire organization believes in data: in just the six days before Jeremy King started at Pinterest, 65% of employees had done a query in their big-data system. Contrast that to a center of excellence approach, where teams must open a ticket and wait in line for a scarce resource to pull data. Self-service scales informed action far faster than “growing the data science team” ever will. I’ll talk more about the value of putting data over opinions in another post. For now, I’d like to share one last story about focusing on “go” instead of “no” — this one comes from Pinterest as well.
Go Now. Confirm After: Holdback Experiments
At some companies, product teams must prove that a change improves the customer experience before they can push that change to the full user population. At Pinterest, they flip this idea on its head at times. When a team has high confidence that a change will be for the better, they let that team take the change to 99% of the users right away. They still experiment, but they do that by keeping a “holdout” population (the remaining 1%) on the legacy implementation. It’s still informed action, but the emphasis is on “go” rather than “no.” They still respect the data and place value in verifying their opinion with experimentation instead of just blindly moving on to the next project.
Adaptability Requires Experimentation
Adaptability doesn’t come from blindly charging ahead faster. Rather, adaptability requires that your individual teams, who are closest to the customer, have the tools and incentive to notice the need for change, experiment in order to find a successful way to implement that change, and safely push out the successful implementation at scale.
As we all look for ways to improve the odds that our organization will not just survive but thrive in the COVID-19 and post-COVID-19 world, we’d do well to ask whether we are doing our part to ensure that teammates can mobilize, can “go” forward to experiment with new ideas, and roll those ideas out, with the least friction. I recorded a 27-minute video about this recently, called Business Continuity Planning: Rethinking Your Release Process.
Making it easier to say “go” with greater speed and less risk, while keeping track of how well things go, is exactly what Split was built for. Teams that have adopted Split’s combination of feature-flag powered progressive delivery, release monitoring, and experimentation engine report that it streamlines their release process, reduces risk (and drama) of pushing changes, and adds rigor, speed, and scale to their experimentation efforts.
Grab a free Split developer account to see how easy it is to work Split’s implementation of feature flags into your code. From there, we’d be happy to turn on release monitoring and experimentation features so you can realize the full value of an integrated solution.
Learn More About Experimentation and Adaptability
You aren’t alone on this journey. Jez Humble (Google), Adil Aijaz (Split), Ya Xu (LinkedIn), and Patti Chan (Imperfect Foods) all have relevant experiences to share with you:
- Read Kimbre Lancaster’s interview with Jez Humble, where Jez shares lots of wisdom on reducing friction from your software delivery process. For Jez, the end goal of continuous delivery is to reduce the “transaction cost” of pushing changes, so you can put changes out more often: An Interview with Jez Humble on Continuous Delivery, Engineering Culture, and Making Decisions.
- Watch a video on building a culture of experimentation, and what that has to do with learning how to kiss a lot of frogs, as quickly as possible: Video with Split co-founder Adil Aijaz and Linked In’s head of experimentation Ya Xu.
- Learn how a small team working for Patti Chan at Imperfect Foods built a culture of experimentation and increased customer retention using readily available tools.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
We all know a good digital experience from a bad one. Great digital experiences make our lives easier, and negative experiences drive us, and our business, elsewhere. What many users don’t realize is how difficult it is for product and engineering teams to know that the features they’re building will…
Feature flags provide so much for software organizations: they allow teams to separate code deployment from feature release, test in production, run experiments, and more. However, some rules apply to the feature flagging process that are easy for teams to overlook. I’ve gathered the best practices of feature flags from…
SRE goals align perfectly with robust feature delivery and experimentation, where every new feature gets tested, and releases happen behind feature flags.