Published 18th September 2019
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.
1. Secure Your Aircover from early on
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 “If I‘m going to be honest, the mechanism of being able to do this wouldn’t exist unless we had that executive air cover for people just to come together and start working together. ” Having a senior sponsor to support, advocate and even mandate is key.
2. Recognise that it’s not just for the benefit of the Engineering Organisation
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. “We wanted to not only do what was needed for the engineers who were using the system, but we also wanted to make sure that we brought everyone along on the journey as well. The real benefits are when you extend it to the wider organisation.”
3. Alleviate People’s Fears
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. “To transform, it’s good to have people who want to transform. Talk about InnerSource projects, give them a name, make them your DNA. Alleviate people’s worst fears. Change is hard and change is scary for people. Once people get it – what it actually is – a lot of the things they were afraid of gets dispelled pretty quickly. Ultimately, it’s a social dynamic. It’s how you bring great people together in order to collaborate and move forward together.”
4. Recognise the problem and address it head-on
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.
5. Learn to Adapt
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 onboard people into the systems that they needed to be able to use.
6. Find Your Diamonds
The evolution into InnerSource is extremely 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. “Collaborate with them, start broadcasting the message so both of your stakeholders can hear the great outcomes that you’re doing together. That’s when organisations can truly start to transform.”
7. Start Small
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. “ I won’t say they were the big bang explosion, you know, we didn’t go from lights out to lights on overnight and, in fact, it’s still continuing to happen. But even with those first seeds planted, we were able to yield some pretty interesting and big results which are just spectacular considering a lot of teams couldn’t work together before.”
By applying the principles of open source within an organisation, InnerSource helps teams work better together, 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.
If you like what you’ve read here, head over here to the full podcast interview with James McLeod, FINOS Director of Community.
Follow us for more information on this and other topics.
Talk to one of our senior team for expert advice
Danese Cooper, VP of Special Initiatives at NearForm, leads the InnerSource capability building program, helping companies looking to modernize their development practices. If you’re new to InnerSource and want to find out how to start with a cultural inventory or embark on a pilot project contact us and we'll guide you through the process.