Developer Relations is Developer Enablement

This post was originally published on my DevRel Medium blog.

I’ve been thinking over the past few months that everything we do as developer relations practitioners is about enabling developers.
Our activities may differ, and so might departments and organisations, and of course our job titles, yet we all have this one thing in common.

Of course, developer enablement is far from being exclusive to DevRel, or even developer tools companies in general. (Or even software, but that’s a whole new can of worms). I would even argue developer enablement is crucial for all software teams to succeed. In this post I am going to expand on this thought, and explore how thinking about enablement can help us serve our communities better.

But what do I mean by enablement? It’s all the activities that help someone — enable them, to become better at what they are doing. It’s removing the unnecessary obstructions that keep someone from being their best self. This will increase their satisfaction with the work, and in turn increase their output, and let them improve even faster.
And about that someone — could be a single person, or groups such as teams, whole organisations, or entire communities.

Enablement is not a zero-sum game, enablement means everybody wins.

The truth is that enablement is far from being new, and pretty much every team is doing it in some shape or form. How so? Take a software development team, for instance:

Enablement is onboarding a new colleague. Getting them up to speed with the systems faster. Introducing them to the rest of the team. Showing them where the good coffee is.
So is a senior engineer mentoring a team member, teaching them best practices and helping them hone new skills.
Enablement is also a line manager listening to her report and ensuring they get to work on projects they are most passionate about, use the tools they want to use, and ultimately grow in their career. I could go on.

And the enablees? (that is a word, yes) They can contribute higher quality code with fewer defects. They are able to ship features faster. As they see the fruits of their labour they are more likely to stay in the company for longer. They will in turn teach, mentor (and enable) others. It’s not a zero-sum game, enablement means everyone wins.

The same thoughts could be directly translated to DevRel as well. As a matter of fact, enabling developers is why we exist. Enabled developers are productive, less likely to churn, and better suited to champion our products and services inside their teams, organisations, and wider networks.

Incidentally, enabling developers and removing barriers is also everything that is in our power as advocates. Unlike dynamics inside of software development teams, we sit outside. We live part way between communities and the companies we represent. We can mentor, suggest, teach, and connect individuals, teams, and organisations, yet we cannot directly influence their actions. In that regard, pretty much everything we do, and what we can do, we do to enable people.

Writing documentation? Check.
Producing tutorials and how to guides? Yep.
Building prototypes and finding flaws in your onboarding flow? Naturally. Attending events, either just to interact with the attendees or to speak? (Mic) Check.
Answering questions on StackOverflow or Reddit? Upvote. Even on Twitter, for that matter.
I could go on, and on, but you get the drift.

The reach and intensity of our interaction can vary greatly. A one on one conversation with a developer at a hackathon is completely different in reach from a blogpost, yet an individual conversation can be also much more impactful and valuable to that single developer than a blogpost is to its tens of thousands of readers. Both can be examples of successful enablement, and both are valuable.

Developer relations is throwing stuff at the wall, and enablement helps us see if it sticks.

Another dark truth about our line of work is that finding new activities for developer evangelists or advocates is hardly a science. Every product is different, and every community has its quirks. Best way I’ve heard it described by several seasoned developer advocates and community managers was “throwing stuff at the wall and seeing if it sticks”. I see enablement as a good way to see if stuff sticks. Once we have tried a new activity or produced some new content, we can ask ourselves a few questions around enablement, that will help gauge its success:
In what ways have we enabled a particular community through our activity?
How does this help someone at their job? Does it help at all?
Have we greatly impacted a few individual people? Or have we helped a large number of folks a bit?
By putting enablement of developer communities as our goal, we get to ask all these questions, and more.

To summarise, enablement of developers is front and center of developer relations, and should be seen as the ultimate objective. It takes many shapes and forms, and that’s perfect. Every person and every community are different, and there are different challenges with each.
Enablement is also what we as developer advocates are best positioned to do, and also the only real power we wield.

At least it’s a superpower though. 🦸‍♀️🦸‍♂️🥑