In today's fast-paced business landscape, organizations are constantly searching for ways to develop and release software more efficiently. One powerful approach to achieving this goal is through the use of Internal Developer Platforms. Gartner recently predicted that “80% of software engineering organizations will establish platform teams by 2026, and 75% of those will include developer self-service portals”. These platforms combine cloud infrastructure, middleware software, and developer tools to enhance productivity and streamline the software development process.
However, the success of a developer platform is not solely dependent on its technical capabilities. In many organizations, there is a disconnect between developers and infrastructure engineers, leading to platforms built with minimal developer input. Consequently, when these platforms are unveiled to the development community, they are often met with disinterest or slow adoption. In this article, we will explore the reasons behind the challenges faced by developer platforms and provide actionable advice on how to overcome them.
Build it, and they will come?
Infrastructure teams are often tasked to design and build developer platforms, taking months or even years to construct a scalable architecture that is robust and secure. Unfortunately, in many organizations, there's a poor working relationship between developers and infrastructure engineers so infrastructure teams build to a specification of presumed usefulness, and then entrust developer adoption to a “build it, and they will come” attitude. Of course, come the day of the grand reveal, everyone is dismayed that the development community seems disinterested or slow to adopt the new platform. They’ll question what problem the platform solves and what benefit it provides to their development team above what they’ve already engineered themselves…or, worse for you, are dreaming of engineering.
Of course, the problem is obvious in hindsight – for any product to be successful, it must incorporate feedback from its customers and solve a real-world problem that they face.
Developing with a product mindset
A common problem in large organizations is to assume that other teams will automatically adhere to your agenda simply because you’re all one company. In reality, each team is driven by its own priorities, culture and inter-team relationships. Specifically, much like the outside world, you must engage with stakeholders early and impress upon them the benefits to them by supporting your initiative.
You might also think that the power to mandate platform use will work. It will to a certain extent, but it's common for people to build up, well, rebellions against mandates, leading to shadow IT that eventually becomes official IT. Even if developers reluctantly use your mandated platform, they’ll do it in a dispirited and grumpy fashion, looking for problems. This is often a strategic first step in defeating your platform mandate in favor of replacing it with their own solution. In short, if you're building a platform for developers, you need them to be excited about using the platform.
In previous leadership roles, I’ve encouraged my technology teams to think of themselves as a company-within-a-company and their colleagues as customers, rather than users. This simple mind shift can have a dramatic effect on how we approach our daily duties. It reminds us that our purpose is to serve and that there’s more to consider in operating a platform than simply the technology.
Through that lens, we can now think about how a company-within-a-company might approach the launch of a new product. The focus immediately shifts away from technology to instead identifying the target market, understanding their wants and needs, and beginning to build a picture of what an improved journey for those “customers” might look like and then, finally, what a possible solution might look like. We might also consider how we can leverage existing services to speed delivery or ascertain any constraints that might impact our solution. We’re all accustomed to these concepts in relation to companies launching products, so why not apply that same approach when we launch an internal developer platform?
Four major components to consider when developing a platform
1. Marketing & sales
As IT professionals, we’re good at building great technical solutions, but that’s not enough. We need to be able to clearly and succinctly articulate what problem we’ve set out to solve, how our product helps, and what improved business outcomes we can expect as a result. I’ve had the privilege of working with some incredibly talented engineering teams who simply aren’t able to deliver the cliché “elevator pitch”.
Marketing and Sales are industries in their own right, and I would suggest you research on topics like “the six P’s of Marketing”. That said, there are five fundamental areas that I’ve found to be most useful for my customers:
- Engage with potential users early to understand and solve their problems. All too often, teams will build what they think is useful, building a solution that nobody will use or spending too much time working in the wrong areas. Incorrect assumptions can be mitigated with user research.
- Identify a champion to partner with and deliver something meaningful together. It is much easier to convince the exec, finance or other potential customers of the value of your work if you’re able to show tangible business improvements.
- Celebrate every minor step forward. The message of change is as important as the change itself. Self-promotion may not come naturally to those in IT, but it’s an important tool in demonstrating your commitment to continuous improvement.
- Build an attractive marketing website to sell your products. Mimic what you might expect from a third-party supplier. I’ve joked regularly that one of the best investments in my career was a $15 Bootstrap website template.
- Think about the people that have decision-making powers and how you can reach them. I’ve personally had success with a viral laptop sticker campaign, branded cupcakes, and engaging with third parties to help deliver my message as part of “developer day”.
2. Customer Experience
If we agree that customers are at the core of any product, then we must look closely at their experience whilst buying, using, or getting help with that product. Irrespective of industry, customers generally have a low threshold for complexity or delay - if they cannot quickly understand how a product might help them or get it to do something simple in their first interaction, then they’ll likely look elsewhere.
In a 2021 survey by Sitel Group looking at the importance of customer experience, they found that “a third of consumers considered severing ties with a brand because of a poor experience”. Reasons included unfriendly staff, slow service/response, poor website experience, and lack of self-service options.
Most organizations have a poor track record when it comes to onboarding, be that bringing on new staff or providing access to IT systems. Perhaps they weren’t able to supply a laptop on your first day, or there was a wall of boring training videos to wade through, the one person who could add you to some critical application was on vacation, or maybe it took several attempts to get your permissions right for a core service. In research completed by Brand Hall Group, they found that the quality of onboarding had a direct impact on new-hire attrition, employee engagement and long-term retention.
We want customers - again, developers - of our platform to have a great onboarding experience:
- Have a simple, automated self-service capability that new customers can use unaided.
- Optimize the process for the customer, with a logical flow and using terms that developers will understand.
- Assume no prior knowledge (i.e., a new hire) and ask for the minimum amount of data.
- Give them instant access - perhaps to a demo environment or a limited trial account.
Case study: Standing Up Developer Labs
At a company I worked with, I helped the engineering team improve the onboarding experience for customers wishing to build virtual machines. Historically, new customers would need to follow quite a laborious process of approvals and provide cost-center details to ensure that any new virtual infrastructure was properly financed.
We developed a new trial service that enabled anyone in the organization to spin up temporary virtual machines that would be automatically destroyed after 30 days. These were offered without the usual service assurances - so no uptime guarantees, no monitoring or backups, and not officially supported by the operations teams. And by destroying them after 30 days, security risks and capacity costs were addressed as well.
Although arguably of limited use, this trial service gave new users the ability to try out the platform within minutes and solved an important customer problem - giving development teams the ability to try new ideas without the headache of securing funding. The HR team also included details of this service as part of our introductory pack for new engineers, helping us to spread awareness of the platform.
3. Great documentation
When assessing a product, customers want to achieve simple things quickly, and know that complex things are possible. Great documentation is the primary tool that we have available to demonstrate those, but unfortunately, is usually low down on the list of priorities for an infrastructure engineering team. When documentation does exist, it’s often too technical, incomplete, difficult to read, or out of date.
I would encourage all teams to write a specific “Getting Started” guide written from the perspective with no prior knowledge of the platform. What does a developer need to know to launch a simple “hello world” application? If you can get new users up and running with something quickly, then they will generally be more willing to invest time later to research how to achieve more complex things. Inversely, if it’s painful to do something simple, most will assume doing something complex is just impossible.
4. Customer service
We have all used ticketing systems and I’m not sure anyone will admit to liking them – either as a user or operator. They are a necessary evil for tracking problems over time, but they are unsuitable for many other types of customer interaction. The goal of good customer service is to remove frustration, not add to it!
Think about the brands that you are loyal to, and what you might expect from them when you need help:
Be responsive: Users appreciate quick and timely responses to their issues through whatever channel they are most comfortable with. Make sure to have processes in place to handle user requests and concerns efficiently. I would encourage teams to adopt a chat system, such as Slack or Teams, to help users with ad-hoc requests. Project Managers and other business users may prefer an email mailbox. If the problem is complex or relates to a platform bug/outage then by all means create a ticket for it, but most questions can be answered more quickly through chat - particularly if you can build a user community willing to help each other. At first, using chat for support instead of tickets may seem overwhelming, but as companies like Garmin have found, it's actually a better experience for both parties: the developers and the operations people. Using a chat system reduces friction and gets answers to those in need faster - after all, the purpose of support is to reduce frustration, not add to it.
Be friendly and approachable: Make sure the team portrays a friendly and helpful attitude when communicating. This can go a long way towards building loyalty and a series of helpful interactions will help smooth things when there’s problems in the future. In my experience, reinforcing the idea of users as customers can improve matters greatly - the platform team exists to empower and support developers through well-defined “golden paths”.
Use clear language: Avoid using technical jargon or abbreviations that users may not understand. Instead, use clear and concise language to explain technical concepts in a way that is easy for users to understand.
Be proactive: Anticipate user needs and proactively address potential issues before they become problems. In addition to common health monitoring of components, create and monitor end-to-end synthetic transactions that mimic common user activities. Produce a regular newsletter of platform improvements, continuously improve documentation by analyzing readership and search statistics, give prior notice of any maintenance work.
Be transparent: Keep users informed about what is happening. This can include providing a service health dashboard, status updates, explaining the resolution process, and communicating an honest and humble post-incident review with follow-up actions. Users are generally accepting of issues if they believe that the teams responsible are doing everything they can to resolve it quickly. Responsive, friendly and transparent communication with clear language is key.
Welcome feedback: Find out what your customers think and what improvements would make the biggest business impact. Consider having a Product Manager that can sit at the intersection of business, technology and user experience. They help translate customer feedback into feature requests, articulate business outcomes, and ultimately help define the future vision of the product.
Done well, a great customer service experience can build a loyal community of users that are more likely to use your product and, most importantly, recommend it to others. You want to consider building an advocate programme that encourages your power users to help contribute to supporting other users, incentivizing them through simple rewards such as virtual achievement badge, physical branded merchandise like t-shirts, or simply by being vocal about their support.
Realizing the full potential of Internal Developer Platforms
In this article, we’ve identified the tendency to overestimate how others will perceive value in what we’re doing and how that often leads us to building in isolation. We discussed the importance of engagement, and, by thinking of our stakeholders as customers, we can begin a mental shift towards solving their problems and working in partnership as we develop our solutions.
Developer platforms have the potential to revolutionize software development in organizations. By addressing the challenges of developer input, incorporating feedback, and developing with a product mindset, organizations can create platforms that solve real-world developer problems and are therefore, embraced by the community.
