Fun with a newish devrel team and the pivot to b2dev

I’m embedded in a newish (~1 years old) devrel team as the sole dev docs writer with my latest client, and I have to say, it’s a lot of fun! Here are some of the contributing factors:

• The client is making a massive pivot from selling to a non-tech market, to selling to developers. I call this “business2developer” or “B2D” though Google doesn’t seem to think this is much of a popular term
• The devrel team thinks a lot about how to strategically use the docs that I write
• They’re a great resource for strategic questions about WHAT to write – who’s the audience? what are the use cases? what should the examples focus on?

Let’s touch on some of these points on why my work is so fun right now:

The pivot to a developer audience

The client used to sell SaaS to large enterprise, whose users were nontechnical. Their docs were more of an internal reference for dedicated support to work with these customers, or for advanced users who’d already been sold the product. Now, their docs need to become more much of a technical sales & evaluation tool: they’re still selling to enterprise, but the individual developer has a much larger role in the sales decision process, so their docs need to be highly technical and attractive to a first-time evaluator at the same time. That means they’re willing to invest in docs improvements, which is where I come in. Yay!

As a corollary, they’re working hard on improving the developer experience (DX) of the product itself – and “product”, in their minds, DOES include the SDK! So right now, I’m helping align an SDK overhaul with a UI overhaul by being the canary in the coalmine in regards to domain model inconsistencies – more on that in another post.

The devrel team helps me think strategically

So, strategy is an interesting topic for me, especially since I read How to tell if you’re a content strategist and realized it mirrored many of my own thoughts. What does it mean to be a ‘dev docs strategist’? In my knee-jerk view, it means thinking more like a marketer at the cost of becoming less technically familiar with the product… and I have to admit, it would be hard for me to let go of the addictive quality of learning new technical topics & then writing about them. I like to go deep, in other words. And in my experience it’s very hard to constantly switch between deep/detailed thinking about the docs, versus thinking about how to make those docs visible at a high level – inbound linking strategy from other sites, for example. The sort of ‘strategy’ that comes naturally to me is the sort of stuff Tom in Write the Docs outlines that fits more with “deep” docs work:

• Evaluate whether the content addresses user needs and uses language that matches into your user’s lexicon.
• Analyze competitors docs, interview product owners, & incorporate user feedback to reorganize navigation
• Ask searching questions (of multiple people, since you’ll get different stories) to suss out the true value of a feature, and explain that in the topic rather than assuming prior knowledge of that value.

I feel like I could sum up the difference between “deep docs” strategy and “devrel” strategy by taking our docs Welcome page as an example. When I first join a team, the welcome page is something I’ll look at with a very critical eye, and try to improve. But 6 months into working on the docs, I rarely think about the welcome page; I’m too wrapped up in the intricacies of internal docs linking strategy & organization. The great thing about being with a devrel team is that they help me not to forget the Welcome page; they’re still thinking about how people arrive at the docs; still helping me rethink docs at the beginner level when I’m already deep into ‘drunk the product koolaid’ land.

B2D means dev docs improvements are necessary and valued

A lot of the work I do as a dev docs writer isn’t super visible; it’s hard/complex to write meaningful OKRs and metrics around docs. (here’s a stab at it from a 2020 WTD unconference. So, I like to know that there’s a “let’s do the docs right” attitude that goes hand in hand with selling to developers – it means that if I dig into a confusing aspect of the SDK reference and improve it, 1. I know that it’s because I’m reacting to developer customer feedback, and I also know that even if I don’t directly hear feedback from customers on the improvements, I feel more directly that 2. I’m connecting to the overall goal of excellent devX by creating excellent docs.