DevRel Maturity Model | Existing Articles About Org Structure

[j12y]

Did you write or read a blog post about what the devrel org structure should be? If so, add a comment below (one comment per article) so we can review and discuss.

[anajsana]

We usually talk about DevRel roles in corporate contexts, but I wonder if it’s also worth considering how these roles look within foundations (LF, Eclipse, Apache,) In those cases, the org chart tends to be a bit different from a typical corporate setup 🙂

[anajsana]

Sharing a list of links (I will add new ones during these days)

• (blog post Jan 2023) https://blogs.newardassociates.com/blog/2023/where-devrel-fits.html
• (blog post 2019) This content comes from a blog I wrote long time ago: https://bitergia.com/blog/kpis-and-metrics-for-devrel-programs/ but Perhaps the topic is a bit outdated

[arun-gupta]

I was literally thinking about this topic and a discussion on LinkedIn this morning. There are some dated articles but I'll capture my experience in the next couple of days.

[arun-gupta]

I began writing about the maturity model, and it evolved into a much larger post. So, breaking it down and instead posted my thoughts on DevRel reporting structure as the first step: https://www.linkedin.com/pulse/devrel-reporting-structure-arun-gupta-mjbwc/.

[j12y]

I really like this article but I'm going to put on a Deviloper Advocate hat and offer a rebuttal for having a discussion.

I question whether there is a fallacy built into articles and presentations about DevRel like this that we've all just accepted and carried the weight of.

There is no “perfect” structure for DevRel. Each model carries tradeoffs, and the right choice depends on the company's stage, priorities, and culture.

I feel this, don't get me wrong, but what if we just categorically stopped accepting it?

Could we adopt definitions that assign an alternate label that more closely reflects an alignment of the stage, priorities, tactics, expectations, and goals of that role with each structure in mind?

Imagine that there was no more DevRel within an org. Instead we replace it with:

• Under CMO/Marketing, this is Evangelism and/or Field Marketing
• Under CPO/Product, this is Advocacy and/or Engineering
• Under CTO/Engineering, this is Experience or Growth Engineering
• Under Sales, this is Pre-Sales Engineering
• Under Operations, this is Support or Solutions

DevRel would no longer fit under one org but be an amalgamation of tactics in a matrix organization across each department. Under a General Manager, ok, maybe this is the case for still using the DevRel label but then would have staff that fits into any of those categories.

Labels come with baggage so putting the specific examples aside for a moment, maybe that sounds preposterous, but so does the idea that other organizational roles just show up wherever in an org chart.

We decided to put Product Marketing under the CTO and they now build the SDKs because YOLO.

¯\_(ツ)_/¯

That doesn't seem to happen but with DevRel it is embraced at our own misaligned peril.

I think an interesting proposition the DevRel Foundation could offer is a standard that reflect the maturity of an organization and recommendation for using labels, job descriptions, and organizational goals to match function with purpose and disambiguate Developer Relations. Certainly not all organizations would comply or adopt new terminology, but over time and with enough awareness and support it could give leaders of those organizations some ground to stand upon in giving clarity to their roles and the resources/support expected to succeed.

Is ambiguity of the term $DevRel today equivalent to an organizational widget of Acme Co or could the DevRel Foundation develop a standard that helps us with more precise terms for each org structure for industry to adopt so that we can say what we mean and be clearer when communicating expectations?

[j12y]

Putting it another way, I'm hopeful we create a document to be prescriptive... given $problem-goal you want a DevRel<type> team with the following objectives and kpis to guide it. This is set of tactics within their scope, these are outside of their scope and should exist elsewhere in the org.

[bguiz]

Here's a 4 part articles series, about devrel, where the target audience is marketing teams:

• Index + summaries: https://handsondev.substack.com/p/developer-relations-for-marketers
• Trust is Built in the Trenches, not through Marketing: https://www.tessakriesel.com/developer-relations-trust-is-built-in-the-trenches-not-through-marketing/
• How to Position DevRel within a Tech Company: https://www.docu.agency/blog/how-to-position-devrel-within-a-tech-company
• The Marketing Funnel Applied to Developer Audiences: https://blog.bguiz.com/2024/marketing-funnel-applied-developer-audiences/
• From Developer Friction to Flow: The Fundamentals of Developer Experience (DevEx): https://biancabuzea.com/from-developer-friction-to-flow-the-fundamentals-of-developer-experience-devex/

[bguiz]

Here's an article I wrote about metrics: https://blog.bguiz.com/2024/devrel-team-okr-planning-strategy/

• accompanying youtube video walking through it: https://www.youtube.com/watch?v=6UBAHgSmi2U&list=PLjyCRcs63y83VNtUOZ42Z3kCerHhOMKDu&index=1
• accompanying spreadsheet template: https://docs.google.com/spreadsheets/d/1UjiQ8ce1Fper6jY7e8VUKaeBjT8sbXwnvYZykjVTuTE/edit?gid=0#gid=0