Developer Experience Specialists ✨ — Digging Deeper Series 🔥
I hope you all have bought your shovels ⛏, because today, we are back with the last blog of DevRel.Page’s “Digging Deeper” series
Today, we’ll be digging deeper into Developer Experience Specialists — who exactly they are and what their role is. Now, it’s important to understand that Developer Experience can be widely interpreted based on the type of companies making those changes, and not to forget there can be dedicated teams for Internal and external developer experience separately. When it comes to developer relations, we want to focus on external developer experience in this blog. We’ll be covering internal developer relations in a separate carousel very soon!
But! Before we dive into that make sure you have checked out our last blog on Developer Community Managers of the Digging Deeper Series!
What is developer experience?
One of the simplest ways to define developer experience would be as “user experience specifically for programmers”. The term “experience” here means those interactions, touchpoints and the feelings that they lead to a developer when working with a product.
Most developer-centric companies have now adopted Developer Experience (DX) teams or DX specialists, who prioritize developer experience for programmers. But the main thing to point out here is that we need to focus on Developer Experience Specialists in the field of Developer Relations which is quite not like the normal developer experience, that tends to focus just on the experience, but something much larger but at the same time specific to the just developer relations.
Who are DX specialists?
Developer Experience or DX specialists are like de facto product owners for anything the developer uses, i.e they might be owning the product experience, working with developers to cater to their needs better, and maintain the feedback loop. DX specialists generally tend to own more towards onboarding flows, SDK/API design, and documentation, which act as the pathway for developers to understand and get used to the product.
It’s also key to understand that when Developer Relations is positioned under product teams, the developer experience might be handled by their developer advocates and content writers directly. When developer relations is aligned towards marketing, we might quite often see dedicated DX specialists working directly with the product team. Although still, the DevRel and DX teams will be very directly connected since the feedback loop generally goes through Developer Advocates.
What do they actually do?
Let’s look at how we usually look at a product. Think about what runs across your mind when you are using any product for the first time — the first impression you have. Developer Experience Specialists regularly explore a developer’s first impression of the product with the aim of making it better and better.
They also work on those by figuring out touch points throughout the developer journey with the product which in turn helps them shape the experience of working with the product in a much better way. A major part of their job might also be around creating onboarding flows and API designs that complement the developer behaviour.
But, what is an onboarding flow? In terms of UX, onboarding flow would be introducing the product, app, or feature to a user. The onboarding flow may also involve guiding the user through completing a few tasks, such as setting up an account or setting preferences. In terms of DX, it would mean the same thing — tasks like guiding through the initial setup, local deployment of the codebase or figuring out the first interaction..
DX specialists, like mentioned before, are also expected to own API and SDK designs which is making sure that the developers have the right experience in terms of the callback actions and flows while using the APIs/ SDKs. This also includes a lot of documentation, tutorials, etc. available to let developers navigate around the services more effectively.
Figuring out the Developer Touchpoints
From the first impression to onboarding to actually being an active developer, there are multiple places a developer goes to figure out what actually works for them. Each and every interaction a developer makes with the product is referred to as a touchpoint.
The First Impression
Your website and the initial introduction pages are always the first touchpoints any developer/ product manager sees. These pages set the initial impression in their mind, of whether the product is worth exploring or not. It is important to regularly take feedback and improve upon these pages since the drop off rate is the highest at this point. Some common touchpoints include:
- Landing Page
- Product Pages
- Getting Started Guide
- FAQs
Onboarding Touchpoints
The next crucial touchpoint that comes into the picture is the onboarding touchpoint. At this point, the developers actually start to interact with the product. This is where the learning curve of the product matters. Here, the job of the DX specialist becomes to actually understand and accordingly structure the onboarding flow to make sure everything is well communicated to the developer exploring the product. A few common touchpoints here:
- Sign up/ Registration
- Documentation
- Tutorials
- Code Samples
- Learning Resources
- Training
Further Touchpoints
At this point, Developers actually start building on top of the project and using it for their purposes. This is where regular feedback comes into place. Developers once onboarded and interested in the product, tend to give a ton of feedback and requests on what is needed for further improvement. It is necessary to have a proper feedback loop and interaction with the DevRel team to understand what needs to be prioritised first in the pipeline. Some common touchpoints to look out for
- Extensions (The new community extensions being developed/ requested)
- Sandbox
- Reference Guide
- Change log (The community’s reaction to latest changes in the product)
Further, the touchpoints can also be divided into Internal and External Touchpoints. Internal Touchpoints basically refer to the properties and content that the company owns and controls. Examples of this include the website, documentation, code samples, support, social media, etc. On the other hand, external touchpoints are where the company doesn’t have direct control, however, they are key resources and channels to reach both your existing users and your potential future customers. Examples include developer-focused media, industry analysts, 3rd party communities (dev.to), external forums(StackOverflow), etc.
What is Structured and unstructured content?
Every DX specialist works directly or indirectly with content. Being a DevRel, one of the major things one works with is always some form of content. DX Specialists generally work in producing structured content. Structured content refers to content that follows a particular structure for the audience to continue reading and figure out the whole product/ feature it is focused on. This contains mainly documentation, serial blogs and certification courses offered by the company. The documentation, like any other, can cover the product’s API, features, and other aspects. Sample templates that developers can refer to when getting to know the product is also structured content. Video series or live streams can also fall under the same category, provided they follow a structure. Structured content is a great way of educating developers on how to utilise the product’s various features and helps the support team expectively in navigating developers to the right place as well.. Generally, structured content is developed by the internal team and requires proper planning and execution on a timely basis.
On the other hand, Unstructured content contains blogs and articles that may or may not be directly related to the product directly. These can be SEO focused, current hot topics in the community, a collaboration with another company or just small tutorials that need to be drafted to maintain the regular stream of content going out. DX specialists generally tend to not focus on this as this rarely is directly related to the product support aspect. The best part about unstructured content is that it requires very little work as compared to structured content and can be published by either the internal team or the external community, the former being a driving force in generating proper feedback for internal teams as well.
Internal Content
Internal content refers to the content developed by the internal team within the company, be it the DevRel, Developers or the marketing people. It is usually in the form of blogs, social media posts, sample workflow/apps/use cases, and ideas to interact with the product in a better way, documentation or a getting start guide. It’s a no-brainer that internal content usually has a larger and more varied audience in most cases as you are going to the visitors rather than they coming to you. It’s the content put out there by internal teams and hoping it reaches the interested parties. Generally, Internal content is structured (for educational/ product focused ones) or SEO targeted (for marketing ones). Also, it is often seen that the reuse of internal content is very common Generally, internal content is quoted in multiple places as the official source on a particular product.
External Content
External or Community content is the content created by the community members/ users of the product for their love and experience of using the product. This is something that makes those community interactions successful. Many times, this content tries to fill the information gap that exists in the official documentation and blogs by the company. Community members generally take this initiative to help support their own teams using the product alongside favouring the development in the direction they’re looking for as well. Many newcomers also tend to share their experience of using the product for the first time which is extremely crucial for DevRel and DX teams in finding out the touchpoints.
But, generating community content needs a lot of effort from the company’s side. Either your community is so dedicated that they take these initiatives on their own or it becomes about implementing programs around external developers and providing them incentives to share their experiences using the product. Different companies have different approaches to structuring these programs. It can be about sharing experiences, generating tutorials, making sample apps, automation, throwing off ideas etc. We can even ask the community to focus on a particular aspect of the product, varying monthly, and create content around it. The only thing to keep in mind is that the incentives should also give back to the community members for actively producing content and for the time and efforts they are putting in.
Summary
To sum it all up — Developer Experience Specialists in the field of Developer Relations is not quite like the internal developer experience. With the rise of the customer-centric approach, organisations have now realised the importance of managing, understanding and catering to the needs of external developers too, especially if the product is targeted for developers. DX Specialists become a bridge between the internal and external developers which not only builds great relationships but also helps the organisation grow in a multitude of ways that weren’t open before.
This wraps up the DevRel.Page’s Diggin Deeper Series 🔥 If this is the first time you’ve read our blog, make sure you check out the rest of the blogs in the series linked below!
Make sure you follow our official Twitter handle to stay updated — we will be releasing a carousel and blog, focusing on Internal Developer Experience Specialists very soon!
Au revoir 👋🏻
…
People in DevRel — What do they Actually do? #1
Developer Advocates 🥑 — DevRelCarousels #3
Developer Evangelists 🚀 — DevRelCarousels #4
Developer Relations + Product — DevRelCarousels #5
