How to find a tribe of mentors - CourtneyR.dev's 2nd Brain

How to find a tribe of mentors 🔗 **Source:** [How to find a tribe of mentors](https://leaddev.com/career-development/how-find-tribe-mentors) > [!note]+ Document Notes > tags: [mentorship, career-development, engineering-management] > author: Shehab Abdel-Salam > source: LeadDev > reference: [https://leaddev.com/career-development/how-find-tribe-mentors] > date created: > > # 🏷️ Title: How to find a tribe of mentors >  ## 🧭 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 Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: The author argues engineers should cultivate a “tribe” of mentors across three categories: technical, product, and online. - Why it matters: Diverse perspectives accelerate execution, product thinking, and leadership growth at all levels. - Key stakeholders: Software engineers, tech leads, product managers, and senior engineering leaders. - Risks and tradeoffs: Over-reliance on one mentor, unfocused advice if mentor pool is too large or noisy. - Bottom line: Intentionally build a small, curated group of mentors to compound career growth. ## 📖 Main Content - The article defines mentorship needs by level: juniors focus on technical excellence and communication; seniors and staff focus on impact, influence, and cross-team leadership; senior leaders must blend technical direction with business understanding. - The author proposes three mentor types: - Technical mentors (often within your org) focus on execution, architecture, and leveling up scope/impact. - Product mentors (PMs/designers) build product thinking, customer empathy, and strategic alignment with roadmaps. - Online mentors (creators, writers, podcasters) offer frameworks and mental models from outside your company. - Finding technical mentors: show eagerness to learn, proactively join initiatives, seek senior engineers or managers who can observe your work and give targeted feedback. - Finding product mentors: deepen collaboration with PMs; share engineering insights, help with scoping, and use that relationship to understand customer pain points and business goals. - Finding online mentors: pick a small, focused set of public experts whose content aligns with your growth areas; consume their content intentionally and adapt lessons to your context. - The author illustrates these ideas with a database scaling project where: - A principal engineer mentor pushed them not to mandate their own solution and to remain open to team input. - Two product mentors from different product verticals developed their ability to present “the right problem with the right solution at the right time.” - Online mentors like Gergely Orosz and others influenced their approach to stakeholder management, documentation, and project shipping. - The overarching claim: career progression requires parallel growth in technical depth, product thinking, and continuous learning, which is best supported by a deliberately assembled tribe of mentors. ### 🗒️ Notes - Mentors provide “unbiased opinions” and recurring feedback on growth, team dynamics, product, and business, helping engineers identify paths to success ([opening argument](https://read.readwise.io/read/01kg29z9axg633zrw5np901kja?endLexposition=0000A_00000-002U&startLexposition=00000&emphasizeText=Mentors+are+foundational+in+helping+engineers+through+providing+unbiased+opinions+on+their+work)). - Rule of thumb: have at least one mentor 1–2 steps ahead on the ladder so your problems are familiar to them. - For junior/mid engineers, mentorship goals: technical excellence (solution design, implementation, testing, deployment), deeper domain knowledge, and strong communication skills for collaboration and interviews ([role of mentorship by level](https://read.readwise.io/read/01kg29z9axg633zrw5np901kja?endLexposition=0000K_00004-001G&startLexposition=0000C&emphasizeText=For+junior+and+mid-level+engineers%2C+the+goal+for+mentorship+is+clear%3A+technical+excellence)). - For senior/staff, mentorship centers on impact and influence: stakeholder management, high-impact project delivery, and inter-team relationships. - Senior leaders need mentors who help balance deep technical mastery with business understanding, setting technical direction and sustaining engineering culture ([senior leader focus](https://read.readwise.io/read/01kg29z9axg633zrw5np901kja?endLexposition=0000W_00000-002q&startLexposition=0000M&emphasizeText=If+you%E2%80%99re+a+senior+leader+already+looking+for+guidance+in+the+form+of+mentorship)). - The “tribe” model consists of technical, product, and online mentors; each type targets different growth dimensions. - Technical mentor: - Ideally within your organization with visibility into your work and performance feedback. - Focus: execution, owning larger projects with greater scope and impact. - Often your tech lead, staff engineer, or principal engineer; might be assigned or self-selected. - You earn this mentorship by demonstrating initiative: joining projects, volunteering, and building cross-team relationships ([finding technical mentor](https://read.readwise.io/read/01kg29z9axg633zrw5np901kja?endLexposition=0000g_00000_00000-000S&startLexposition=0000Y&emphasizeText=Finding+a+technical+mentor+requires+you+to+show+your+willingness+to+learn)). - Product mentor: - A PM or designer with deep knowledge of customer pain points; “voice of the end user.” - Goal: develop product thinking and leadership, especially for product-minded engineers leading high-impact projects. - Conversations reveal attempted solutions, unmet needs, and product vision; mentorship focus is strategy (vision, roadmap, business outcomes) ([product thinking description](https://read.readwise.io/read/01kg29z9axg633zrw5np901kja?endLexposition=0000r&startLexposition=0000i&emphasizeText=Having+conversations+with+product+people+helps+you+understand+the+customer%E2%80%99s+pain+points)). - Start with your team’s PM; look to adjacent teams or senior PMs if needed, offering engineering insights, project scoping help, and technical opinions. - Online mentor: - Someone outside your company who offers structured content: YouTube, podcasts, newsletters, etc. - They can’t see your daily work but provide frameworks and mental models from extensive industry experience ([online mentor definition](https://read.readwise.io/read/01kg29z9axg633zrw5np901kja?endLexposition=0000w_00000_00000-000S&startLexposition=0000s&emphasizeText=An+online+mentor+is+someone+outside+your+company+who+provides+online+mentorship+sessions)). - Examples: distributed systems experts on YouTube, principal engineers podcasting on leadership, or senior engineers writing newsletters. - This mentorship is asynchronous and low-commitment; you adapt non-tailored advice to your own situation. - Choose a small, focused pool (~4–6) aligned with your interests to reduce noise and emphasize growth ([curating online mentors](https://read.readwise.io/read/01kg29z9axg633zrw5np901kja?endLexposition=0000y_00002-0013&startLexposition=0000y&emphasizeText=I+personally+recommend+keeping+a+small+pool+of+people+%28~4-6%29+with+focused+areas+and+less+noise)). - Use case: Database scaling project - The author led a critical infrastructure project scaling the core database cluster; success mattered to manager and skip-level ([project intro](https://read.readwise.io/read/01kg29z9axg633zrw5np901kja?endLexposition=00012_00000-005J&startLexposition=00010&emphasizeText=Not+too+long+ago%2C+I+was+part+of+an+infrastructure+project+that+involved+scaling+our+core+database+cluster)). - Technical mentor (principal engineer outside the team): provided platform expertise; key advice: “do not mandate a solution you ideate yourself,” encouraging openness to team ideas and leading to a better hybrid solution ([principal engineer advice](https://read.readwise.io/read/01kg29z9axg633zrw5np901kja?endLexposition=0001A_00000-008C&startLexposition=00014&emphasizeText=One+piece+of+advice+I+learned+from+him%3A+do+not+mandate+a+solution+you+ideate+yourself)). - Product mentors: two PMs from different product verticals—one existing collaboration, one proactively initiated—helped the author understand multiple product roadmaps and cross-team impact, leading to better framing of problems and solutions ([product mentors story](https://read.readwise.io/read/01kg29z9axg633zrw5np901kja?endLexposition=0001K_00005_00000-000I&startLexposition=0001C&emphasizeText=Through+their+mentorship%2C+I+thought+more+like+a+product+person)). - Online mentors: Gergely Orosz, Steve Huynh, and Evan King & Stefan Mai influenced the author’s approach to stakeholder management, Amazon-style six-pager documentation, and general project execution ([online influences](https://read.readwise.io/read/01kg29z9axg633zrw5np901kja?endLexposition=0001O_00000-006p&startLexposition=0001M&emphasizeText=These+industry+thought+leaders+shaped+how+I+take+on+new+projects+as+an+engineer)). - Conclusion: One mentor is good but insufficient for high performance; the best career resource is a small, intentional tribe spanning technical, product, and online perspectives to support multi-dimensional growth. ## 📚 References - Shehab Abdel-Salam, “How to find a tribe of mentors” — LeadDev: https://leaddev.com/career-development/how-find-tribe-mentors - Gergely Orosz, The Pragmatic Engineer: https://pragmaticengineer.com - Sean Goedecke interview on shipping projects (via Pragmatic Engineer podcast). - Amazon Six-Pager memo pattern (Steve Huynh reference; general background: https://www.allthingsdistributed.com/2006/11/working_backwards.html) ## 🗣️ Paraphrase - Paragraph A paraphrase: Engineers progress faster when they surround themselves with several mentors, each providing distinct perspectives on technical skill, product sense, and broader industry practices. - Paragraph B paraphrase: By deliberately cultivating relationships with technical leaders, product partners, and external experts, you can design a personalized support system that improves execution, strategic thinking, and long-term career outcomes. ## 📰 Newsletter In this week’s WordPress-adjacent learning spotlight, we’re zooming out from themes and plugins to talk about *people*. LeadDev’s “How to find a tribe of mentors” is a great playbook for any WordPress developer or contributor who wants to level up. Instead of hunting for a mythical “perfect mentor,” the author suggests assembling a *small* trio: - A **technical mentor** who reviews your code, architecture choices, and performance tradeoffs—perfect for those wrangling complex Gutenberg blocks, REST APIs, or large multisite installs. - A **product mentor** (often a PM or UX designer) who helps you think in terms of user journeys, conversion, and roadmap—useful whether you’re shipping client sites or plugins on wordpress.org. - An **online mentor**—newsletter, podcast, or YouTube channel—whose frameworks you can adapt to your own work. Think engineering leadership shows, performance deep dives, and product-minded dev blogs. As you plan your learning path—Core contributions, performance work, or your next plugin launch—consider curating a mentor “stack” just like you curate your favorite tools. A few focused relationships can compound your skills far faster than adding one more tutorial to your reading list. ## ✅ Action Items #### DevRel - Developer advocacy: Create talks or blog posts for your community on how to intentionally build a mentor tribe (technical, product, online) within the project ecosystem. - Education: Design workshops or office hours where senior contributors act as technical/product mentors for newer contributors, with clear goals per session. - Developer experience: Add “mentorship-ready” examples and templates (e.g., PR templates, design docs) that mentors can use when guiding contributors. - Developer marketing: Run a campaign around “Grow with mentors” highlighting stories of contributors whose WordPress work accelerated through cross-role mentorship. - Community management: Encourage mentorship channels in Slack/Matrix/Discord with light structure (role-based rooms, code of conduct reminders, and pairing rotations). - Internal/external/cross-project: Align mentoring initiatives with contributor ladders and recognition programs, closing the loop between impact, feedback, and advancement. #### OSPO - Policy & Governance: Define lightweight policies for cross-org mentorship, including expectations, time commitments, and recognition for mentors. - License Compliance: Offer mentorship-style office hours to help teams interpret licenses and handle attribution correctly. - Security Management: Pair security engineers with product and platform teams as ongoing mentors for threat modeling and secure SDLC practices. - Software Inventory: Assign mentorship for SBOM champions per business unit to maintain accurate inventories. - Developer Support: Formalize “consultation hours” where senior engineers mentor teams on open source usage and contribution. - Community Engagement: Sponsor mentorship programs with upstream projects, including co-authored design docs and roadmap discussions. - Strategic Alignment: Tie mentorship outcomes (e.g., increased upstream contributions, fewer policy violations) to KPIs and report them to leadership. #### Community - Maintainers: Host roadmap clinics where maintainers mentor contributors on scoping, prioritization, and release hygiene. - Contributors: Launch a “first 90 days” mentorship track pairing new contributors with technical and product mentors. - Sponsors: Offer transparent reports showing how sponsored mentorship programs increase project stability and feature velocity. - Ecosystem: Run cross-project tabletop exercises to practice incident response and coordinated disclosures with mentor-led debriefs. #### WordPress - Core: Encourage component maintainers to offer scoped mentorship (e.g., “be a technical mentor for 1–2 contributors this release”). - Core Performance: Pair new performance-minded contributors with seasoned profiling and benchmarking mentors. - Core AI: Establish responsible AI mentorship pairs to guide contributors through evaluation, guardrails, and ethical considerations. - **Core Program Team:** Create clear rituals (office hours, mentorship rotations) that surface blockers and align teams around shared milestones. - Mobile: Offer mentorship on telemetry use, offline UX, and platform-specific constraints for app contributors. - Playground: Use Playground as a sandbox for mentored exercises: reproducing bugs, performance experiments, and feature prototypes. - Community: Build speaker mentorship into WordCamp and meetup programs to grow diverse technical voices. - Training: Turn key mentoring concepts into lesson plans, and encourage trainers to act as structured mentors between cohorts. - Marketing: Highlight real-world stories of contributors whose WordPress careers grew via targeted mentorship. - Support: Pair experienced forum moderators with new volunteers to coach on tone, conflict de-escalation, and triage. - Design: Run UX audits as live mentoring sessions, explaining decisions and tradeoffs for mentees. - Documentation: Establish doc “editors” as mentors, helping contributors learn standards and examples-first writing. - Photos: Mentor contributors on inclusive, high-quality photography and metadata practices. - TV: Mentor new presenters on storytelling, accessibility, and pacing in recorded talks. - Polyglots: Organize translation sprints with embedded mentors coaching on glossaries and style. - Accessibility: Pair experienced a11y reviewers with devs to walk through WCAG issues and fixes. - Meta: Mentor contributors on .org APIs, performance, and contributor tools to reduce onboarding friction. - CLI: Mentor plugin/theme authors on CLI workflows, scaffolds, and automated testing. - Hosting: Share mentorship between hosts on best-practice defaults, telemetry, and incident response. - Tide: Mentor plugin authors on improving quality scores, with guided reviews of real reports. - Openverse: Provide mentorship around ingestion pipelines, licensing, and moderation policies. - Themes: Run theme review mentorship cohorts focused on modern standards and testing. - Plugins: Build security liaison mentorship for plugin authors, with practical hardening guidance. #### The WPOCC - Programs: Offer fellowships that explicitly include multi-mentor setups (technical, product/community, and external/online). - Projects: Run governance clinics where maintainers get mentored on decision processes, documentation, and conflict resolution. - Funding experiments: Tie microgrants and stipends to structured mentorship milestones (e.g., mentoring a new maintainer through a release). ### FAIR - Technical independence: Encourage local copies of key mentorship artifacts (charters, docs, notes) with signed provenance from mentors. - Policies and covenants: Define transparent terms for funded mentorship programs with anti-capture clauses and sunset reviews. - Productized governance artifacts: Turn successful mentorship patterns into reusable charters, operator agreements, and scorecards. ## 🧪 Hypotheses - Engineers with at least three distinct mentor types (technical, product, online) advance faster in role seniority than those with only one. - Having a technical mentor inside the same organization leads to higher-quality execution outcomes on large projects. - Regular interaction with product mentors increases the likelihood that engineers can articulate customer problems and business impact effectively. - Curated online mentors (≤6 sources) yield more actionable learning than a large, unstructured set of content subscriptions. - Teams where engineers have active mentorship relationships deliver complex cross-team projects with fewer delays. ### 📊 Methodology - Conduct a longitudinal study of engineers, tracking mentor relationships, promotion rates, and project outcomes over 2–3 years. - Survey engineers on mentor types, frequency of interactions, and perceived impact on skills (execution, product thinking, leadership). - Run controlled internal experiments where some teams receive structured mentorship programs and others continue ad hoc mentoring. - Analyze documentation quality, stakeholder satisfaction, and incident rates for projects led by mentored vs. non-mentored engineers. ### ❓ Questions - How many mentors is “enough” before the overhead of coordination outweighs the benefits? - What qualities most reliably predict an effective mentor for engineers? - How does mentorship differ across remote vs. co-located teams? - Can asynchronous online mentorship substitute for a lack of internal mentors, and under what conditions? - How should organizations recognize and reward mentors without turning it into a purely transactional relationship? ### 🔮 Future Research - Comparative studies of mentorship structures (one-on-one vs. “tribe” models) in engineering teams. - The impact of cross-functional mentorship (engineer–PM, engineer–designer) on product outcomes. - Best practices for combining synchronous mentorship with asynchronous online learning. - Tooling to match mentees with complementary mentors across companies or communities. ### 💡 Implications - Practice: Teams should formalize multi-mentor setups for engineers, especially around critical projects. - Policy: Organizations may create mentorship expectations in role ladders and promotion criteria. - Security: Mentors can embed security thinking earlier in design, reducing vulnerabilities. - Education: Bootcamps and universities can teach students to design their own mentor networks. - Funding models: Grants and sponsorships can prioritize programs that include structured mentorship components. ### 🧠 Learning Styles Assessment - Reading level estimate: Approximately upper high school/early college (Flesch–Kincaid Grade ~11–12) due to domain-specific terminology and multi-clause sentences. #### 👀 Visual learners - Present: Conceptual separation of three mentor types and a concrete project example (but mostly text). - Improve: Diagrams showing how technical, product, and online mentors intersect around an engineer; timelines of a project with mentor touchpoints. #### 🔊 Aural learners - Present: References to podcasts and talks as online mentors. - Improve: 2–5 minute audio summary of the article; author-narrated version; suggested listening list of example “online mentors.” #### 🗣️ Verbal learners - Present: Clear definitions of each mentor type and use of narrative case study. - Improve: Short glossary of terms (e.g., “product thinking,” “technical direction”) and more analogies. #### 🧩 Kinesthetic learners - Present: Implicit suggestions to proactively reach out, help PMs, and join initiatives. - Improve: Explicit step-by-step exercises (e.g., “In the next week, schedule one conversation with a potential technical mentor”). #### 🧠 Logical learners - Present: Structured progression (levels of engineers → mentor types → case study → conclusion). - Improve: Simple decision trees or matrices mapping engineer level and goals to mentor priorities. #### 🧑‍🤝‍🧑 Social learners - Present: Emphasis on relationships and recurring conversations. - Improve: Discussion prompts or peer-circle formats to design and review mentor strategies together. #### 🧘‍♀️ Solitary learners - Present: Encouragement to curate personal online mentors and reflect on interests. - Improve: Reflection questions at the end (“Which of the three mentor types are you missing?”). #### 🌿 Naturalistic learners - Present: Limited to social/organizational ecosystems. - Improve: Use ecosystem analogies (e.g., diverse mentorship as biodiversity) and discuss sustainability of mentorship practices. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Standard article headings and paragraphs (typical for LeadDev). - Improve: Ensure proper heading hierarchy, language attributes, and descriptive alt text for any images. #### Keyboard navigation - Present: Likely basic keyboard navigability via browser and site navigation. - Improve: Confirm visible focus states, skip-to-content links, and logical tab order. #### Contrast and readability - Present: LeadDev typically uses reasonable contrast and readable typography. - Improve: Validate contrast ratio for all text and interactive elements; consider increased line height and larger base font size. #### Text resizing and reflow - Present: Responsive layout that should reflow at higher zoom levels. - Improve: Test at 200–400% zoom, ensure no horizontal scrolling for main content, and respect prefers-reduced-motion. #### Media and captions - Present: Primarily text-based article; linked podcasts are external. - Improve: Provide transcripts or summaries for any recommended media and avoid autoplay if embedded. #### Forms and interactions - Present: Minimal interactive elements beyond navigation and registration prompts. - Improve: For any forms, ensure labels, error states, and target sizes meet WCAG 2.2 AA. #### Standards reference - Map identified gaps and checks to WCAG 2.2 AA criteria such as 1.4.x (contrast), 2.1.x (keyboard), 1.4.10 (reflow), and 3.3.x (input assistance). ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focuses on generic software engineering roles without strong regional bias. - Improve: Add examples from different regions, company sizes, and cultural contexts for mentorship. #### Inclusive language - Present: Generally neutral, role-focused language. - Improve: Further reduce jargon or define it; add plain-language summaries for newer engineers or non-native English readers. #### Neurodiversity support - Present: Clear structure and chunked sections (levels, mentor types, case study). - Improve: More frequent headings, summaries, and predictable patterns for complex concepts. #### Representation - Present: Mentors cited are mostly senior male industry figures (implied). - Improve: Include examples from diverse genders, backgrounds, and career paths in mentorship stories. #### Psychological safety - Present: Encourages proactive outreach but doesn’t explicitly address power dynamics or saying no. - Improve: Discuss boundaries, consent in mentorship, and how to handle misaligned or harmful guidance. ### ✅ Logical Validity #### Strong reasoning - The argument that different career stages require different mentorship focuses is inductive but well-grounded in common engineering practice and plausible examples. - The case study logically supports the claim that a mix of mentors (technical, product, online) improves project outcomes, showing specific decisions influenced by each. #### Fallacies - Mild selection bias: the article generalizes from the author’s positive experience without acknowledging failed or misaligned mentorships. This could be improved by noting limitations and counterexamples. #### Tone of voice - Tone is supportive, pragmatic, and slightly aspirational—“every engineer looking to progress” and “the best career resource for your career” signal encouragement without being overly salesy. ### 🛡️ DARVO Analysis - Deny: No denial or minimization of harm; the article is constructive and advisory. - Attack: No attacks on individuals or groups; the piece is non-adversarial. - Reverse victim/offender: No attempt to recast victims or offenders; the themes are growth and responsibility. - Overall: DARVO dynamics are not present; rhetoric centers on empowerment and initiative. ## 🎯 Conclusion - Bottom line: Engineers progress faster when they intentionally assemble a small, diverse tribe of mentors—technical, product, and online—aligned with their current level and growth goals. - Practical next steps: Audit which of the three mentor types you already have, identify gaps, and over the next month initiate at least one relationship in each missing category with a clear, shared purpose. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [{Title or entity}]({ARTICLE_URL}) by [[{Author or [MISSING]}]] via [[{Site or [MISSING]}]]. Published {DATE_OR_[MISSING]}. Accessed . > “Short quote, verbatim, ≤25 words.” Two lines: context and use. Cite data if relevant. [view highlight]({ARTICLE_URL}#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [{Title or entity}]({ARTICLE_URL}) > “Short quote, verbatim, ≤25 words.” Two lines: context and use. [view highlight]({ARTICLE_URL}#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] #### [Z2] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Short action — context/{ARTICLE_URL} #fleeting #inbox - [F2] Short action — context/{ARTICLE_URL} #fleeting #inbox - [F3] Short action — context/{ARTICLE_URL} #fleeting #inbox ---