The companies we at VMware Tanzu work with are constantly looking for new, better ways of developing and releasing quality software faster. But digital transformation means fundamentally changing the way you do business, a process that can be derailed by any number of obstacles. In his recent video series, my colleague Coté identifies 14 reasons why it’s hard to change development practices in large organizations, such as security, compliance, and technical debt. In this companion series of blog articles, we’re exploring each of those topics in more depth, providing advice on how you can help approach them in your business.
Today, let’s look at the fourth digital transformation bottleneck: People aren’t using the shiny new developer platform you just built for them!
Build it and they will come?
It’s common practice in organizations to combine chosen cloud infrastructure, middleware software, and developer tools into a convenient platform to help boost developer productivity. Infrastructure teams are often tasked with this, and it can take months or even years to construct a scalable architecture that is robust and secure.
Unfortunately, in many organizations, a poor working relationship between developers and infrastructure engineers results in a platform that is built with minimal developer input and that’s designed to meet their presumed needs. Then, come the day of the grand reveal, those engineers (and management) are dismayed that the developers seem disinterested or are slow to adopt the new platform. Meanwhile, the developers are left questioning what problem the platform solves and what benefit it brings them above whatever shortcuts and workarounds they can engineer (or perhaps already have engineered!) themselves.
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
People in large organizations often assume that other teams will automatically adhere to a new agenda simply because everyone’s part of the same company. In reality, each team is driven by its own priorities, culture, and inter-team relationships. Others believe that mandating the use of a platform will solve this problem. Although that might work to a certain extent, it’s common for people to rebel against mandates. This can lead to shadow IT that eventually becomes official IT. Even if developers reluctantly use your mandated platform, they’ll likely do it in a dispirited and grumpy fashion, looking for problems with it. 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 mindset shift can have a dramatic effect on how people approach their daily duties.
Through that lens, we can now think about how a “company within a company” might approach the launch of a new product. With this mindset, the focus immediately shifts away from technology to instead identifying the target market and understanding their wants and needs. You can begin 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. Consider how you can leverage existing services to speed delivery or ascertain any constraints that might affect our solution. We’re all accustomed to the concept of market research to accomplish these very tasks, so why not apply that same approach to an internal developer platform?
When developing a platform, there are four major components to consider.
Marketing and sales
As IT professionals, we’re good at building great technical solutions, but that’s not enough. We need to clearly and succinctly articulate what problem we’ve set out to solve, how our product helps, and what improved business outcomes we 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 you might find valuable insights researching topics like “the six Ps of marketing.” Here 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.
-
Identify a champion to partner with and deliver something meaningful together. Advertise your progress.
-
Celebrate every minor step forward; the message of change is as important as the change itself.
-
Build an attractive marketing website to promote your products, mimicking what you might expect from a third-party supplier. I’ve joked regularly that one of the best investments I’ve made in my career was a $5 Bootstrap website template.
-
Identify people with decision-making power and think about 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.”
Never underestimate the power of a cupcake
Customer experience
If we agree that customers are at the core of any product, then we must look closely at their experience while 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 if they can't get it to do something simple in their first interaction, they’ll likely look elsewhere.
A 2021 survey by Sitel Group looking at the importance of customer experience 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 you weren’t able to get a laptop on your first day, you had to wade through a wall of boring training videos, 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. Research completed by Brand Hall Group found that the quality of onboarding had a direct impact on new-hire attrition, employee engagement, and long-term retention.
We want customers—in this case, our 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 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. We solved an important customer problem by giving development teams the ability to try new ideas without the headache of securing funding. The HR team included details for new engineers on their first day and as a core part of the graduate program, which helped build awareness of the platform and ensure good customer experience.
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 for doing this. Unfortunately, documentation is usually low-priority for infrastructure engineering teams, and when it does exist, it’s often too technical, incomplete, difficult to read, or out of date.
I encourage all teams to write a “getting started” guide specifically for someone 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, they will 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.
Customer service
We have all used ticketing systems and I’m not sure anyone will admit to liking them—either as a user or as an 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 you’re 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 for handling user requests and concerns efficiently. I 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 might prefer an email inbox. If the problem is complex or relates to a platform bug or 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 might seem overwhelming. But, as companies like Garmin have found, it’s actually a better experience for both parties—the developers and the operations people.
Be friendly and approachable: Make sure the team portrays a friendly and helpful attitude when communicating. This can go a long way toward building loyalty, and a series of helpful interactions will help smooth things when there are 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 might not be familiar with. Instead, use clear and concise language to explain technical concepts in a way that is easy for others 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’s happening. This can include providing a service health dashboard and 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 who can sit at the intersection of business, technology, and user experience. They help translate customer feedback into feature requests, they articulate business outcomes, and they can ultimately help define the future vision of the product.
Done well, a great customer service experience can build a loyal community of users who are more likely to use your product and, most importantly, recommend it to others. Consider building an advocate program that encourages your power users to support other users, incentivizing them through simple rewards, such as virtual achievement badges or physical branded merchandise like T-shirts, or simply by being vocal about their support.
Summary
The tendency to overestimate how others will perceive value in what we’re doing often leads teams to build products in isolation. However, by thinking of your stakeholders as customers and engaging with them early and often, you can begin to make a mental shift toward solving the real problems they face. And by working in partnership, you’ll be able to develop new solutions that transform your business in meaningful ways.
Learn more
To keep exploring this topic, check out these other great resources:
- White paper: Why You Should Treat Platforms as a Product
- Webinar: Creating a Platform Team to Support a Modern Application Platform
- Webinar: Product Centricity & Platform Engineering: Why it Matters and How to Get Started
Need help? VMware Tanzu Labs has helped organizations across the globe build and scale their internal developer platforms. Tanzu Labs offers bespoke consulting services to help foster platform-as-a-product practices that focus on meeting the needs of your developers while imparting valuable skills to platform engineers. Learn more about Tanzu Labs' platform services.
Read about other common digital transformation bottlenecks we've covered in this blog series:
- Securing Your Environment with Tools Before Rules
- Making Compliance a Feature, Rather than Friction
- 5 Ways to Cure Your Tech Debt Crisis
- The Power of a Path-to-Production Workshop
- To Succeed at Digital Transformation, Do Less
- Bottom-up Change Doesn’t Work
- How to Solve the Skills Problem
- Transformation without Belief Is a Waste
- Empowerment without Clarity Is Chaos
- Crusties Who Are Reluctant to Change
- Lack of Trust: All Talk and No Tools
About the Author
Follow on Twitter More Content by Bryan Ross
