Culture, Behaviors, and InnerSource. A three-part blog series. 3 of 3

The first post of this series highlighted the Westrum typology of organizational culture, ranging from the pathological (that we seek to avoid) to the generative (that seems ideal, but difficult to sustain at scale). The second post highlighted a spectrum of organizational behaviors ranging from the counterproductive (that we seek to avoid) to what we call “citizenship” (that seems ideal, but difficult to sustain at scale). This post is about InnerSource. It too seems idea and challenging to create without support.

I ended the previous posts asking: Can InnerSource thrive in a non-generative culture? Is participation in InnerSource a citizenship behavior? I suggest that with careful support it can operate in a bureaucratic culture. Moreover, it might be better to initially frame InnerSource as an expected part of the software engineering role so that we can create the enabling bureaucratic structures these types of organizations require for work to get done. I'm suggesting this as a way to start, not as the only way to succeed.

We all seek to encourage engineers to create solutions that can be used by many groups. The problem is that some workplaces consider unstructured collaboration as a risk to project schedules. The truth is cross-team collaboration does not have to be unstructured. You can foster innovation with processes that invite it, supporting future deliverables too. That’s why we need to encourage projects to think beyond their next release. In this way, we can help teams meet their schedules by encouraging InnerSource. This also gives engineers a way to make a difference beyond their current role.

In the traditional workplace, factory engineers built products. They billed their time to a project and worked on the projects they were assigned to. The early days of software development were inspired by the factory mindset; the software engineer was viewed as a mechanical engineer. They developed expertise with tools and materials and were assigned to a role on a production line. Aside from their smoother hands, free from blisters and metal shavings, software engineers were not much different. They developed expertise in a language and parts of the software stack and were assigned a role on a dev team.

The successes of the open source and the agile movements challenged the idea of long-plan software assembly. Manufacturing evolved from relying upon late 19th-century scientific management practices popularized by Taylor, Gannt, and Ford to the more generative TQM, Kaizen, and Lean methods popularized by Demings, Toyoda, and other mid-to-late 20th-century process experts. Over the past 20+ years, the software manufacturing industry has evolved too. It does not make sense to build software using a century-old manufacturing model designed for physical goods. Yet in bureaucratic organizations, advocates of InnerSource still face questions that reflect outdated thinking.

• What billing number should engineers use to track and bill their time working on InnerSource?
• Will managers allow engineers to allocate time away from the primary team tasks?
• Who is going to support code created outside a formal project where there is no structured accountability mechanism to point to a responsible party?

Without significant support, InnerSource does not thrive in organizations preoccupied with billing numbers and management permissions. Bureaucratic organizations often respond to the request to support InnerSource by creating rules about the steps a team must take to allow their code to be shared (e.g. scanned to ensure there are no secrets in the code), and rules about when a team can use code that is not supported by an internal team. They prefer creating rules to solve problems, even in situations where the rules are the problem. They generally don't welcome outcomes that rely upon volunteerism. We need an approach that accommodates their orientation.

Let’s take a specific example with a fictional UI Component team (called UIC). Let me propose this as a pattern, not the only pattern. Why this team? Most tech companies have one of these with a small number of underappreciated but excellent engineers and designers working together. Most of their base technology is already open source. Some companies have implemented InnerSource models for their work, some companies are very reluctant to do so, and some companies have even published their UI component libraries as an open source project to get an even greater generative outcome. This tells me that all options are on the table.

The UIC team is responsible for creating UI components all products teams are supposed to use. They ensure components meet accessibility, design, internationalization, and security requirements, etc. They publish a list of approved components but know that product teams will often need a component not yet on the list. For example, a mobile app team now needs a date-picker. Ideally, the UIC team assigns someone to create, certify, and support one, but that takes time and was not anticipated in the plan. The product team can't wait, so they create their own non-blessed component. Then they found that another product team recently created one too. Now we have two components that work, but neither are on the official list. Maybe they fail some requirement the product teams weren’t concerned with initially. Ideally:

