Why developers avoid your platform
You’ve assembled a platform team and built a self-service, internal developer platform (IDP). The first version is up, but nobody is using it. What’s wrong? This article discusses common problems and ways to address them and offers a way forward that works for everyone.
In the 1989 movie “Field of Dreams,” Kevin Costner built a baseball diamond into his cornfield because a mysterious voice promised him, “If you build it, they will come.” This phrase became a popular way to describe ambitious IT projects where people believe the outcome is so valuable it will draw users toward it. But what happens if they don’t come? What happens when you invest a vast amount of time and resources, but your users simply stay away and don’t use what you built?
Here, we talk about this disappointing scenario in the context of cloud platforms. Let’s say you recently built a new self-service platform for your organization. It deploys secure, compliant infrastructure, allowing developers to self-service everything they need. Yet they refuse to use it. Instead, they prefer to follow a DIY approach, managing their own tools and workflows. Worse, maybe the developers choose to avoid the cloud entirely and continue with legacy technologies rather than be forced to use the organization’s platform.
Fortunately, several ways forward, discussed here, can improve the situation and help you build a platform that works for everyone.
They will come if there is no alternative
Regardless of the merits of your platform, some developers will not use it if given a choice. They may want to target a different cloud provider or feel that a DIY approach would permit faster delivery times, allowing them to realize the benefits of public cloud more quickly. Multiple, smaller platforms might be manageable for a small organization or a single team with a niche requirement. But at scale, this means no central visibility, reinventing the wheel each time, and a fragmented IT landscape. Maintaining a patchwork of tools and workflows loses economies of scale and makes it harder to achieve the gains that every organization seeks.
Many platform teams start life in this kind of fragmented technology landscape with a remit to introduce standardization and bring control. Pragmatism dictates a phased approach: it is often not feasible to expect the entire technology organization to move to a new way of working in a single “big bang.” Instead, the platform team works in parallel, providing shared services (like VCS, CI/CD, or observability) that help developers offload non-functional concerns they don’t want to manage independently. If the central platform can offer easy onboarding and promise a low-friction developer experience, teams will soon find that the benefits of using the centralized platform outweigh the cost of running their tools themselves, and they will start integrating into the platform.
At this point, the platform team could begin to make the platform mandatory. Sometimes enforcement is done bit by bit: first, the VCS system (which everyone uses anyway), then the CI/CD tool (which developers are comfortable with and aligns with industry best practices). Teams that started on their own might choose to onboard to the platform later, as the burden of running tools on their own becomes untenable. It’s important to remember that a mandatory platform shouldn’t mean “my way or the highway.” Developers may need to opt out of specific tools or workflows they can’t use, and they should be allowed to. But if this happens a lot, it’s a sign that your platform doesn’t meet the needs of your users, and you may need to rethink how it works. More generally, if your mandatory platform doesn’t address the needs of your users, you’ll hear soon enough. A feedback loop of developers’ grumbles and gripes should be used positively, with their requirements feeding into a roadmap to ensure the platform team focuses on the most demanded features.
Features of a good platform
HashiCorp Professional Services engages with customers to help them use HashiCorp products as best they can. In our line of work, we see many platforms and different operating models. We know employing the right technology is only part of the platform equation. Platform teams must consider people and processes equally, too. Increased adoption is any platform’s first and immediate aim, so let’s dig deeper using the Technology Acceptance Model, which defines successful adoption as a function of 1/ perceived usefulness and 2/ perceived ease of use.
People
The focus should initially be on the platform consumers: developers. A platform should streamline their workflows and enable them to self-service the infrastructure they need without unnecessary process pain. Everything they require should “just work,” with a paved road guiding the way. They should also be able to leave that paved road and blaze their own trail, should the need arise.
Developer experience is a vast topic, and it isn’t possible to do it justice in a short blog post. But some aspects make a big difference. A low barrier to entry is essential, as is maintaining a low “cognitive load” for the platform. Your platform should be simple to understand and use. Do sensible default values mean users can start in a few clicks or lines of code? Is there good (read: up-to-date) documentation with clear examples and samples? Is there a Golden Path they can follow to get them there?
Providing targeted, specific education will make it easier for developers to use your platform. Are developers aware of the platform, its capabilities, how to deploy their applications, and how to get help when needed? How can your developers become platform advocates who can spread the word and encourage others? Often, winning the hearts and minds of developers can tip the organization into a better perception of your platform and, from there, into making it a success.
Process
However easy a process may be to follow, no amount of manual, repetitive work can be called “useful” for your users. Good platforms seek to reduce developers’ toil through automation. Shifting left in this way helps shorten the software development feedback loop so developers can spend more time discovering errors during development time.
It’s not just infrastructure provisioning that platform teams can shift left. They can embed rules and checks into the code to secure the infrastructure by default. Compliance and governance checks can be performed against infrastructure patterns (like Terraform modules), significantly reducing the go-live processes that developers must follow. By exploiting the economies of scale that common patterns bring, the processes developers must follow become less invasive and more valuable.
Automation also increases the ease of use. Platforms can reduce the number of hand-offs between teams. Gates are bottlenecks are removed, giving developers a faster time to market and an easier route to production for their applications.
Technology
Many tools could prove helpful for your platform, but how well do they fit holistically in the end-to-end developer experience of your platform? You shouldn’t immediately accept re-use of the incumbent pre-platform ones, nor the default ones that come with your cloud provider. Do the tools integrate well, allowing you to compose multiple technologies into a cohesive platform? Do the tools help you automate and reduce developer toil? Can you stack the tooling to encapsulate a single golden path to solve a problem?
Sometimes, industry-standard tooling can be the easiest to use. User experience aside, shiny toy syndrome is real in IT. You’ll find it easier to locate and attract suitable candidates, and they will be able to be productive quickly.
Finding a way forward
A common theme runs through all these platform features: they help developers do their jobs more efficiently and effectively. Consistent tooling and workflows will enable scale, but platforms need flexibility for those who can’t adopt the standards. Forcing developers to work in a certain way alienates those who can’t, resulting in less adoption of your platform. Platform flexibility and differing consumption models (like No-Ops and DevOps-as-a-Service) deserve a blog article on their own, so I’ll aim to write one soon.
Clear and consistent two-way communication with developers is vital. What do they need? What blockers prevent them from doing their jobs? What repetitive, manual tasks would they like to automate? Listen to your developers and find out what they need. Then, use their priorities to drive the roadmap.
As with all major IT projects, it’s best to start small. Create an MVP that addresses a big pain point or significantly benefits your developers. Iterate on the MVP with frequent, small releases, each adding a new feature developers need.
Developers are customers of your platform, so treat them as such by focusing on the customer experience. Help them to learn and understand your platform through training aids and education. Consider embedding platform engineers into development teams to help them get started. Working closely with developers will aid you in understanding their needs and support them in getting up to speed quickly. A few key people often drive opinions and sentiments and can influence how others perceive your platform. Work to identify these people, engage with them, and get them excited and on board.
Make an effort to establish continuous feedback from developers. Find out what works for them (or doesn’t) and address their burning issues. Build metrics to measure this success and overall sentiment (e.g., by using net promoter score) and employ them as part of the platform team’s KBOs or performance targets. By rewarding and incentivizing the platform team to serve your customers, you build a culture that works to create a platform that genuinely addresses customer needs.
Finally, consider bringing in outside help who has experience building good platforms. The HashiCorp professional services team can advise you and help develop a platform that addresses developer needs, enables scale, and keeps your organization safe and secure.
