One of the key measurements of the success of any product is adoption. There is no point in creating an internal platform if your users don’t end up using it, and you won’t be achieving any significant ROI on your work. But it is not uncommon to see the adoption of internal tools or platforms stagnate and come to a halt. It may well be that they fail to cross “the chasm” or to get to the late majority groups of the technology adoption lifecycle but they end up failing their objectives.

There are a myriad of reasons why your platform may not see the adoption that you would like to see. These may include: not being fit for purpose, focusing on the wrong type of user, not solving the right problems, or being too difficult to use. In many cases, you will hear comments from your target user groups like “We are too busy to adopt yet another thing” or “We will get to it when we deal with a few more fires”.

In this article, I’ll share some of the principles and techniques you can try if you want to expedite the adoption of your internal platform/tools based on my experience and advice received from other platform engineering leaders. I’ve also added two case studies of using dedicated modernization squads to accelerate adoption from my experience at REA Group and Slack.

1. Understand the needs of your users and stakeholders

There is no point in building a platform or a set of tools if they are not solving the problems of your users, in this case, the engineers in your organization as well as those of your stakeholders in the organization.

The key here is to apply product thinking to your platform. If you want to dig into the details of how some organizations are applying it I recommend watching the recording of the talk Leoren and I gave at Devopsdays Melbourne:

Additionally, if your platform solves a lot of your user’s problems by default (batteries included) this will be a strong selling point that will boost adoption.

For example, if your platform meets your organization’s compliance, security, and performance requirements by default then your users don’t have to worry too much about those areas and they can focus on solving user problems.

🛠️ Techniques to explore:

• Hire or borrow product-oriented folks such as a product manager, developer advocate or UX designer
• In the early stages, work together with your early adopters to make sure you are solving a real problem
• Conduct user experience interviews
• Establish a user advisory group
• Have a feedback channel in Slack
• Ensure your platform team has engineers with experience in the area your platform is helping with, for example, software developers
• Keep your executive stakeholders and functional partners engaged
• Use analytics to understand the usage of your product, see below the tracking we did at REA Group of the adoption of Shipper over the years.

2. Focus on providing a great user experience

A compelling platform will attract more users to it and if they like the experience then they will tell other engineers generating the desired snowball effect that will help you greatly with adoption.

🛠️ Techniques to explore:

• Apply UX research and design techniques
• Have a straightforward feature request process and reserve the capacity to tackle those bugs that ruin the experience of your users
• Run customer love sprints
• Run frequent surveys and track NPS score

3. Documentation and onboarding should be a delight

Make sure that your product has great documentation that helps users to get started quickly and also to figure out how to use those more complicated functions that may not be part of their day-to-day.

A critical phase for that is during the early interactions with your platform so you need to make sure the onboarding process is great.

🛠️ Techniques to explore:

• Hire or borrow a tech writer
• Experiment with new ways of documentation: videos
• Use self-serving documentation
• Run boot-camps
• Make platform onboarding part of the engineering onboarding process in the early days of any engineer in the organization

4. Provide reliable and user-friendly support

There is nothing worse than feeling that you are alone when you don’t know how to make a product work or there are issues that need attention but nobody is there to help. Your support channels should be easy to find and provide a great experience to users. A lot of times the users can get captivated by your ability to care about them when dealing with support.

🛠️ Techniques to explore:

• Have dedicated support channels in Slack
• Provide white glove support to your most critical users or those who need it the most
• Provide clarity on the response time and availability of your support
• Tune your documentation and FAQs based on the request received

5. Flex out your Internal marketing muscle

As with any other product, you want to promote and sell it to your users. It’s important that you invest in making sure that they know about the benefits your platform provides and what is coming down the road that may help to build up the excitement but also avoid wasting time developing tools or features that are already in the plans.

🛠️ Techniques to explore:

• Create an identity for your platform: a name and a logo are crucial
• Create a marketing site for your platform. Not to be confused with your documentation as these two should be complementary
• Have an announcement channel where you will share new releases or interesting news
• Swag, swag, swag! One of the most powerful tools that all engineers love. You could have stickers, t-shirts, hoodies, etc with the logo of your platform
• Publicize case studies of your users adopting or using the platform in interesting ways
• Celebrate contributions and adaptations
• Promote your product within your own product. For example when launching new features

