There are numerous other experiences from which we can learn as we deliver solutions for our fellow developers. These experiences can help us identify areas where we can improve and continue to innovate in the platform space to assist our developers in supporting the missions of our companies.

Every industry has its own unique approach to creating an excellent experience for its customers. For example, theme parks focus on providing a "magical" experience for their guests. They consider how guests move through the park, how to set the stage for guests, and even offer ways to skip lines. Roadside assistance services provide both paved road solutions and support services. They help drivers throughout their journey, not just when they have an emergency. We can also learn from how doctors and clinical professionals approach patient care. By applying their care model to building platforms, we can build better and more compassionate relationships with our developers.

Terrible Experiences

Let’s start by considering some potentially terrible experiences:

• Standing in a never-ending line at a theme park 
• Being stranded on the side of the road with no help
• Discomfort in a medical appointment

These are situations that we often dread or fear. Not the kind of experiences that you’d often want to encounter, much less recreate. Now think about what you might dread or fear about your development experience.

• Waiting days for code review
• Spending hours and hours fixing your local development environment
• Getting help from a peer who doesn’t make you feel at ease

These are what I’d call equally poor experiences when it comes to developing software.

I love learning patterns, trends, and models from other industries and applying them to my own work. I think there’s a lot we can learn about customer service from these interactions to make magical, joyful, and compassionate experiences.

In this article, we’ll look for patterns of delightful experiences in places that are not always known for it, and see how we can apply these and take more customer-minded approach to our platform teams. I’m going to focus on general development experience, but this is applicable for any experience that you care about, internal or external, whether you’re on a platform team at all.

Theme Parks

How many of your fellow developers would agree that their development experience is “magical”? But what is “magic”? Let’s go to the source itself, Disney.

For the magician:

“The show is a highly practical process made up of a series of meticulously planned, well-rehearsed steps that are designed to delight the audience.”

Apologies to our kid selves, but magic is not magic to the magician. If magic is just meticulously planned experiences, what could that mean for our development experiences?

Understand Your Customer

We should set up regular feedback loops that we can use to understand our developers. Disney is constantly listening: before guests arrive, throughout their visit to the park, after guests arrive home. Once Disney knows who their guests are and what they expect, they can work to exceed their expectations by delivering consistently and continuously.

So how might that translate for our development experiences?

• Setup dedicated Slack channels
• Run post-experience surveys
• Gemba: meaning “the actual place” (where the work is done), which means shadowing people working and learning from their experience

Measure Wait Times

Everyone at an amusement park hates to wait in lines. Developers hate waiting too.

“No matter what the specific service or product being delivered, wait time is the enemy we are all fighting.”

Disney found that alternatives like a FastPass system that allows people to self-manage their own time, choosing where to prioritize a faster wait time when it counts, actually improves overall park efficiency. Giving control back to your customers is another key to a magical experience. So what might that mean for our development experiences? 

Map out the development experience and monitor where developers are getting stuck on tools or processes that could be better designed or utilized for efficiency, such as:

• Broken tools
• Flaky tests
• Red builds
• Bad docs
• Slow deploys

Where are your developers just waiting?

• Setup: local environment setup time
• Test: unit tests, integration tests
• Review: code review, getting UAT
• Build: local and CI pipeline timing
• Deploy: lead time plus the actual deploying itself

So I want you to think about the difference between a lousy day at a theme park and a truly magical experience.

How might you create a “magical” experience for your developers and peers?

Roadside Assistance

Let’s talk about driving. 

Last summer I got the opportunity to drive on the island of St. John. I was particularly excited to see the other side of the island that I hadn’t been able to reach in the past. But here’s the rub: cars in St. John are left-hand drive (like the U.S. is) but also left-hand traffic (driving on the left like in the UK). Plus, in previous trips, I had really only seen the nice waterside paved roads.

On the map you can see the top left, where I left Trunk Beach on a nice and paved road. But what looks like a nice shortcut on the top right, was actually a one-lane road, narrow, full of pot-holes and switchbacks on giant hills. I would have had no idea what to do had we gotten stuck out there. Off-roading can be fun, if you have the right car, the right equipment, and the right expertise. This was not fun.

Paved Roads

A few years back, Netflix defined a paved road as:

“Formalizing a set of expectations and commitments between the centralized teams and our engineering customers.”

For our platforms, the notion of a “paved road” is a recommended way of getting something done.

Imagine the difference between the joy of driving an autobahn versus a pot-hole-filled back road. Getting from point A to point B, there are often off-road solutions that are less supported, less maintained, and create more cognitive load to use. In St. John, I was solely focused on driving and not making mistakes. Not fun. A paved road creates a new solution that is better supported, better maintained, and often joyful. 

So what might that mean for our development experiences? It could be as simple as a script and as complicated as a developer platform but look for opportunities to reduce cognitive load, plug some potholes or create entirely new roads.

What are the things your developers keep running into, maybe even giving them a flat tire along the way? And, importantly, what does it feel like to use your platform?

Getting Help

And what if we get a flat? Roadside assistance is continuously being able to provide support for where our customers are at. 

Getting stuck on the side of the road is not what your customer intended and they probably did not plan for it. When we interact with a developer who has an issue, they probably didn’t plan to have that issue either.

But they’re stuck either way, and they’re frustrated.

