We’re in the midst of transforming one of the most influential organizations in the world by helping them adopt a new operating model that affords them greater responsiveness to competition, culture, technology, and all other forms of disruption.

To that end, we’re deploying a product development lab inspired by Scaling Agile at Spotify and Eric Ries’ lean startup methodology inside of our client’s organization. In two months from now we’ll have three cross-functional teams that have missions to tackle, the agency to self-organize, and the support from senior leaders to validate and ship new products.

All of the pre-flight precautions for this digital transformation have taken place. To borrow from John Kotter’s 8-Step Process for leading change, we’ve 1) established a sense of urgency, 2) created a coalition to guide, sponsor, and champion the change, 3) developed a vision, and 4) communicated said vision for buy-in.

Now the real work of turning theory into practice begins. We’ve been hiring “A” players, fencing off against real estate to find space for the new team to work, minimizing organizational entropy, managing executives’ expectations, and leading an onslaught of workshops to ready the organization for this new way of working. None of this has been easy, but it all looks like peanuts when you pick up the phone and speak to their 100-year-old IT organization about implementing a shift like this.

Exposing our client’s technical infrastructure to these agile product teams is a very real challenge. From the beginning, our clients told us that IT was their biggest worry. When I hear from their team that it can cost ~$100,000 to setup a development environment for a 3-person team to hack a product together or 6 months to get approval for GitHub Enterprise I can’t help but agree with them.

I could take 40% of the cost out of most IT departments simply by stopping IT Directors managing things they don’t need to manage anymore. — Dave Snowden

None of this is that surprising. Like most traditional companies, they’ve never had a good enough reason to invest in interoperable systems, sandbox environments, or private APIs for anyone in the organization to experiment with. It’s always been spec docs, waterfall development, and things like capability maturity models that big consulting sell to their clients’ IT departments that keep agile practices at bay and disruption lurking at their doorstep. These more traditional ways of working are fine to use when you’re executing, but execution and adaptation are irreconcilable opposites. When you find yourself trying to innovate (frequently) in markets that have high levels of uncertainty (most) your IT department is going to find it really difficult (impossible) to manage that volatility.

This reality makes the case for a Responsive OS all the more potent. If we know evolution works best when it has a diverse selection of small bets to work with across different levels of risk then why not start to design our organizations to do a better job of managing it? It’s why we’re spinning up three teams in our client’s product lab with an emphasis on speed, autonomy, and a high tolerance for small failures. And it’s the same reason why there’s so much value in service-oriented architecture that’s easy to clone and build upon (less capital investment + more frequent and less risky small bets).

Where does this leave our client’s product development lab?

We’ve found some great co-conspirators in their IT department who we’re working with to design a service layer that can support the kind of prototyping you’d expect to find at a startup. The outcome will be an architecture that allows applications to evolve rather then an architecture designed to support specific applications. It’s a bandaid solution, but a damn good one that we believe will become permanent when this new way of working finds its way across the rest of their organization. Beyond that we’re investing a phenomenal amount of time applying these same principles to other parts of the organization (HR, legal, compliance, marketing, customer service, etc.) because without them this whole thing doesn’t work.

No company has ever succeeded in innovation by following best practices in their industrial sector and that’s what makes the uncertainty of this product lab so worthwhile. We’re not applying agile to existing products in service of incremental gains (although we could). Instead, we’re exploring new territory, which means we don’t know if our customers will find whatever we build useful. We’ll have a hunch, a hypothesis to test, but there’s no way of finding product/market fit without building something first. And there’s no better way to do that then embracing a Responsive Operating System that shifts the central lever of management from the hardware of the organization to the software of its culture.