6. Create your own professional services / dedicated modernization squad

Similar to how commercial products benefit from providing professional services you can employ similar techniques internally in your organization. The idea is to have a group of internal consultants that provide hands-on support to your users to migrate into your platform. They would work closely with the new users and make sure that when the work is done not only the migration work is completed but also that the new users are able to operate with ease in the platform. You can picture this team as an “Enabling team” in the team topologies terminology.

During the process of helping with adoption/modernization, the dedicated team will have an opportunity to feed back to the platform team on the processes but also potentially contribute to the documentation and code of the platform.

I’ve personally seen really positive effects of using this approach when attacking the long tail of stragglers/lagers.

🛠️ Techniques to explore:

• Fund your dedicated modernization team with potential savings from having each team do this process on their own. Talk to your finance team and you may get surprised
• Embedding folks in product teams temporarily can be a great way to achieve this outcome
• Rotate folks between your platform and modernization groups as this is a great learning experience
• Work with a TPM (Technical program manager) or similar type of folk in your organization who can manage and run programs of work across the org
• Use value-stream mapping to streamline your migration processes

Lastly, I resisted including one of the options to boost your adoption which is Mandate or when your leadership team tells the whole org you have to use the platform. This approach can boost your adoption, as there are no other choices, the effects of losing the competition and the restraint on autonomy can end up hurting your platform perception more than helping.

🪄Case Studies of dedicated modernization squads 🪄

I want to go a bit deeper and share two case studies on utilizing dedicated modernization squads that I consider to be quite successful.

1️⃣ Wall-e team at REA Group

🧑‍💻 Team members: 石昆 / SHI Kun, 王宇飞 / WANG Yufei, 刘阳 / LIU Yang (Rocky), 王玥 / WANG Yue, 陈曦宇 / CHEN Xiyu, 王运 / WANG Yun with the support of Andrew Cos

🚩 Situation:
Adoption of a new CI/CD platform (Buildkite) was progressing but not at the speed projected. Previous tool (Bamboo) licences were up for renewal.

🎬Action:
The platform leadership team pitched to our CTO and finance team for the creation of a dedicated team to expedite the platform modernization program. The program got funded and we used our consulting partner Thoughtworks to kick-start a team called wall-e. The wall-e team started partnering and embedding with product teams to help them uplift their CI/CD tooling. In early stages they realized that uplifting the knowledge and experience of the teams would be critical and worked in a training program based on the platform onboarding exercises.

🚀 Outcome:
All services in the 60+ squads at REA were migrated to Buildkite. Not only that, in the process of uplifting so many builds, they became experts in adjacent things such as our deployment tool rea-shipper, and ended up becoming its Subject Matter Experts, helping teams adopt them too. Funding was expanded to help with these areas and also other revamps of legacy uplifting.

2️⃣ SRE India team at Slack

🧑‍💻 Team members:
Ganesh Kumar Kattamuri, Faisal P, Faiz Siddiqui, Sunil Ailsinghani, Bipul P, Liptan Biswas, Villies Thekkekara, Harpreet singh, Shivam shukl

🚩 Situation:
At Slack, we had created our own internal developer platform (Bedrock). Teams were adopting the new platform at their own pace but one group of teams was showing magnificent results in implementing the new technology. That area was a set of teams located in India that was assisted by an eager and talented group of SREs. Due to the modernization investment teams supported by SRE India had dramatically reduced their custodianship effort leaving the SRE folks team with spare cycles to expand their realm. Other areas were struggling to adopt the new platform in general due to a lack of expertise, the time required for migration and their own product commitments.

🎬 Action:
We got the go-ahead from leadership to expand SRE India’s set of responsibilities to modernize other teams across Slack. A program of work led by TPM was put together and the team started to engage with other teams across Slack.

🚀 Outcome:
During the 6+ months where we run the modernization program many teams benefited from the expertise of the modernization team and managed to get their apps migrated to Bedrock. The team, later on, joined the core platform group and started managing the fleet of Kubernetes clusters for all Slack teams using their gained expertise in working with our platform and our customers.