Moving DevEx From DevRel to Engineering  🔗 **Source:** [Moving DevEx From DevRel to Engineering](https://dev.to/missamarakay/moving-devex-from-devrel-to-engineering-5251) > [!note]+ Document Notes > 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 > <!-- deep-read:sections start --> ## 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. Community highlights include teams standardizing hiring loops for fairness and speed. New plugins on our radar streamline doc site accessibility and automate changelogs for SDKs. Read the original perspective: Moving DevEx from DevRel to Engineering (DEV Community). ## ✅ Action Items: Prompt tailored to your role and goals: “Analyze how this article’s reorg of DevEx into Engineering informs open-source advocacy, contributor engagement, and education in the WordPress ecosystem: - Governance: Map how moving DevEx under Engineering would affect an OSPO-aligned model at GoDaddy/WordPress, including decision rights for docs/SDKs, community platforms, and contributor programs. - Contributor Experience (CX): Identify practices to reduce interrupt-driven friction for contributors (issue triage, PR review SLOs, release-season surge playbooks). - Educational Design: Propose curricula that support continuous delivery without OKRs (micro-objectives, rolling rubrics, cohort-based contributor onboarding). - Equity in Feedback: Balance paying customer input with non-paying community voices; define transparent prioritization criteria and publish them. - Career Architecture: Draft DevEx/DevRel/Eng-aligned role matrices for advocates, DX engineers, and doc engineers; include growth paths that reward community impact. - Sustainable Funding: Outline funding models for docs/SDK maintenance and community infra post-reorg; include stewardship metrics tied to OSPO reporting. - Transparency & Inclusivity: Recommend internal ‘reintroduction’ comms cadences, office hours, and dashboards to clarify scope and foster psychological safety for contributors. - OSPO Readiness: Define policies, metrics, and governance necessary for an OSPO to steward DevEx in WordPress, ensuring compliance, DEIB, and long-term sustainability.” Deliverable: a brief plus a 90-day plan aligning reorg lessons to OSPO leadership objectives. ## 🧪 Hypotheses: - H1: Placing DevEx under Engineering increases developer adoption of SDKs due to tighter product feedback loops. - H2: Eliminating quarterly OKRs in favor of continuous delivery improves responsiveness but risks strategic drift without transparent roadmapping. - H3: Prioritizing paying-customer feedback improves retention metrics but decreases community satisfaction among non-paying users unless mitigated by inclusive feedback channels. - H4: Establishing a dedicated DevEx career ladder improves retention and performance compared to forcing alignment with generic Eng tracks. - H5: Introducing explicit interrupt budgets and SLOs reduces burnout and improves cycle time in docs/SDK teams. ### 📊 Methodology: - Mixed-methods: Combine product analytics (SDK adoption, doc search success, PR cycle time) with surveys (NPS, developer effort scores), and qualitative interviews. - A/B or quasi-experimental designs: Compare pre/post reorg metrics and matched teams that remain in DevRel. - Data sources: GitHub (PR review times, issue labels), docs analytics (search-to-success), customer CRM segments (paying vs non-paying), incident/interrupt tickets, employee engagement surveys, retention data. - Analysis: Interrupted time series for process changes; difference-in-differences across org models; thematic analysis for interviews. ### ❓ Questions: - How can DevEx quantitatively balance paying-customer feedback with broader community needs? - What minimum viable career ladder elements uniquely define DevEx work? - Which SLOs best capture the “support” side of Docs & SDKs without stalling product work? - How should teams communicate progress without OKRs while preserving strategic coherence? ### 🔮 Future Research: - Comparative outcomes for DevEx housed in DevRel vs Engineering across different company sizes. - Impact of interrupt budgeting on developer productivity and burnout. - Governance models that equitably weigh community and enterprise needs in open-source ecosystems. ### 💡 Implications: - Evidence-based org placement for DevEx could reduce adoption friction and improve developer happiness. - Clear career frameworks help retain cross-disciplinary talent. - Balanced feedback governance can improve both commercial sustainability and community trust. ### 🧠 Learning Styles Assessment: - Readability: Plain-language, listicle format; estimated reading level ≈ Grade 8–9. 1) Visual: Minimal visuals. Improve by adding org charts, flowcharts for hiring and planning, and a RACI for Docs/SDKs. 2) Aural: No audio. Add a short audio summary or podcast segment. 3) Verbal: Strong concise bullets; could add stories/examples. Link to examples of hiring loops and planning docs. 4) Kinesthetic: No hands-on tasks. Include templates (interrupt SLOs, intake forms) and exercises (draft a reorg comms plan). 5) Logical: Clear cause-effect notes; add metrics dashboards, process diagrams, and step-by-step playbooks. 6) Social: Invite discussion via comments or link to forums; suggest internal office hours formats. 7) Solitary: Add reflection prompts (e.g., “Where does your DevEx sit, and why?”) and journaling worksheets. 8) Naturalistic: Not applicable. Could add sustainability analogies (ecosystem health metrics for community). ### 📊 Accessibility Assessment: - Screen Reader: DEV articles generally semantic but images (if any) need alt text. Ensure alt on charts if added. - Keyboard Navigation: Typically fine; verify skip links and focus states. - Contrast/Readability: Recommend high-contrast palette and scalable fonts. - Text Resizing: Ensure responsive typography and no layout breakage at 200% zoom. ### 🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment: - Cultural Relevance: Limited perspectives. Add examples from diverse orgs and geographies. - Inclusive Language: Generally neutral; define jargon (OKRs, SLOs, interrupts). - Neurodiversity Support: Short bullets help; further chunk content with headings and summaries. - Representation: Include diverse case studies and imagery when visual assets are added. - Psychological Safety: Encourage transparent comms, clarify scope changes, and provide change support resources. Add content warnings for job uncertainty topics if expanded. ### ✅ Logical validity: - Strengths - Causal reasoning: “Engineering streamlined hiring → we had to rework hiring” strengthens clarity; could add before/after metrics. - Balanced view: Notes both increases and decreases in scope; add rationale for each change to strengthen. - Logical flow: Expected vs unexpected sections provide structure; linking each unexpected change to a mitigation would improve coherence. - Weaknesses/Fallacies - Potential hasty generalization: “Community feedback was ok, but specific customers’ feedback was best” lacks evidence. Suggest adding comparative satisfaction or retention data. - Possible false dilemma: Framing paying customers vs everyone as a conflict; propose a tiered prioritization model to avoid dichotomy. - Tone of voice: Candid, reflective, pragmatic; not adversarial. 🔍 DARVO Analysis - Deny: No denial of problems; the author openly acknowledges challenges. - Attack: No targeting of individuals or groups; no defamation or motive-questioning. - Reverse Victim and Offender: Not present. The narrative does not portray the team as victims of others; it’s descriptive and process-focused. - Emotional cues: Matter-of-fact, transparent, occasionally self-effacing (“stream of conscious listicle”). No DARVO-aligned rhetoric detected. ### 🔍 SEO Evaluation: - Keywords: Likely present organically: “DevEx,” “DevRel,” “Engineering,” “reorg,” “SDKs,” “docs.” Improve by adding long-tails like “moving devex to engineering,” “devrel to engineering reorg lessons.” - Meta Description: Add one around 155 characters: “A candid look at moving DevEx from DevRel to Engineering: scope shifts, hiring changes, OKR-free delivery, and balancing product vs. support.” - Title Tag: Current title is clear; length acceptable; includes primary keywords. - Headers: Uses bullet sections; convert to H2/H3 headings for scannability. - Content Length: Short-to-medium; could expand with examples/metrics to reach 1,000–1,500 words for depth. - Links: Add internal links to related reorg stories or hiring posts; add external links to resources on OKRs vs continuous delivery and DevEx best practices. - URL: Current slug is concise and keyword-relevant. - Image Optimization: Add a diagram with descriptive alt text and optimized file size. - Mobile Optimization: DEV is responsive; ensure any added assets are lightweight. - Engagement: Invite comments, offer templates/downloads, and add a CTA for feedback. - Schema: Use Article schema; consider FAQ schema if adding Q&A. - Social: Ensure Open Graph/Twitter Card previews with a compelling summary and image. ## 🎯 Conclusion: This candid account surfaces the operational and cultural realities of relocating DevEx into Engineering: revised governance, scope rebalancing toward SDKs/Docs, process overhauls for hiring and planning, careful career-path design, and the constant dance between product-building and support. The piece is strongest as a pragmatic field note; adding data, frameworks (SLOs, intake processes), and inclusive feedback models would turn it into a reusable blueprint for teams navigating similar reorgs. <!-- deep-read:sections end --> [[3. Resources/Readwise/Full Document Contents/Articles/Moving DevEx From DevRel to Engineering|Full Document Contents]] ## Document Notes --- 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:]] - [[#📖 Main Content:]] - [[#🗒️ Notes]] - [[#📖 References:]] - [[#🗣️ Paraphrase:]] - [[#📰 Newsletter:]] - [[#✅ Action Items:]] - [[#🧪 Hypotheses:]] - [[#📊 Methodology:]] - [[#❓ Questions:]] - [[#🔮 Future Research:]] - [[#💡 Implications:]] - [[#🧠 Learning Styles Assessment:]] - [[#📊 Accessibility Assessment:]] - [[#🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment:]] - [[#✅ Logical validity:]] - [[#🔍 DARVO Analysis]] - [[#🔍 SEO Evaluation:]] - [[#🎯 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. Community highlights include teams standardizing hiring loops for fairness and speed. New plugins on our radar streamline doc site accessibility and automate changelogs for SDKs. Read the original perspective: Moving DevEx from DevRel to Engineering (DEV Community). ## ✅ Action Items: Prompt tailored to your role and goals: “Analyze how this article’s reorg of DevEx into Engineering informs open-source advocacy, contributor engagement, and education in the WordPress ecosystem: - Governance: Map how moving DevEx under Engineering would affect an OSPO-aligned model at GoDaddy/WordPress, including decision rights for docs/SDKs, community platforms, and contributor programs. - Contributor Experience (CX): Identify practices to reduce interrupt-driven friction for contributors (issue triage, PR review SLOs, release-season surge playbooks). - Educational Design: Propose curricula that support continuous delivery without OKRs (micro-objectives, rolling rubrics, cohort-based contributor onboarding). - Equity in Feedback: Balance paying customer input with non-paying community voices; define transparent prioritization criteria and publish them. - Career Architecture: Draft DevEx/DevRel/Eng-aligned role matrices for advocates, DX engineers, and doc engineers; include growth paths that reward community impact. - Sustainable Funding: Outline funding models for docs/SDK maintenance and community infra post-reorg; include stewardship metrics tied to OSPO reporting. - Transparency & Inclusivity: Recommend internal ‘reintroduction’ comms cadences, office hours, and dashboards to clarify scope and foster psychological safety for contributors. - OSPO Readiness: Define policies, metrics, and governance necessary for an OSPO to steward DevEx in WordPress, ensuring compliance, DEIB, and long-term sustainability.” Deliverable: a brief plus a 90-day plan aligning reorg lessons to OSPO leadership objectives. ## 🧪 Hypotheses: - H1: Placing DevEx under Engineering increases developer adoption of SDKs due to tighter product feedback loops. - H2: Eliminating quarterly OKRs in favor of continuous delivery improves responsiveness but risks strategic drift without transparent roadmapping. - H3: Prioritizing paying-customer feedback improves retention metrics but decreases community satisfaction among non-paying users unless mitigated by inclusive feedback channels. - H4: Establishing a dedicated DevEx career ladder improves retention and performance compared to forcing alignment with generic Eng tracks. - H5: Introducing explicit interrupt budgets and SLOs reduces burnout and improves cycle time in docs/SDK teams. ### 📊 Methodology: - Mixed-methods: Combine product analytics (SDK adoption, doc search success, PR cycle time) with surveys (NPS, developer effort scores), and qualitative interviews. - A/B or quasi-experimental designs: Compare pre/post reorg metrics and matched teams that remain in DevRel. - Data sources: GitHub (PR review times, issue labels), docs analytics (search-to-success), customer CRM segments (paying vs non-paying), incident/interrupt tickets, employee engagement surveys, retention data. - Analysis: Interrupted time series for process changes; difference-in-differences across org models; thematic analysis for interviews. ### ❓ Questions: - How can DevEx quantitatively balance paying-customer feedback with broader community needs? - What minimum viable career ladder elements uniquely define DevEx work? - Which SLOs best capture the “support” side of Docs & SDKs without stalling product work? - How should teams communicate progress without OKRs while preserving strategic coherence? ### 🔮 Future Research: - Comparative outcomes for DevEx housed in DevRel vs Engineering across different company sizes. - Impact of interrupt budgeting on developer productivity and burnout. - Governance models that equitably weigh community and enterprise needs in open-source ecosystems. ### 💡 Implications: - Evidence-based org placement for DevEx could reduce adoption friction and improve developer happiness. - Clear career frameworks help retain cross-disciplinary talent. - Balanced feedback governance can improve both commercial sustainability and community trust. ### 🧠 Learning Styles Assessment: - Readability: Plain-language, listicle format; estimated reading level ≈ Grade 8–9. 1) Visual: Minimal visuals. Improve by adding org charts, flowcharts for hiring and planning, and a RACI for Docs/SDKs. 2) Aural: No audio. Add a short audio summary or podcast segment. 3) Verbal: Strong concise bullets; could add stories/examples. Link to examples of hiring loops and planning docs. 4) Kinesthetic: No hands-on tasks. Include templates (interrupt SLOs, intake forms) and exercises (draft a reorg comms plan). 5) Logical: Clear cause-effect notes; add metrics dashboards, process diagrams, and step-by-step playbooks. 6) Social: Invite discussion via comments or link to forums; suggest internal office hours formats. 7) Solitary: Add reflection prompts (e.g., “Where does your DevEx sit, and why?”) and journaling worksheets. 8) Naturalistic: Not applicable. Could add sustainability analogies (ecosystem health metrics for community). ### 📊 Accessibility Assessment: - Screen Reader: DEV articles generally semantic but images (if any) need alt text. Ensure alt on charts if added. - Keyboard Navigation: Typically fine; verify skip links and focus states. - Contrast/Readability: Recommend high-contrast palette and scalable fonts. - Text Resizing: Ensure responsive typography and no layout breakage at 200% zoom. ### 🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment: - Cultural Relevance: Limited perspectives. Add examples from diverse orgs and geographies. - Inclusive Language: Generally neutral; define jargon (OKRs, SLOs, interrupts). - Neurodiversity Support: Short bullets help; further chunk content with headings and summaries. - Representation: Include diverse case studies and imagery when visual assets are added. - Psychological Safety: Encourage transparent comms, clarify scope changes, and provide change support resources. Add content warnings for job uncertainty topics if expanded. ### ✅ Logical validity: - Strengths - Causal reasoning: “Engineering streamlined hiring → we had to rework hiring” strengthens clarity; could add before/after metrics. - Balanced view: Notes both increases and decreases in scope; add rationale for each change to strengthen. - Logical flow: Expected vs unexpected sections provide structure; linking each unexpected change to a mitigation would improve coherence. - Weaknesses/Fallacies - Potential hasty generalization: “Community feedback was ok, but specific customers’ feedback was best” lacks evidence. Suggest adding comparative satisfaction or retention data. - Possible false dilemma: Framing paying customers vs everyone as a conflict; propose a tiered prioritization model to avoid dichotomy. - Tone of voice: Candid, reflective, pragmatic; not adversarial. 🔍 DARVO Analysis - Deny: No denial of problems; the author openly acknowledges challenges. - Attack: No targeting of individuals or groups; no defamation or motive-questioning. - Reverse Victim and Offender: Not present. The narrative does not portray the team as victims of others; it’s descriptive and process-focused. - Emotional cues: Matter-of-fact, transparent, occasionally self-effacing (“stream of conscious listicle”). No DARVO-aligned rhetoric detected. ### 🔍 SEO Evaluation: - Keywords: Likely present organically: “DevEx,” “DevRel,” “Engineering,” “reorg,” “SDKs,” “docs.” Improve by adding long-tails like “moving devex to engineering,” “devrel to engineering reorg lessons.” - Meta Description: Add one around 155 characters: “A candid look at moving DevEx from DevRel to Engineering: scope shifts, hiring changes, OKR-free delivery, and balancing product vs. support.” - Title Tag: Current title is clear; length acceptable; includes primary keywords. - Headers: Uses bullet sections; convert to H2/H3 headings for scannability. - Content Length: Short-to-medium; could expand with examples/metrics to reach 1,000–1,500 words for depth. - Links: Add internal links to related reorg stories or hiring posts; add external links to resources on OKRs vs continuous delivery and DevEx best practices. - URL: Current slug is concise and keyword-relevant. - Image Optimization: Add a diagram with descriptive alt text and optimized file size. - Mobile Optimization: DEV is responsive; ensure any added assets are lightweight. - Engagement: Invite comments, offer templates/downloads, and add a CTA for feedback. - Schema: Use Article schema; consider FAQ schema if adding Q&A. - Social: Ensure Open Graph/Twitter Card previews with a compelling summary and image. ## 🎯 Conclusion: This candid account surfaces the operational and cultural realities of relocating DevEx into Engineering: revised governance, scope rebalancing toward SDKs/Docs, process overhauls for hiring and planning, careful career-path design, and the constant dance between product-building and support. The piece is strongest as a pragmatic field note; adding data, frameworks (SLOs, intake processes), and inclusive feedback models would turn it into a reusable blueprint for teams navigating similar reorgs. ## Highlights - 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. ([View Highlight](https://read.readwise.io/read/01k376ee4wwxnsh7wbh64hd4d2))