Reverse DevRel: The core engineering skill you've been missing

It's not uncommon for programmers to forget that we're building products for people -- like, real, actual breathing and thinking human people. We get so caught up in technical details that we forget about the people who will be using our products. I'm certainly guilty of this myself - I'll spend so much time just getting something working that I forget to think about how it will be used.

The result: we build features (or worse, entire products) that are difficult to use, or that don't solve the problems that people actually have.

One great remedy to this is to get feedback from users early and often. This is a User Experience skill that I'd be happy to talk endlessly about - and I've certainly written about UX in the past.

But there's another skill that I think is just as important, and it's one that I think is often overlooked: DevRel.

DevRel stands for Developer Relations. It traditionally focuses on building and nurturing relationships between companies and the developers who use their products and services. DevRel professionals, also known as developer advocates, do this by producing videos and articles, and providing support to developers by serving as the liaison between the company and the developer community.

Communicating with end users and iterating on features by responding to feedback. Doesn't that sound like something every engineer should be doing? Do you do that?

DevRel is typically about building better things for developers. If we turn the DevRel model on its head and ask engineers to think of part of their role as being a developer advocate, we can use it to build better products, and to uplevel our teammates.

I'm lucky to get to work with some exceptionally talented people - one of whom is CJ Avilla. CJ is a seasoned engineer and developer advocate, and he's done a great job of making sure that at Craftwork, our DevRel muscle is strong. He will often use devrel superpowers to get feedback on features as they're being built.

It's typical for CJ to send a quick video to the team to show off a new feature he's working on. He'll narrate the video, explaining what he's working on and why. He'll show off the feature, and then ask for feedback.

This is a direct opportunity to ask things like:

• Does this make sense?
• Is this what you were expecting?
• Is this useful?

If you've worked with engineers who are disconnected from your end users, you know how valuable these questions can be. They build empathy and trust between the team and the end users. They help us build better products.

The use of screencast video is super helpful here, too - it's much easier to digest than a long email or a Slack message. It also creates two important types of empathy:

1. By demonstrating the features we build, we're forced to use them, and feel any UX pain points that might exist as a result of the implementation. This creates a better end product.
2. For those watching demo videos, it's much easier to see the person behind the feature when you can see their face and hear their voice.

The effectivity of this approach is contagious. As we build out new features, the rest of our team has started to follow the same patterns outlined above. In my experience, this is the type of experience that would be absolutely unheard of for brand new engineers. Connecting what's being built with who it's being built for is invaluable, and not something that can be gleaned from leetcode. It's a skill that's learned through experience.

To quote the world-famous developer advocate Missy Elliot: take your DevRel, flip it, and reverse it

As far as I can tell, nobody has written about reverse devrel, because it's a term I just made up... you can imagine how that complicates things. That aside, here are some great resources to dip your toes into the wild world of engineers who talk to people:

This book by Mary Thengvall is a great place to start if you're interested in learning more about DevRel.

Another great read, by Reiko and David Meerman Scott - while not directly about DevRel, it's a great book about building a community around your product. Building support and momentum for what you're creating is

Loom makes it super easy to make quick screencasts. At Craftwork, we use it frequently to record quick videos to share with teammates. It's a great way to get feedback on features as you're building them, and couldn't be easier to use. Their free plan lets you make 25 5-minute videos - which is more than enough to get started.