Your team's differentiator isn't its tech

A simple mind-mapping exercise can reveal your organization's competitive advantage.
469 readers like this.
Open innovation

Opensource.com

In 2016, I launched Open Innovation Labs, a place where people seeking to leverage the principles of openness can work with a seasoned team to build innovative software that solves their most pressing business problems. It has been an exciting and daunting undertaking. Today, Open Innovation Labs imparts knowledge and best practices that emerge from the world's most successful open source projects, and we provide a residency-style experience that immerses teams in those practices.

We generally partner with companies looking to do two things: Either they want to move quickly and be disruptive, or they see disruption as an existential threat and seek to adapt their behaviors to facilitate a more rapid pace of change.

Our own team began as one of the former, but we suddenly found ourselves one of the latter. The lessons we learned as we made that transition—lessons about organizational culture and the power of openness to shape it—truly have made us better coaches today.

Here's what happened.

An identity crisis

To launch Labs, I built a small, cross-functional team that immediately set to work doing the very things we encourage lab residents to do. First, we created hypothetical scenarios to achieve our team's objective—which, in this case, was to accelerate our customers' work in a residency-style engagement and build enthusiasm for building applications the open source way. Then, we applied emerging technologies to build next-generation software that would help us explore those scenarios. We worked relentlessly to create a clever system for accelerating customers' efforts and delivering real value.

We called that system "push-button infrastructure," or "PBI." PBI allows us to spin up a customer-ready Labs environment, built for speed and experimentation, in less than an hour. We took it to market as soon as we could (even before it was fully functional), and the reaction actually took us by surprise. "I want that!" was the most common response we received from customers and internal teams. We were onto something. The excitement was palpable.

About nine months into the endeavor, one of my technical staff pointed out that another open source engineering team in the community had made a major breakthrough with their software—something that allowed them to create a system that could eventually replace much of what we'd built. What's more, this team was easily ten times larger than ours, with a huge ecosystem of partners to boot.

Our little gem was already in danger of being disrupted by a more powerful force.

I reached out to one of the project leaders, another open source advocate. He candidly told me that our group was the inspiration for much of their efforts.

While I was flattered, my stomach also sank: Our little gem was already in danger of being disrupted by a more powerful force.

The team took stock of the situation. We faced an identity crisis. If our core product became obsolete, then would we continue to exist? In that case, what was our core value proposition? What would we look like?

The primacy of principles

We convened face-to-face to sketch our core value proposition in a group exercise called "mind mapping." It produced two strong revelations.

The first was about PBI. As exciting as the technology was, it didn't actually define much of what made us special. In fact, it was barely on the mind map. If it came from another group, or was abandoned entirely, it still wouldn't stop us from achieving our mission. This was a big weight off of our collective shoulders.

The second realization was about something more abstract: The team's most-valued asset was its shared belief system. We all named characteristics like "collaboration," "authenticity," "transparency," "accountability," "open decision making," "meritocracy," "adaptation," "experimentation," and "a focus on impacting people" as the things that made our team truly unique and capable of delivering value to our customers.

These cultural principles came from our experience working in open source communities. We listed principles like:

  • Shared problems are solved faster
  • Transparency forces authenticity and honesty
  • Participative communities are more open to change
  • Open standards provide business agility

Our core mission, we decided, was to share with our customers and partners these same principles over the course of our engagements with them—to help them leverage lessons from the open source world to build, better, more adaptive solutions to problems. This insight allowed us to pivot productively; we realized we should focus more on imparting new ways of working together to catalyze organizational (and eventually cultural) change, and less on any particular technical solution or offering.

Shortly after that meeting, we made the bold choice to utilize the great work coming from the external community we'd viewed as an existential threat only days before. We adapted our software to take better advantage of that offering. Doing this meant halting development on some of what we initially considered core material in order to ride a bigger, better wave.

Our core mission, we decided, was to share with our customers and partners these same principles over the course of our engagements with them.

I still keep the result of that mind map on my desktop. It reminds me that our shared beliefs endure far beyond any particular experiment or project. It centers our team in a way that allows us to transcend the individual, and become part of a bigger purpose, satisfying a fundamental human desire that lays in each of us.

As you read the first section of this guide, I hope you too will discover the benefits of building an organizational culture on open principles—one that transcends any individual effort and creates an enduring, shared purpose capable of inspiring teams long after we're all gone.

This article is part of The Open Organization Guide to IT culture change.

User profile image.
Mike Walker is the Global Director of Red Hat's Open Innovation Labs, whose mission is to make it easier and quicker for customers to bring innovative ideas to life.

3 Comments

As a neurologist and someone who reads works on the philosophy of mind for interest and entertainment, I have to say I don't understand this term "mind map". It seems to be outside my conception of the mind.

Hi Greg, thanks for your time and your comment!

A mind map is a technique to visually organize information hierarchically, usually laid out sort of like branches of a tree that stem from a trunk. Wikipedia has some basic info: https://en.wikipedia.org/wiki/Mind_map

When we did team brainstorming, we got a lot of great ideas. However, we found that if we then organized and grouped the ideas produced in a brainstorming session into a mind map, it became a quick and effective way to see the bigger picture, and reach group agreement on main concepts and themes.

A variant of the mind map that we've grown fond of is called Impact Mapping...stay tuned for an article from a colleague of mine on how we put that one to use!

In reply to by Greg P

Good read, thanks for sharing.
I guess(!) switching to a different tool (from the competition) is much easier when your primary job is not creating tools, but consulting people.

Do you think your experiment had ended differently if your team's task would have been to create said PBI tool and you found out about the other solution?

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.

Download the Open Organization Guide to IT Culture Change

Open principles and practices for delivering unparalleled business value.