Common Practices to Reduce Adoption Cost of Internal Engineering Tools
In my last article, I talked about starting an adoption plan by driving with the outcomes the customers would gain impact in and that instead of forcing adoption, we should first view our role as educators, helping customers determine when adopting is right for them based on the cost of delay relative to the outcomes. This article will cover the third variable: how to make adoption as affordable as possible.
Affordability may be the most critical variable since the more effortless to adopt, the higher the product's initial adoption rate. Even if a product provides few outcomes a customer prioritizes, if it's nearly free to adopt, then why not?
This article will focus on strategies from around the industry that have been successful and inspire some ideas for making internal developer enablement and platform tooling easier to adopt.
Near 0-Effort (for the Customer) Adoption Strategies
"The Holy Grail is 0 Effort Adoption"
Olga Sermon
In her talk "Available, Affordable, Attractive: Enabling Platform Adoption," Olga Sermon says, "The holy grail is 0 effort adoption." Let's start here -- what are examples of feature adoption that took close to 0 effort?
Automated Delivery (and Early Design)
Olga says:
"When we're evaluating solution candidates, we have to think whether we would be able to automate them and whether users would have to do a lot of manual things to get them to work...the holy grail is zero effort adoption which means we want to automate everything we can and we want to minimize the number of interfaces we provide to our users as well"
Inherited Changes
Olga talks about how they introduced image scanning into the builds at their company, and all the customer had to do was sign up to activate it. This example implies the product designed a way to automate the delivery of new capabilities to pipelines without needing customer action.
Side note: sooner or later, at every company I've worked, there has been a need to generate parts of a pipeline and have the user compose the rest.
At a previous employer, I worked on scanning all running images in an environment and sending reports to risk and compliance and the customer team. Since apps aren't always under development, vulnerabilities occur for services that have been running but not updated.
These security use cases are examples of added benefits to the Platform side of the product, sometimes without even an interface for the customer to use, inherited into the infrastructure they run on. These types of changes result in nearly 0 effort on the part of the customer.
Composed Changes Utilize Dependency Management and SemVer
On the other side of the infrastructure is the app running on it, and engineers must make changes to adopt new infrastructure or Platform capabilities that get released.
While many benefits are released and inherited, this class deals with releases consumed and composed within an application's repository like other dependencies.
Examples of this
An authentication library distributed as a versioned jar for Java services.
Helm charts and Terraform Packages versioned and distributed.
Designing platform functionality to be delivered like any other package management system to enable versioning and composition resolves many issues adopting new Platform releases. Adoption is fundamentally an update action. Doing it this way allows cross-compatible acceptance or integration-level tests to confirm broad platform usability. Still, it also puts updating into the same SDLC workflows that engineers are already used to and provides greater flexibility in determining the architectures to consume them.
In this article, Abi Noda reviews "Which Factors Influence Practitioners' Usage of Build Automation Tools?". He finds that adoption is impacted by whether the tools are configurable, fit within the existing technology stack and workflows developers use, and the product is visible broadly in the organization. Delivering releases that integrate into existing workflows will offer the best chance of regular, consistent adoption.
So, low-cost adoption requires a system design that enables inherited and composed updates through minimal, standardized, well-defined interfaces. Then, the automation to deliver them accordingly.
It is worth noting that there is an upper limit to the changes that must occur in the customer's service for low-to-no-cost adoption. I've driven re-platforming efforts where significant components of customer service have to be rewritten -- like adopting Kubernetes from a VM-based platform. There's no option but high effort for that type of work, and higher-effort adoption strategies are what come next.
Higher Effort Adoption Strategies
Enabling Teams
In his talk "How to accelerate the adoption of your internal platform," Javier Turegano talks about how Slack relied heavily on "Modernization Squads" to make adoption low-cost for internal customers:
"...picture this theme as your own internal Professional Services, similar to how commercial products and companies benefit from providing Professional Services. You can employ similar techniques internally in your organization...the teams will not have to do the adoption themselves because it will be expedited by experts."
Sometimes, there isn't a dedicated enablement team, but each team must play the role of an enablement team for anything they release. When talking with Rebecca Murphey about their time at Stripe, they mentioned how Platform teams would push changes to the customer's repository, bypassing the customer altogether.
At Twilio, we don't push changes but submit PRs to repositories with the suggested changes so the team can review and accept the changes. They are similar but reflect a critical difference in the operational culture and how that relates to adoption.
Keeping Documentation Up-to-Date and Invite Contributions from Users
When customer teams adopt product work, enabling them to do it themselves is the goal. PMs from Microsoft, Stripe, Github, Slack, Twilio, and others mention how vital relevant and accurate documentation is to efficient product adoption.
Many PMs said one of the most significant factors that facilitated their partners to adopt a new platform was allowing anyone to update the documentation easily. If something was outdated, the customers added it themselves. Not only did this allow the documentation to stay up-to-date and increase its usefulness, but the customers saw themselves as part owners of the solution and increased their engagement in developing the platform tooling.
Group-owned documentation updates are a good signal. If a diverse set of teams regularly contributes to the docs, then more positive outcomes around adoption occur.
Applying an Open Source Model
A PM at Microsoft told me about when it came to re-platforming: many teams didn't adopt the new Platform initially because it didn't support many vital features. The Platform group had to prioritize the needs of other customer teams. A sizable population gets caught in what she called "the infinite PM loop," we talk with a team, figure out what they need, and apologize because their needs are a lower priority than other teams. There needs to be more engineering capacity. Some teams get caught in this loop for years.
Microsoft's Linux platform team adopted an open-source contribution model to alleviate this problem. The Platform group set up clear contribution guides, and some customer teams even allocated engineers to work on the Platform team to build needed features.
By enabling customer teams to co-develop using open-source models, the Platform accelerated adoption broadly and increased customer satisfaction internally. This strategy hits on customizability and engineering throughput themes in a planning and prioritization process.
Lastly, good old-fashioned top-down pressure
There will almost always be some small percentage that doesn't adopt, either by being abandoned, forgotten, or ignored. Top-down pressure is a strategy of last resort since it is expensive, slow, and usually burns goodwill. But, I don't have any examples of larger companies that sooner or later have to apply managerial force to finish broad adoption goals.
Conclusion
We see some common themes develop. The first is well-done adoption examples have a minimal cost in terms of time and engineers to the customer team. These outcomes result from thoughtful planning around standard interface changes flow through and automation for ongoing delivery of updates. How strictly the platform team tries to standardize is unique to each company. Still, there is a middle ground that has to be found between freedom and standardization if we want to deliver regular updates to teams as efficiently as possible.
Second, most changes should fit existing SDLC workflows by being versioned controlled and composable dependencies compatible with existing tech stacks. This strategy eliminates the hurdle of changing customer workflows or tech stacks and puts adoption in the proper perspective: an update process.
Lastly, re-platforming initiatives are wildly expensive and challenging. If our goal is incremental delivery and a cadence of value, re-platforming should be the last option. If there is no alternative to re-platforming, then enabling customizability through open-source models, group-owned documentation, and heavy investment in enablement or internal professional service teams resolve many issues preventing adoption.