What we’ve learned from two years of Red Hat Open Innovation Labs

Since this April marked the two-year anniversary of the launch of Red Hat Open Innovation Labs, it’s a particularly appropriate time to reflect on what’s worked well, what hasn’t and what still remains to accomplish. We’re starting to see patterns and trends. So in the spirit of open source (and in the spirit of what mom always said), 'it’s better to share’ — here goes:

Buying in on the great experiment

First, it’s useful to note that we’ve always considered Open Innovation Labs an experiment: a living, breathing work-in-progress. This attitude has served us well. We set out to create a startup of sorts within the world’s largest open source software company, dedicated to creating enthusiasm for building applications and building teams the Open Source Way.

In the beginning, this attitude required us to be open and honest with upper management about the unknowns. Will it be profitable? Don’t know. What’s the three-year plan? Don’t know. But we have ways to find out quickly, iteratively and cheaply. And we have good evidence to believe return on investment could be huge. So let’s give it a try.

These kind of conversations are not comfortable ones to have, especially in a larger company owned by public shareholders with high expectations. However, establishing early executive buy-in on a startup-style of business is critical to creating the freedom and responsibility necessary for rapid change.

Community-powered innovation

During our initial growth stage, we’ve concluded that a focus on people and teams is paramount. But, it is not enough to hire great people. You must build high-performing teams, quickly. And to do this, you must leverage the power of community.

Specifically, we looked outside of Red Hat, to other great communities, for inspiration and for collaboration.

To establish our delivery practices, we looked at thought leaders, open source communities, and other companies we admired, in addition to Red Hat’s internal practices.

We borrowed ideas from people like Karen Martin, Gokjo Adzic, Alberto Brandolini, Martin Fowler and Jez Humble. We borrowed ideas from open source communities like Kubernetes and met with their engineers. And guess what? Not only did this help us build our business more quickly, but it created connections with these teams and individuals that have allowed us to mutually benefit more than we’d ever imagined.

To establish our engineering assets, we purposely chose to join an existing, nascent community called Container Automation Solutions Lab (CASL), which was started by our Communities of Practice (CoP) within Red Hat. We were able to use that existing effort, and turbo-charge it to quickly establish what we at Open Innovation Labs call push-button infrastructure. Looking back, it would have been a massive waste of time to attempt to build this on our own. In fact, we might not have gotten off the ground had we attempted to go it alone.

No pressure, no diamonds

Something about the Open Innovation Labs format — a time-boxed, residency-style, immersive work experience — is magical. We intentionally time-box our work between one to three months in duration. People leave their offices and work in a new environment, relatively free from distractions. And we all work together, dead-set focused on a single, really tough business challenge.

Expectations are high. And funding is fixed. There’s no time for fiddling around. We must find the leanest way to get results, fast. So the team becomes willing to take risks and be experimental. When it feels right, I describe it as a tense, positive and optimistic excitement in the air that is infectious

The right kind of pressure creates near-inseparable bonds among teammates — this is something you just don’t see in typical organizations, and it lasts far beyond Open Innovation Labs. Living in San Francisco, I occasionally bump into former Open Innovation Labs residents at coffee shops and other places. And it’s like getting reunited with a good friend from school — you’ve got an authentic, shared connection for life. In this sense, the Open Innovation Labs experience can really be a culture change catalyst.

Best of all, the right kind of pressure creates amazing results. Like advanced mobile app prototypes in just five weeks and high-performing, self-organizing teams that live on far beyond their Open Innovation Labs experience.

Pouncers and pausers

Teams that are diverse in skills, backgrounds and attitudes tend to be more resilient and adaptive to change. They are increasingly essential to maintain a competitive advantage.

As an experiment, we teamed with LDR21 to examine our own team. During a workshop in Boston, we ran an analysis of our team, using their Open Index and Individual Response Index as the measuring stick.

Perhaps unsurprisingly, we learned that the large majority of Open Innovation Labs team members were naturally ‘pouncers’ - people whose natural initial response to change is to leap head first without hesitation. However, some of the best teamwork out of Open Innovation Labs had come from collaboration with ‘pausers’ - people whose natural initial response to change is to pause and analyze before making any moves.

We had an ‘aha’ moment: great teams need both pouncers and pausers, agreeing to work together on a common goal!

