Moving DevEx From DevRel to Engineering  ## Metadata - Author: [[DEV Community]] - Full Title: Moving DevEx From DevRel to Engineering - Category: #articles - Document Note: --- tags: - #developer-experience - #organizational-change - #engineering-management Author: Amanda (missamarakay) Source: DEV Community article Reference: https://dev.to/missamarakay/moving-devex-from-devrel-to-engineering-5251 date created: 2025-08-21 00:00 --- # Title: Moving DevEx from DevRel to Engineering — Expectations, Surprises, and Adaptation ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - DEV Community: Moving DevEx from DevRel to Engineering (original article) ## 📝 Summary: The author shares a candid, stream-of-consciousness account of reorganizing a Developer Experience (DevEx) team from Developer Relations (DevRel) into Engineering. Expected changes included a new manager, peer group, reporting line, and scope adjustments. Unexpected changes were substantial: new headcount, immediate need to overhaul hiring processes, abandoning OKRs/quarterly planning in favor of continuous delivery, career path alignment challenges, a shift toward prioritizing paying customer feedback, and a dual identity as both product development (Docs & SDKs) and support—leading to heavy interrupt-driven work and seasonality around release cycles. The reorg also required ongoing internal re-introductions to clarify scope and placement. Where to find these points in the article: - Opening context (0%): “I wasn't sure if I wanted to share this… stream of conscious listicle.” - Expected changes (~25%): “Things I expected…” - Unexpected changes (~50%): “Things I didn't expect…” - Seasonality and internal marketing (~75%): “Some seasonality… nearly constant (re)introductions…” Direct links to positions: - Start (0%): https://read.readwise.io/read/01gxppm1sqwmyxt78m074y9swc?scrollDepth=0.0 - Expected list (~25%): https://read.readwise.io/read/01gxppm1sqwmyxt78m074y9swc?scrollDepth=0.25 - Unexpected list (~50%): https://read.readwise.io/read/01gxppm1sqwmyxt78m074y9swc?scrollDepth=0.5 - Seasonality/marketing (~75%): https://read.readwise.io/read/01gxppm1sqwmyxt78m074y9swc?scrollDepth=0.75 ## 📖 Main Content: The article is a practical field note on the realities of shifting DevEx from a community- and advocacy-oriented function (DevRel) to Engineering. The change affects: - Governance and reporting: Moving under a VP in Engineering changes prioritization, metrics, and expectations. The team remains second-level under the CTO within Product. - Scope recalibration: Ownership expanded to SDKs (a new function) while community platforms (Slack, Hub, Forum) moved away. This rebalances focus from broad community engagement toward product enablement and developer workflows. - Process shifts: Engineering’s streamlined hiring and move away from quarterly OKRs required immediate adaptation—adopting continuous, incremental delivery and reengineering hiring loops for technical roles. - Career ladders: Aligning DevEx roles with Engineering career paths brought both standardization and friction; DevEx Engineers needed a related but separate ladder to reflect unique competencies. - Customer signal hierarchy: Greater emphasis on specific paying customer feedback—tension with DevRel’s broader “build for everyone” ethos. - Operational reality: Docs & SDKs lead to both product development and high-volume support/interrupt work; seasonality spikes occur before twice-yearly minor releases, particularly for PR reviews. - Internal alignment: Persistent reintroductions and “internal marketing” were needed to correct misperceptions that the team still sits in DevRel. Reflections: - The reorg illustrates a pattern: DevEx often thrives closest to Engineering when tied to product surface areas (SDKs, Docs), but success depends on guardrails that protect focus (e.g., ticket SLOs, interrupt buffers). - Moving away from OKRs doesn’t negate outcomes; it redistributes them across continuous delivery, requiring robust working agreements, data-informed prioritization, and service-level expectations for interrupt-driven domains. - Career architecture matters: Without a distinct DevEx path, teams risk mis-evaluating impact that spans documentation quality, SDK usability, and developer productivity. ### 🗒️ Notes - Expected changes - New manager and peer group with peer managers - Different spot on org chart; reporting to VP instead of director; still under CTO within Product - Scope changes: add SDK ownership; remove Community Slack/Hub/Forum - Unexpected changes - Immediate +1 headcount and urgent hiring process rework due to Engineering’s streamlined approach - Engineering dropped quarterly planning and OKRs → shift to smaller, continuous improvements - New manager career path aligned with Eng Managers; DevEx Engineer path updated, related but distinct - Career path changes mid-flight are disruptive to individuals - Feedback posture: specific paying customers > broad community signals, creating tension with inclusivity of non-paying developers - Team labeled product dev (Docs & SDKs) but operates as support too—heavy interrupts - Seasonality: spikes before twice-yearly minor releases; surge in PR reviews - Ongoing internal comms: repeated reintroductions to clarify team scope and placement; residual perception they’re still in DevRel Operational implications - Need service-levels for docs/SDK support; buffer time for interrupts - Strong intake/triage to separate product work from support work - Clear career frameworks tuned to DevEx competencies (DX research, API design, information architecture) - Data-focused prioritization blending paying-customer insights with community health metrics ## 📖 References: - DEV Community: Moving DevEx from DevRel to Engineering — https://dev.to/missamarakay/moving-devex-from-devrel-to-engineering-5251 ## 🗣️ Paraphrase: 1) Original idea: The team gained immediate headcount and had to overhaul hiring to match Engineering’s streamlined process. - Paraphrase: We unexpectedly received approval to add to our team and quickly discovered our previous DevRel-style hiring loop didn’t fit Engineering’s approach. We had to rebuild our hiring process right away to align with how Engineering recruits and evaluates candidates. 2) Original idea: Engineering moved away from quarterly planning and OKRs, forcing a shift to incremental, continuous delivery. - Paraphrase: Since Engineering no longer uses quarterly plans or OKRs, we transitioned to a cadence of small, steady improvements. This required rethinking how we plan, prioritize, and communicate progress without the familiar quarterly goal structure. ## 📰 Newsletter: DevEx Corner: From DevRel to Engineering—What Changes When You Move Closer to the Code? This week we’re unpacking a candid field report on shifting a Developer Experience team out of DevRel and into Engineering. Highlights you’ll care about: - Process pivots: Goodbye OKRs and quarterly cycles; hello continuous delivery and incremental wins. - Product vs. support reality: Owning Docs and SDKs means building and being on-call for the developer journey—expect interrupts and pre-release PR surges. - Career ladders that fit: Aligning with Eng frameworks while preserving DevEx-specific competencies isn’t optional—it’s how you retain and reward impact. - Signal hierarchy: Balancing paying-customer feedback with community-wide needs remains tricky but essential for inclusive ecosystems. Learning web dev? Watch how SDK design and great docs drive adoption. Communi - Summary: The hard (and hidden!) truth on reorgs - URL: https://dev.to/missamarakay/moving-devex-from-devrel-to-engineering-5251 I wasn't sure if I wanted to share this, but I've had a few folks ask about our reorg out of DevRel and into Engineering. Please enjoy this stream of conscious [listicle](https://en.wikipedia.org/wiki/Listicle). This is what I have energy to write right now. #### Things I expected * Different manager * Different peer group (first time ever having peer managers!) * Different position on an org chart + Reporting to VP (now) vs. director (previously) + Still second-level as CTO, still within Products * Our scope increased to own SDKs, a new function entirely * Our scope decreased - removed Community Slack, Community Hub, and Community Forum #### Things I didn't expect * We immediately received +1 headcount. + Prior to the reorg, I wasn't anticipating hiring this year. + Hiring is hard, but it's been *very* hard recently. * Engineering recently streamlined hiring, which was vastly different from the process and way we hired in DevRel. + Outcome: we had to rework our hiring process immediately. * Engineering had completely shifted away from quarterly planning and OKRs. DevRel did both quarterly planning and OKRs. + Outcome: we had to shift to smaller incremental improvements and more of a continuous delivery style. * New manager career path, streamlined with other Engineering Managers. + But I don't feel like an Engineering Manager...? * Updated DevEx Engineer career path (to be closer to streamlined Eng career path, but ultimately needed to stay separate). + This is still a change, and changes to people's inflight career paths are hard. * Community feedback was ok, but specific customers' feedback was best. + Puts us in direct conflict with building for *everyone*, paying customer or not. + Note - this was a company shift, so no matter where we sat I think this would have been a change. * We were labeled as a product development team (Docs & SDKs), but often function as a support team too, particularly for Docs. + This means we have a LOT of interrupt driven work. + Some seasonality too - weeks before the 2x yearly minor releases we see a huge uptick in PR reviews. * Nearly constant (re)introductions and internal team marketing to describe scope changes. + These have slowed, but I'm still finding some people think we are part of DevRel, not Eng., Moving DevEx From DevRel to Engineering, DEV Community, 01gxppm1sqwmyxt78m074y9swc.