Fixing their flat is great, but recognize that you’re solving a problem they didn’t intend to have in the first place. They hoped to use your slick new super-highway of a paved road to get to a particular place, but they needed help.

So what might that mean for our development experiences? Answer the question behind the question for your customers; get them to their destination. Don’t just fix their immediate problem by fixing their flat, but ensure they get to their destination because that was their purpose to begin with.

The paved path should be what your developers want to do! But enough flat tires and folks will stop using your nice paved roads.

How might you create a set of paved roads and excellent roadside assistance for your developers?

Doctor’s Office

Let’s talk about the doctor’s office. It is often a stressful interaction, with many unknowns, coupled with being sick, hurt, or scared about what could ultimately be wrong. The healthcare industry can have a reputation for being cold, simply out to make money off you by running tests, prescribing expensive medication, and using confusing medical jargon.

C-I-CARE

I was first introduced to this mnemonic of patient care when I started at One Medical and it’s something that both our clinicians and our corporate staff use daily. C-I-CARE stands for the steps we use in personal interactions: Connect, Introduce, Communicate, Ask Permission, Respond, and Exit. It was developed to address poor patient experiences and focus on the most important elements of human interactions. At its core, C-I-CARE is about treating all people with the utmost compassion and demonstrating respect for their time, needs, and emotions.

Let’s dig into how we might use this with the developers who use our platforms, bringing care and compassion to our interactions. C-I-CARE is a concept that’s now used in many places, but we’ll look into how we at One Medical use it specifically.

Connect

The opportunity at the beginning of the interaction to relate as human beings (before diving into clinical or other work) and begin to form a relationship.

Our customers are also our colleagues and they’re often just a Slack message away. But just because we have more informal communication lines with our users, there is no less incentive to connect with empathy. A request in Slack from an engineer is often one of the last steps they’ve taken in a potentially frustrating experience of encountering an error or being blocked from doing their work.

Building relationships and creating specific feedback channels create safe spaces for our developers to bring up issues and know they’ll be heard. If people feel their concerns won’t be heard, they’ll stop sharing. And if they don’t share, we lose a crucial feedback loop that makes our jobs even harder to improve their development experience.

Relating to your users as fellow human beings first, then as developers, is key.

Introduce

Introducing ourselves is a way of humanizing our interactions; taking us beyond transactional care and into relationship-building.

Taking time to introduce ourselves, our name, and our role, sets the stage for why we’re connecting. People want to know that you’re capable of helping them, and introductions help confirm that they’re in the right place with the right people.

As a developer, it can be easy to want to solve an issue quickly with a link to some documentation and be done with it. Why else do we have documentation? It can seem counterintuitive to spend extra time when we know that the solution is in our wiki. But like our roadside assistance partners, we should be top-of-mind for when issues go beyond a well-written how-to page.

Making sure that folks know who our team is and how we can help is crucial to relationship-building.

Communicate

Share what is going to happen, when, and how; use positive language to provide options and build productive relationships or add it to what is currently there.

Our goal in communication should be to increase understanding, on both sides. In order to best solve issues brought to our team, we have to listen.

Active listening and proactive questions that dig into the root of the issue are important to make sure we’re solving the actual problem. We must also acknowledge when we’re using jargon that isn’t always familiar to other developers. The solutions we provide can often hide an underlying layer that a developer isn’t entirely comfortable with.

Communicating in the language your coworkers understand, and proactively explaining things they don’t, goes a long way to building trust.

Ask Permission

Asking permission gives control back by respectfully empowering someone with choice and autonomy.

As we’re communicating, we should understand how a developer can be helped most effectively and what they’re comfortable with.

Asking if a developer is comfortable sharing their screen could be daunting if they’ve had that trust violated before, such as making fun of a particular editor or way of doing something. Having a developer make changes to their setup is a big area where we should be sensitive to ask first. Recognize where it’s in their interest to have them learn what to do, rather than just doing something for them. Some developers may be less comfortable with running diagnostics or commands that we assume to be familiar, so being patient with their mistakes goes a long way in furthering that trust.

Avoiding assumptions and making clear requests empowers your coworkers to be in control.

Respond

Show respect and attentiveness to someone by addressing potential questions and future needs, and sharing what will happen next.

Anticipating every issue is impossible, but as much as we can we should try to understand the issue behind the issue.

We might be helping to resolve an engineer's database, but they may have other setup issues lurking. Getting an engineer back to productivity should be our end goal, just like our roadside assistance example. Maybe you have a script that developers can run to diagnose problems. Help them understand how to use it in the future for similar issues.

Acknowledging the true issue at hand and responding to our coworker's ultimate need leaves them feeling understood and respected.

Exit

End interactions with clarity, warmth, and respect; always use endings to reconnect personally and with gratitude.

We’re grateful for any opportunity to help our fellow engineers and receive feedback on what can be improved in their development experience.

Thanking folks for their time and ensuring they know how to reach out again in the future is important, even if it is to clarify a better team to support.

With a system like C-I-CARE in mind, how might you approach your fellow developers in a more caring and compassionate way?

Conclusion

In each of these situations, you’ll notice that people are put first and customer service is paramount. We saw how you can transform these ordinary, fearful, or insensitive experiences with intention. This isn’t just for platform or developer experience teams, though; we can all consider how we build better products and better interfaces that continue to delight our users in magical, joyful, and compassionate ways.