Our job was to find the right counterbalance to create those teams in each Open Innovation Labs experience and to establish and reaffirm a common team purpose each day. Like Woz and Jobs, the yin and yang between these two natural tendencies can create harmony and really successful products. Sharing this insight has helped Red Hat team members collaborate more effectively in developing solutions where there may be uncertainty about a veteran employee’s new role in an increasingly fast-paced, digital world.

ABO: Always Be Offboarding

(Source: Alan O’Rourke, OnePageCRM)

At Open Innovation Labs, we must ensure that whatever we build — great software and great teams — can be brought back home. So we have a mantra: ‘ABO: Always Be Offboarding.’

Before an Open Innovation Labs residency even begins, we are already prepping for offboarding into the enterprise.

This is where open source and open standards help tremendously.

Containerized prototypes can run anywhere. Open standards allow components to be interchanged later, without an excessive amount of refactoring.

This is where microservice architectures help tremendously.

We use Event Storming to quickly arrive at a domain-driven design for our business solution. Coding to APIs and domain models allow for greater modularity and flexibility for change down the road.

This is where a dual-track approach helps tremendously.

At Open Innovation Labs, we’re quickly prototyping innovative new software. I like to compare it to building a next-generation race car, with all the best possible parts at your disposal, using techniques prescribed by the experts who purpose-built those very parts.

At the same time, a second, on-premise team works in the enterprise datacenter or cloud of choice to lay down the operational foundations of a modern production-ready infrastructure. I liken this to building a racetrack while the car is being developed and tested.

The best part: both efforts can be done simultaneously, and when the two efforts converge, the racetrack is ready, and the car is compatible with the track. So we can begin using that prototype right away, continuing development and taking it to production, and to scale.

This is where our push-button infrastructure helps tremendously.

At Open Innovation Labs, a near-daily ritual that residents will experience is the tear down and rebuild of the entire development environment. At first, it’s frightening to most. Over time, it becomes essential, because it helps us to be absolutely sure that everything we build is code.

More specifically, we encode our infrastructure, our pipelines, our deployment processes and, of course, our application. We capture changes in source control and use test automation and advanced deployment techniques to deploy those changes. In this way, we can be certain that the environment can be recreated with ease, almost anywhere. This helps to greatly simplify the transition and offboarding to a new environment.

Great entrepreneurs subscribe to the culture of open

Being open does not only mean looking outside for inspiration and new ideas. Equally so, it means being able to quickly ditch an old idea, no matter how labored or beloved, in favor of a better one — even if it wasn’t your own.

This can be hard for early entrepreneurs to embrace, as there is an over-emphasis in today’s entrepreneurial culture around the ‘mad genius-style creator.’ According to legend, the mad genius single-handedly invents instantly successful products in a fevered rush. While I also enjoy late night hacking sessions, there is, in fact, a method to the madness behind successful, sustainable, entrepreneurial efforts.

For starters, adopting open principles can create immense business leverage that proves to be essential for any early-stage effort. We’ve learned that the fastest way to build a solution is not to build it at all, but instead to find a community that’s already laid the groundwork for you.

This is why we believe that open source moves faster than proprietary software. And why many of the world’s best software solutions are increasingly built with open source.

Open is a cultural mind shift worth fostering in organizations large and small. At Open Innovation Labs, we provide a purpose-built environment to reinforce open principles until it becomes muscle memory. But anyone can learn to adopt the principles of open, regardless of your environment or policy on open source software.

Open for good

It’s no coincidence, then, that the United Nations Children’s Emergency Fund (UNICEF) Venture and Innovation teams have chosen to standardize on open source solutions.

Their venture team identifies early-stage ideas with the potential to significantly and positively impact children’s lives in critical ways, in order to justify a venture investment. They typically look outside to community efforts across the globe, searching for options that might already exist, but just need additional oomph to create greater impact.

Their innovations team then takes these ideas, and brings them to greater scale and impact through open source software solutions. Standardizing on open source gives them the flexibility to deploy where and how they want with the ability to scale to meet the project’s needs. This is essential to helping UNICEF deploy these solutions in the poorest of countries, where resources are severely limited. And the adherence to open standards allows them to maintain interoperability so that existing solutions can be repurposed for uses that may not have even been imagined.

This is why Red Hat collaborated with UNICEF and many others to create a big data platform for social good called Magicbox. We’re truly excited to share the results of this effort at Red Hat Summit this year and look forward to making a major, tangible and sustainable impact on children’s lives globally as a result.