Telling Our Story

As I've been in the process of interviewing (and now left one company and about to start at another), I've been thinking a lot about how we in the developer relations field tell our story. We're experts at helping others tell their stories, and we're great at collecting and giving feedback. However, we as a field overall are not very good at explaining our value. And because we're not all that great at explaining our value, we often get dropped into known buckets: technical content marketing, influencer marketing, pure engineering, solutions architecture... It's a lot easier for an organization to justify a developer relations professional when they can tie it to a story they already know.

Before we can dive into the details of metrics and measurement (my intended post today), I realized I needed to explain more about what I mean. Let's start, fittingly, with a story.

Back when I was working on a team of technical writers, we had a director over the team, which she had cobbled together from all of the technical writers in the company save one or two who were embedded in various product teams. That director spent a ton of time in meetings, and when actually in the office (which was rare), I could always hear her talking with various teams across the company. Sometimes, she spoke with engineering. Sometimes, support. Occasionally, the people on the other end of the line were from sales or finance or some other group far from the world of technical writers. She also was constantly gathering metrics, writing up reports, and otherwise doing a lot of behind-the-scenes work that we weren't always quite sure what exactly she did. However, it all came to a head one day when I realized exactly what she was doing.

Like many other larger companies, we had a time of year when the company would tighten belts and let go of a number of people in a layoff. Coming from a background of governments and non-profits, this fact of big company life was new to me. I had no idea just how often technical writers were the first to get let go, especially if they were embedded in product teams. We found out very quickly that the technical writers in our org who had not been condensed to our team were let go. And then our director told us that she had to let go of part of our team early that morning. The other technical writers on the team, who had long been part of these kinds of rounds and had each been laid off more than once, noted that it was a lot less than they had expected—they all had expected the team to be laid off almost completely.

Turns out, all of those reports and metrics and meetings were part of a larger story. Rather than explaining technical writing in the terms that fellow writers understood, our director was weaving us into the company's overall story—in this case, she proved how much support phone time was saved by having readable docs, how we impacted the NPS score overall at the company, how we prevented X project from overrunning budget by having API docs for a similar project that ended up merging together, etc. By having us all under her, she was able to shield the team overall from the worst of the layoffs because she pushed all year long to prove our worth. So, when the meetings were held among managers to make decisions, cutting the whole team wasn't even on the table. (If you're reading this: Thanks, Laura!)

I think about this story a lot when I'm thinking about developer relations as an industry. We discuss how to figure out which metrics to choose, how to help our communities grow, how to explain community growth. But do we sit down and think about how to weave ourselves into the company's story in a way that makes sense to everyone else? When we sit down in an interview, we're expected to tell our story and give examples of a time we failed, or shined, and how that impacted the people around us. What if we took that attitude every day? How can we give examples that relate our work with our impact in a way that would convince someone of the value of our industry to the things they care about?

All of the metrics we can collect in the world do nothing for us if we can't set them in the context of the larger picture. It's important to tie those metrics to the community's and company's goals, but it's also important to use those goals to figure out which metrics are worth finding, including ones that maybe you wouldn't consider yours (such as the average time a support phone call takes or the NPS score for the support team).

Writers half-joke about sitting and waiting for the characters to tell them their story. In our case, there are a lot of things that we can use to demonstrate our value to a company, and a lot of it isn't immediately obvious. We need to sit and listen, metaphorically, to find out which metrics are wanting to connect to us and help us explain our value to people who may just want to drop us into a known bucket. If we take the time to drive our own story, we can avoid letting others define our worth while defining who we are as an industry along the way.

What do you think? I want to hear your thoughts! Reach me in any of the following ways:

• Post to me on Mastodon at @nimbinatus@hachyderm.io.
• Find this post on LinkedIn via my profile, comment, (and follow me while you're there!).
• Tweet at me at @nimbinatus. (I'm not on Twitter much these days, to be honest.)

Did you find this useful? If so, share it with a friend so they can subscribe.

If you want to post something about developer relations strategy, metrics, or our industry so you can share with others, drop me a line!