Engineering Acceleration with InnerSource Culture
“We’re all working together; that’s the secret.”
~Sam Walton
Organising the teams for delivering a large enterprise product is one of the biggest challenge most leaders face at the job. A team structure can make or break the speed at which the product can be delivered and also shapes the working culture at enterprise organisations. There have been various ways to organize the teams; for example — hierarchical structure, functional structure, matrix orgs, hybrid etc.
Value Streams/vertical teams always achieve business focused fast deliveries because they have least friction in terms of managing dependencies & there are no single bottlenecks. Business, product, engineering & design being in one group, move fast right from idea to design to development to release. Decisions and prioritizations are in silo and are much faster.
Below is a simplified version of how engineering teams and code repositories ( repo in short ) are organised in vertical value streams:
Respective teams work in their code repositories with no overlap of work and make independent releases. This works pretty well until at a certain point. Imagine a situation where 2 business VS ( value streams ) need a shared capability; for example, a user account suspension on e-commerce marketplace for two or more different reasons managed by different value streams of work. Now there is a problem of duplication. In the motivation to move fast and also since the decision making is in silos, both VS teams will build the common capability resulting into a duplication of code, loss of productivity and wastage of resource, finally increasing the cost of development. So there is a problem!
In classic setup there are 2 common solutions to this problem:
- Move the common capability to horizontal platform:
The shared capability team works as a separate team and builds the common capability to be reused across multiple value streams. This avoids duplication as a single code base and services can solve for multiple business capabilities. However, this model breaks the concept of value stream teams because the shared team cannot be aligned to any specific business need directly. It also results into prioritisation issue for new features because different business value streams may have conflicting priorities at any given point.
2. Reuse the common capability built by a Value Stream team:
Instead of carving out a horizontal non-value stream team, the common capability can be developed and maintained by one specific value stream and other teams can reuse.
This model maintains the value stream structure for ownership & delivery, but has the same problem of conflicting prioritisation and resourcing for common reusable code. The owning team for common code may become a bottleneck, leading to slow delivery of business needs and poor team morale.
However, there is 3rd approach to solve this problem — where multiple value stream teams can contribute to single common capability repo. The below diagram shows how this model works:
With multiple teams forking and contributing to single repo, this model “opens” a code repo for independent code contributions. Feature level prioritisation can be managed by independent VS teams and resourcing can be managed independently based on business value. Inter-team engagements shift from Feature Requests to Pull Requests.
If you are still reading this article, you just got introduced to the model of InnerSource!
InnerSource was the term coined by Tim O’Reilly in 2000. As defined -
“InnerSource is the use of open source software development best practices and the establishment of an open source-like culture within organizations for the development of its non-open-source and/or proprietary software.”
Today InnerSourcing is a common practice at many large tech driven enterprises across globe. Below are the main benefits of InnerSourcing:
- Code Reuse/Leverage : InnerSourcing practice avoids duplicates code in the system allowing leverage of common capabilities/framework/tools across different business focused engineering teams.
- Better Quality : The base to enable InnerSource adoption lies in quality. Quality of product gets better with automation, code reviews, static code quality checks & regression suites coverage. There are more than one member reviewing the code coming from multiple teams.
- Innovation : The silos around subject matter expertise gets broken allowing cross team ideas and both product and tech innovations across the groups participating in InnerSource projects.
- Cross Organisation Collaboration : This model expands the definition of team beyond a manager or leaders’ hierarchy. Team members from various sub groups/business units collaborate on one project, building the code and members’ visibility across organisation.
- People Engagement : People are at the focal point of InnerSource culture. Driven by trust, ownership and close team work, InnerSource culture boosts engagement and morale for the people at organisations. This brings in the sense of volunteerism while continued to be focused on business deliveries from the team.
While the benefits of InnerSource are obvious, it does not come for free. There are various challenges both from organisational setup and the adoption point of view. InnerSource model requires significant change in working style. The classic management style that believes in “single neck to choke” for failures will have high resistance for the InnerSource adoption. If not done right, this model also brings fear of security problems, uncontrolled forking, pull request queues, fear of maintenance efforts etc. These can be solved by thinking InnerSource as a culture along with implementation of new leadership styles & right level of governance.
InnerSource culture:
InnerSource is a not a process but is a culture; and a culture, to be built inside an organisation, needs investment at various level. InnerSource culture can be built with enabling 3 basics tenets and support right from senior leadership to grass root level.
The following diagram shows the 3 basic enablers/principles of InnerSource culture:
- Transparency : This basic principle reinforces and enables open mindset. Transparency is built into the code and process by putting the right documentation of the design, detailed code comments, developer guides to enable self start that encourages someone new to start with the fork and understand the code. Transparency invites re-use, builds quality and enables collaboration through communication.
- Collaboration : Built on the foundation of transparency and communication, collaboration is achieved by a common vision and goal shared across multiple teams. Collaboration encourages feedback and dialogue among developers that enables a sense of community spread across different business facing engineering teams. Without a strong sense of community and collaboration, InnerSource culture can not be sustained.
- Meritocracy : As mentioned earlier, people are at the center of InnerSource culture. The culture of InnerSource flourishes and sustains only in a meritocratic environment. In turn, this culture also helps drive meritocracy where the technical decisions are made by technical experts, and tech design & architecture are not driven by organisational boundaries. To build and sustain InnerSource culture, leadership needs to support and nurture people with “earned authority” & “role models” purely based on merits and impacts. Both suppliers ( teams that own & maintain the open repo ) & consumers ( people who re-use & contribute to open repo ) need to be celebrated and rewarded to encourage and nourish the InnerSource culture.
At Walmart Global Tech we do it very well. At highest level of tech & business reviews, we showcase, cheer and reward the InnerSource adoptions.
To wrap it up, InnerSource culture is a mindset to achieve boundary less engineering accelerations, enabling re-use & leverage while continued to be focused on value creation for business within a Value Stream. With InnerSource adoption, leaders can build highly engaged vertical teams without worrying about wastage in duplication. While this concept was introduced years ago, with various collaboration tools ( e.g., git for code versioning, Confluence for documentation, Jira for issue tracking, Zoom/Teams for communication etc ) available at hand, this culture has seen accelerated adoption across various large enterprises recently.
References and further reads:
- InnerSource wiki
- Adopting InnerSource book [free pdf]
- InnerSource commons org site
- An Introduction to InnerSource
