Dawid Ostrowski’s Post

The biggest question with "separate org" is how far does that go up and where does it report to? Unless you have a CDRO in the executive team and board meetings, it's still part of something else. I guess you could have a VP leading it and reporting into a technically savvy COO in some companies as a way to avoid having too many C(x)O. I think the first question is how important is DevRel to a given company. If you have a consumer SaaS it's negligable unless you want to drive a lot of sales via APIs and third parties. If you are a dev tools company it's life or death. Second question I think might be maturity of the company as that might affect prioritization of the goals of the function - early stage working on product market fit, maybe you focus on product feedback and put it under a VP of Product. Over time as you're confident about fit and are focusing on scaling well tested features and messaging, maybe it goes under a CRO as a third leg along with marketing and sales? Would be fascinating to survey and see how and why people have put it into various locations!

My instinct would be for a separate org, because developing something involves multiple functions (e.g. around me, I see designers, engineers, accessibility specialists, privacy specialists, security specialists, product managers, data scientists, bizops, marketing...). I worry that having DevRel too close to one specific function will privilege only one of those groups at the expense of all others. In turn, that implies that DevRel as a whole probably needs to think of themselves as connectors and facilitators, not as gatekeepers.

In our case DevRel is a part of the Learning org at SAP.

Wherever DevRel sits in the organization, I believe the most important part is to connect the dots between departments and create a clear, unite communication, move towards common goals, understand how you can help each other. "Ew, developers" is so common and it kills the vibe 😬

Very interesting indeed. It would be even more interesting to list a handful of names of companies and what approach they have taken to be successful.

My aspiration is for Developer Relations to take its place alongside engineering, product, sales, and marketing, led by a dedicated C level executive, to get recognized as the unique discipline it is and as a driver of business value. The voice of the developer needs to be heard in modern companies. #devrel

Not sure if technical evangelist is exactly the same as DevRel (it is all kind of fuzzy) but my take: I fall easily and deeply into product. I am the voice of the community internally, speaking potentially unpopular truths that usually get stopped at gatekeepers. I know the asks, I know the pain points. Internally, I know the challenges. I am also a "hype-person". I market the product by demos, by talks, through community interaction. I know the product deeply & it allows me to speak thoughtfully & accurately in marketing campaigns. Sales, while somewhat distasteful to me (sorry!) I understand my role there also. I bring comfort & trust to customers & potential customers. Though for me personally, the idea of my relationships being transactional is unpleasant, I try to balance it against the good my efforts bring to the ecosystem. Engineering is an easy one, I've programmed for 26 years. I know code. I speak their language. I can communicate difficult concepts to both devs & business folk. So, I think the ideal setup IS a separate DevRel/Evangelism org or group. That is how (for the most part) we operate here. I report to a Director of Evangelism. My peers are all evangelists. But in my day to day, I engage with everyone.

Here's what the stats say from our https://www.stateofdeveloperrelations.com/

Developer relations with goals around awareness and adoption may find it difficult to fit in a sales organization. Most sales orgs have targets and goals set each quarter driven around revenue. If a direct mapping of devrel to such numbers don’t happen then the devrel teams can suffer.

This is a great illustration, Dawid Ostrowski. Showcases how DevRel impacts multiple functions within a business. If I were to make a small suggestion, it will be to expand this illustration to include another column for the "Goals/KPIs" of each team. For eg: Marketing - leads and brand awareness Sales - deals and revenue Product - product education & trials My take on this is that DevRel should be its own function with its own team lead/head. Being part of other functions automatically ties you to that function's goals and KPIs and any activity that is undertaken will be judged through a singular lens. There is another notion around Developer Marketing and how it is impossible to effectively market to developers. I believe the answer is building relations, building genuine connections, and listening to developers. So, Developer Relations, not Developer Marketing The challenge is, as you rightly point out, how do we measure success? In my opinion, DevRel should contribute to the KPIs of the teams mentioned above specific to a technical/developer audience. As a DevRel-specific KPI track how many advocates the team created- those who love and advocate for your product independently - unpaid articles, reviews, and references.