DevRel and the Dotted Line  ## Metadata - Author: [[SpeakOfTheDevrel.Cloud: Doug Sillars]] - Full Title: DevRel and the Dotted Line - Category: #articles - Document Note: --- tags: - #DevRel - #DottedLineReporting - #OrgDesign Author: SpeakOfTheDevrel.Cloud: Doug Sillars Source: Speak of the DevRel Reference: https://speakofthedevrel.cloud/2023/12/18/devrel-and-the-dotted-line/ date created: 2025-08-23 00:00 --- # Title: DevRel and the dotted line ## Table of Contents: - [🧭 Introduction](#-introduction) - [🏛️ DevRel Reporting Structures](#-devrel-reporting-structures) - [🕸️ Dotted Line Reporting](#️-dotted-line-reporting) - [⚖️ Pros and Cons](#️-pros-and-cons) - [🤝 Managing Relationships](#-managing-relationships) - [🌱 Community Building](#-community-building) - [🔚 Conclusion](#-conclusion) - [🔗 References](#-references) ### References: Speak of the DevRel ## 📝 Summary: The article argues that the lack of standardization in DevRel reporting structures isn’t inherently problematic because DevRel, by its nature, operates through “dotted line” relationships across many departments. Dotted line reporting means DevRel receives goals, feedback, and work from multiple teams (marketing, product, engineering, customer success), gaining broad visibility and collaboration benefits while also risking relationship overload and burnout. DevRel often sits at the center of an internal web of relationships—and then extends that web externally to the developer community through relationship-building, content, solutions, and updates. ## 📖 Main Content: The author observes a wide variation in where DevRel reports (marketing, engineering, customer success, product, sometimes the CEO). Rather than prescribe a single right answer, they highlight that DevRel inherently collaborates across silos—functioning like a hub with many spokes. This “dotted line” posture confers advantages (learning, alignment, collaboration) but requires discipline to maintain many relationships and manage workload. The scope extends beyond internal teams: DevRel also supports external developer communities, adding another ring to the dotted-line web. Success depends on proactive communication, clarity of expectations, prioritization, and sustainable boundaries to avoid burnout. Personal insight: - DevRel effectiveness often correlates with where influence sits, not just where the team reports. Explicit agreements (working agreements/SLAs) with partner teams, plus a shared roadmap, can turn dotted lines into reliable collaboration channels without collapsing DevRel into a request queue. - Community work mirrors internal dotted lines: both require ongoing discovery, feedback loops, and value delivery. Treat community like a peer “department” with its own expectations and success metrics. ### 🗒️ Notes - The reporting debate - No standard for DevRel reporting; varies by org maturity and strategy. - Reporting lines seen: marketing, engineering, product, customer success, CEO. - Key claim: Variation isn’t bad because DevRel already operates cross-functionally. - Dotted line defined - Direct manager in one org unit; ongoing responsibilities, feedback, and goals from many others. - Typical partner teams: product, engineering, marketing, customer success. - Pros of dotted lines - Learning: Direct exposure to customer issues, engineering pipeline, marketing plans—improves content relevance and empathy for devs. - Collaboration: Cross-team communication reduces duplication and misalignment; “well-oiled machine” when synchronized. - Cons of dotted lines - Relationship load: Easy to over-rotate toward some teams and drift from others. - Burnout risk: Everyone routes work to DevRel; capacity can be overwhelmed. - DevRel as a hub - DevRel appears central in a web of dotted lines; some lines are “darker” (used more) than others. - Imperative: Keep all lines open and relationships strong. - Community as an additional dotted line - Beyond internal teams, DevRel builds and supports the developer community. - Activities: relationships, questions, content, solutions, updates—akin to adding another dotted line to the org structure. (Inline anchors are used since the original is a short article; there are no in-article timestamps. Key lines you may want to reference appear early in the piece such as “One of the biggest unresolved debates…” and “Dotted line reporting means…”.) ## 📖 References: - Doug Sillars, “DevRel and the dotted line,” Speak of the DevRel: https://speakofthedevrel.cloud/2023/12/18/devrel-and-the-dotted-line/ - Supporting image reference (mentioned by the author): https://www.flickr.com/photos/bigcypressnps/31634644291/ ## 🗣️ Paraphrase: 1) Original idea: “There isn’t any standardization for how developer relations reports inside a company… I don’t necessarily think this is a bad thing. The reason… is that every devrel position has dotted line reporting into different (every?) parts of the organization.” - Paraphrase: While companies place DevRel in many different departments, that inconsistency isn’t a problem. DevRel roles naturally operate across multiple teams through informal lines of responsibility, so a single rigid reporting model isn’t essential. 2) Original idea: “Dotted line reporting means that while you directly report into <team name>, you’ll also be receiving tasks, assignments and feedback from other teams…” - Paraphrase: In a dotted-line setup, DevRel has a formal boss but also takes direction and input from many groups—product, engineering, marketing, customer success—balancing multiple sets of expectations and deliverables. ## 📰 Newsletter: Learning web dev this week? Here’s your friendly, caffeinated briefing. Recent updates: PHP 8.x performance tips keep rolling in; JS tooling’s quieter but watch for incremental DX gains in bundlers; CSS container queries continue to shine for responsive interfaces. Community highlights: shout-out to first-time contributors in the WP performance team and everyone shipping accessibility fixes—small PRs, big impact. New plugins worth a look: a zero-config image optimizer for Core Web Vitals, a block-pattern library with accessible defaults, and a lightweight audit logger for multisite. For self-guided growth, pair HTML semantics with [MDN’s ARIA practices](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) and keep your Git chops sharp by triaging issues in a friendly repo like [WordPress Gutenberg](https://github.com/WordPress/gutenberg). If you’re new, start with “good first issue,” then graduate to docs improvements—your future self (and your users) will thank you. And yes, test on mobile early and often; your thumbs are stakeholders too. Got a plugin or tutorial to feature? Reply with a link and a one-liner about the problem it solves. Keep building, keep sharing, and remember: ship it, then iterate. ## ✅ Action Items: Custom prompt for aligning articles to your DevRel-OSPO trajectory at GoDaddy/WordPress “Analyze the provided article through the lens of: - Open-source advocacy: Identify arguments or practices that promote transparent collaboration, upstream-first contributions, and sustainable funding models. - Contributor engagement: Extract tactics that reduce onboarding friction, define contributor pathways, and improve recognition/retention. - Education and instructional design: Translate key ideas into teachable curricula (learning objectives, scaffolding, assessments) for PHP/JS/HTML/CSS/Git/GitHub learners. - DevRel operating model: Map the article’s insights to cross-functional alignment, dotted-line stakeholder management, metrics (dev experience, content performance, community health), and boundary-setting to prevent burnout. - OSPO readiness: Surface governance implications (policies, compliance, license hygiene), program design (working agreements/SLAs with product, marketing, engineering), and reporting (exec dashboards that balance product value and community health). - WordPress ecosystem transparency and inclusivity: Propose ways to publish roadmaps, decision logs, contributor office hours, and DEIB-aligned communication; ensure non-code pathways are represented. - On- and off-stage advocacy: Create a speaking/workshop outline, demo plan, and follow-up community activities that connect education with impact. Deliver: 1) A one-p - Summary: The document discusses the reporting structure for developer relations (DevRel) teams. There is a lot of variation in how DevRel teams report within companies, with some reporting into marketing, engineering, customer success, product teams, or even the CEO in smaller organizations. However, every DevRel position has dotted line reporting into different parts of the organization, meaning they receive tasks, assignments, and feedback from various teams. The pros of dotted line reporting include learning and collaboration, while the cons include maintaining many relationships and the potential for burnout. Building and supporting the developer community is also a key responsibility for DevRel teams. - URL: https://speakofthedevrel.cloud/2023/12/18/devrel-and-the-dotted-line/ One of the biggest unresolved debates for developer relations is the reporting structure for the DevRel team. As I apply for a new position here at the end of 2023, I am reading dozens of job descriptions. Each description describes the reporting hierarchy for the developer relations team, and there is a \*lot\* of variation. Some report into marketing, engineering, customer success, product teams. In smaller organizations, they might report straight right into the CEO. There isn’t any standardization for how developer relations reports inside a company… I don’t necessarily think this is a bad thing. The reason it isn’t a terrible thing is that **\*every\*** devrel position has dotted line reporting into different (every?) parts of the organization. #### Dotted Line reporting Dotted line reporting means that while you directly report into <team name>, you’ll also be receiving tasks, assignments and feedback from \*other\* teams. Probably every team. This means that, in addition to your goals and expectations from **your** team, you’ll also be working closely with customer success, product, marketing, engineering, etc., and they will have expectations and goals for developer relations. **Pros of dotted lines** * Learning: By working across silos, I learn more about the issues customers are facing, the engineering pipeline, the marketing plans – you get a good taste of everything that is going on. I can do a better job delivering content to developers! * Collaboration: Teams that are communicating with one another collaborate better. When everyone is in sync, things can move like a well-oiled machine. When teams are working in a vacuum, work is duplicated, or completely out of sync. Good collaboration keeps everyone in sync. **Cons of dotted lines** * There are a lot of relationships to maintain. It is easy to focus on certain relationships and fall out of sync with others. * Burnout: If everyone expects work to be completed by the devrel team – the workload can get too high. While the devrel team may report to one specific member of the team, there is an expectation that there will be many different reporting relationships inside the company – to the point where the DevRel team begins to appear at the center of a web of dotted line reports. [https://www.flickr.com/photos/bigcypressnps/31634644291/](https://www.flickr.com/photos/bigcypressnps/31634644291/in/photolist-v6a5U-QcrPBz-aa7Xge-azcgct-R6Bfo3-8w7ZjS-9G9fkf-cQgGdE-8w7ZWf-P9aDkT-CjfH5-aHhnbp-9oBvU-5yG5Cs-MhDt2j-5yFK6w-bCMh8C-o9njrH-oCtb3K-okZ9sK-9FKMkg-v2xFT-8PVhiV-6F4CTs-gsYrFA-Lm6Wx-bLqqoX-5vSbKd-otMUzA-hqWSNP-yGAWLT-7R41Vb-pDdgM-dk8tvZ-MqZDHo-7QZvUe-buFe8z-p8TJ3j-LwGA1h-7R3PpW-MqZG2w-ek7QtK-4Y4LPd-5MXqN5-oxGpad-pXYZLS-pHHtaB-pHDThK-5MTb7n-7R3JYd) Clearly, some of the dotted lines might be darker and used more often than others, but as a DevRel professional, it is important to keep all lines of communication open and keep the relationships strong. #### But wait, There’s more! In addition to all of the dotted line reporting and collaboration *inside* your company, the developer relations team is often tasked with building and supporting the developer community. What does building and supporting a developer community look like? To me, it is building relationships; asking questions; delivering content; creating solutions; providing updates and more. If I were doing these things with an internal team, I’d add a dotted line to my reporting structure. #### Are Customers Really a Dotted Line? What do you think? Leave a comment below!, DevRel and the Dotted Line, SpeakOfTheDevrel.Cloud: Doug Sillars, 01hj15zeckybamt3gb7nssyt7g.