1. The UIC team seeks to have an official component in their UI library. They can create a new one, promote an existing one (perhaps modified), or blend the best parts of the ones out there.
2. The product teams prefer to use a supported component, but don’t want to upgrade components unless there is value in doing the work. So, there’s a timing issue.
3. A new team that needs a date picker should be discouraged from creating a new one if the official one is already out there.

But what happens if there’s a need before the UIC team decides which path to take? What does another new team do? They could also create another new date-picker or use one of the existing ones. Using an existing one is the start of InnerSource. For a new team to use an existing date picker, they need to discover there are two out there created by other teams. Since neither is on the official list, that may be a challenge. Ideally, we want to reduce the proliferation of redundant solutions. The UIC team prefers that new teams use an existing component, even though they don’t support it. It makes eventual consistency easier.

Previously they viewed the world of components as either being in their library or not. They were the gatekeepers. But they realize the factory mindset does not scale. Other teams can create and proliferate their own components, undermining the value of the standard library. Rather than fighting the business, and suppressing the generative solutions using bureaucratic policies that result in worse overall outcomes, they accommodate as best they can – with an InnerSource process.

For those needs not yet addressed by the UIC team, product teams have an incentive to publish and even provide some support for their incubating interim options. Doing so improves the chances their component gets promoted and they have less future work. The UIC team also has an incentive to publish their roadmap so that product teams can decide if creating an interim solution is worth the trouble. Moreover, the UIC team might want to publish their accessibility, design, internationalization, and security standards so that product teams code toward those goals. Better yet, the team codifies the requirements in the form of unit tests to be automated by the build process. Most of all, the UIC team has an incentive to point people to the new incubating solutions. In fact, the UIC team realizes they now run an incubation pipeline. This process allows them to augment their engineering resources, control the process, and encourage InnerSource. InnerSource via incubator pipeline. If you proposed it, they'd say it's out of scope for what they do. But if you back up into it, it makes a ton of sense.

Notice that an engineer working on a product team may also get a sense of pride that a component she created to address an unmet need for her product can be promoted into the UIC library and used as the standard component for all products. We’ve provided her a path to citizenship behavior by showing her that even though the coding was her job, getting it into the incubator is above and beyond. It's that careful balance we were seeking. The incubator is a formal process (since bureaucracies love that), but it feels a bit more generative, at least to the participants (and people love that too).

I'll note: this isn't a novel idea. Incubation paths are standard at many open source software foundations and are at the core of many Open Innovation processes. This approach is, in some way, a blend of existing InnerSource patterns: the Contracted-Contributor (an agreement), Gig-Marketplace (if the UIC team invites incubees), and the Review-Committee (acceptance after incubation) pattern. Maybe this is a new take on the idea (if so maybe we have a new pattern to contribute? folks, let me know)? My goal here was to weave together the lessons from Westrum's culture analysis, the discussions about organizational citizenship behaviors, and common barriers to InnerSource at bureaucratic organizations to see if there emerged a pattern that can help an InnerSource-seeking team.

Summarizing the 3-post journey: Achieving InnerSource success at bureaucratic workplaces requires a blended understanding of three topics. 1. InnerSource itself. This field is evolving under the guidance of the InnerSource Commons group. They have smart contributors who are capturing great ideas you can use. 2. Your organization's unique cultural biases. That, according to Westrum, comes from leadership and their signals about what matters most to them. I don't propose you ask them to become non-bureaucratic. That's not how change works. Rather, to find ways to add support for parallel processes that fit in with the bureaucracy but support generative outcomes. 3. How to inspire the most effective InnerSource behaviors. You'll want a careful balance of "greater purpose" messaging to attract people to bring their best. But if you position InnerSource as pure volunteerism, it may get blocked or diminished. I wish I had a better answer for this part. It's tricky. The challenge now is to take these three aspects and blend them to suit your unique environment.