7 Lessons on a Journey to InnerSource

With the increasing pressure to deliver new ideas, products and services faster and more efficiently, companies are asking themselves: Is our development model the best it could be?

Companies born in the digital world tend to have an inherent collaborative culture, using agile methodologies and open source ecosystems that drives a more efficient development model and delivers higher quality software. But for more traditional companies, InnerSource is becoming a popular strategy - the approach to using open source culture and best practices inside an organisation to create a more free-flowing collaboration style.

Recently I spoke to James McLeod about his journey to InnerSource at Lloyds Banking Group.  James recently joined the FinTech Open Source Foundation - FINOS as Director of  Community to pioneer and educate the Financial Services adoption of Open Source. Here I share his top 7 recommendations on how to embark on a successful journey to InnerSource.

From the get-go, there was a desire within Lloyds, from the top down, to have a more free-flowing collaborative style and reap the benefits of Open Source .  They actively encouraged engineers to come together in order to evolve a real community spirit.

James is the first to acknowledge that having ‘enlightened management’ on his side was a critical first step in the journey to InnerSource and was instrumental in facilitating every step along the way.

Having a senior sponsor to support, advocate and even mandate is key.

At Lloyds, the push to have a more collaborative model was applied across all disciplines. It was part of their group digital transformation that all disciplines should learn to communicate and share ideas with one another.

This presented an opportunity for James to take advantage of and paved the way for him to embark on his quest.

Once you’ve begun the journey, taken the first steps and created some platform for negotiation and collaboration, it’s important to make it known.

Publicise your ambitions.

This can feel scary, but it’s a proven tactic promoted with the InnerSource Commons.   Securing buy-in is easier when the benefits are understood. Seeing people get better together and seeing all the boats rise can be powerful and exciting.

Building on his experience of meet-ups, James established ways to communicate, involve and motivate others. Along the journey, he brought out the engineering team to broadcast their intent, presenting to key stakeholders internally and externally.

Many companies who adopt InnerSource are encouraged to do so in order to address the silos that exist within their organisation. Discrete engineering teams are separated from each other.

Often there’s a method to request features or enhancements across these silos, but the actual coding happens only within a closed group and bottlenecks are common.  This was a key issue at Lloyds and was one of the first issues to be addressed.

James led an examination of all their systems of collaboration to explore where they could improve sharing of code across departments and across countries.

They looked externally to examine potential solutions that would remove bottlenecks and barriers to collaboration. That's where their journey into GitHub Enterprise started and allowed them to maximise the opportunities that InnerSource presented.

They had to take extra precaution not enforce too much control in the system whilst at the same time involve those from cybersecurity, risk, product owners & designers - those who actually owned the output.  As an engineering team, they should not be seen as mavericks, particularly given the regulated industry in which they operate.

Within digital transformation, an organisation needs to learn how to adapt. It’s not enough placing the systems to improve much-needed collaboration and provide the missing metrics. You need to learn how to adapt and adjust your organisation to be able to meet the demand.

At Lloyds, the engineering demand drove the change within the wider organization in order to meet it.  To build momentum and generate active interest and involvement, they rolled out brown bag sessions, streaming webinars, ‘horizontal’ working groups, and hackathons involving senior people and graduates and guest speakers.

They provided lakes of education and onboarded people into the systems that they needed to be able to use.

The evolution into InnerSource is absolutely possible providing you have the right people on your team. But also by finding the diamonds outside of your organisation, those who think the same way and are trying to transform their companies within can lend tremendous weight to what you are doing.

Along his journey, James began to build trusted relationships with like-minded engineering teams from other large financial organisations and consultancies - like IBM, Wipro, TCS and Publicis Sapient - sharing ideas, collaborating technically and inviting one another to speak at events.

Once you’ve demonstrated how to solve big problems on a small scale, you can broaden it to the wider organisation. Embarking on a pilot and demonstrating results can really encourage the business to start thinking differently and educate them on the benefits.

By applying the principles of open source within an organisation, InnerSource helps teams work better together by breaking down silos; reducing bottlenecks; and resulting in higher-quality development, cleaner code and more efficient use of resources.

A more collaborative, effective and efficient delivery model helps to increase innovation and create a competitive advantage.

If InnerSource is new to you, you’re not sure what ‘great collaboration’ looks like and you need practical help in setting up ‘rules of engagement’ or embarking on a pilot, we can help you get there.  Contact us to arrange an initial evaluation with me or to learn more about our InnerSource Developer Days, training and consultancy offers.