Likeable leaders go further - CourtneyR.dev's 2nd Brain

Likeable leaders go further 🔗 **Source:** [Likeable leaders go further](https://leaddev.com/career-development/likeable-leaders-go-further) > [!note]+ Document Notes > tags: [leadership, technical-lead, communication] > author: Jack Franklin > source: LeadDev > reference: https://leaddev.com/career-development/likeable-leaders-go-further > date created: 2025-01-05 10:30 > > # 🏷️ Title: Likeable leaders go further >  ## 🧰 Action Inbox - [H1] Practice saying "yes to discussion, no to timeline" approach — avoid dismissive responses #leadership - [H2] Implement post-meeting recap emails for all cross-functional meetings — build trust through documentation #communication - [H3] Audit current communication for "I/my team" vs "we" language — shift credit attribution #teamwork ## 🧭 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 - [Likeable leaders go further](https://leaddev.com/career-development/likeable-leaders-go-further) ## 📝 Summary - Technical leads must shift from optimizing individual output to team performance and cross-functional relationships - Why it matters: Likeable, approachable leaders achieve better team performance and career advancement than those who rely solely on technical expertise - Key stakeholders: Technical leads, engineering managers, cross-functional partners (PM, UX, business stakeholders) - Risks and tradeoffs: Balancing technical excellence with people skills; managing increased communication overhead - Bottom line: Technical expertise alone is insufficient for leadership success - approachability and clear communication are equally critical ## 📖 Main Content The article argues that technical leads must evolve beyond individual contributor mindsets to become effective team multipliers. Franklin presents three core areas for improvement: managing workload while staying approachable, building trust through clear communication, and properly attributing credit to team members. The shift from IC to TL requires recognizing that your individual output becomes secondary to facilitating team success. Technical leads serve dual roles - as internal trusted advisors to their teams and external calm authorities to the business. The author emphasizes that approachability often trumps technical expertise in determining leadership effectiveness. Franklin shares a personal failure where dismissing a product manager's idea damaged relationships and missed opportunities. This led to developing strategies like always accepting discussion invites, maintaining idea backlogs, and being honest about priorities rather than claiming to be "too busy." ## 🗒️ Notes #### Early Career Focus vs Leadership Requirements - Key idea: Individual contributors optimize for personal output (PRs, bug fixes, feature delivery), but technical leads must optimize for entire team performance - Evidence: "your individual output is directly linked to the team's success" #### The Dual Role of Technical Leaders - Key idea: Effective TLs serve as trusted internal guides and external calm authorities - Evidence: "A trusted, wise head internally...A trusted, calm authority externally" #### Approachability Over Technical Expertise - Key idea: Team enjoyment and respect for leadership matters more than pure technical skill - Evidence: "a good TL recognizes that their technical expertise is almost secondary to their approachability" #### Managing Overwhelming Input Gracefully - Key idea: Technical leads face constant requests and must learn to decline without damaging relationships - Evidence: Franklin's example of dismissively telling a PM "Sorry, I'm too busy and we have too much to do" #### Strategy: Always Accept Discussion Invites - Key idea: Never outright decline conversations; defer or request email summaries if needed - Evidence: "Always accept an invite for a discussion. If you're really busy, defer it a week" #### Maintain Comprehensive Idea Backlogs - Key idea: Track all potential projects even if currently infeasible, as priorities and technical landscapes change - Evidence: "Keep a list of all the ideas or projects you could do, even if there are far too many" #### Honest Priority Communication - Key idea: Replace "I'm too busy" with transparent priority discussions - Evidence: "Try to avoid 'I'm too busy' as a phrase. That's never the real reason" #### Team-First Prioritization - Key idea: Team questions, 1:1s, and unblocking take precedence over external requests - Evidence: "Put your own team first, every time...My number one objective is to minimize the time my team is blocked by me" #### Post-Meeting Documentation Strategy - Key idea: Send recap emails after every meeting to ensure alignment and catch misunderstandings - Evidence: "End each meeting with a recap...giving people a chance to flag if they disagree" #### Written Decision Tracking - Key idea: Document all decisions, including informal ones, to maintain accountability and context - Evidence: "Get every decision in writing...capture any decisions taken in less formal scenarios" #### Proactive Change Communication - Key idea: Own priority shifts transparently rather than letting people discover changes independently - Evidence: "Proactively communicate when things change...own the situation and be transparent" #### Credit Attribution Language - Key idea: Use "we" instead of "my team" or "me and my team" in communications - Evidence: "Focus on what 'we' shipped. Avoid saying 'my team' or 'me and my team'" #### Public Praise, Private Feedback - Key idea: Recognition should be public while constructive criticism remains private - Evidence: "Praise publicly, and provide feedback privately" #### Blameless Problem Resolution - Key idea: Focus on fixes and process improvements rather than individual fault-finding - Evidence: "When there are bugs, keep it blameless...focus on fixing the bug and any process improvements" #### Professional Emotional Management - Key idea: Avoid public venting; take breaks when unable to be constructive - Evidence: "Avoid venting in a public forum...that's usually my signal to go for a walk" ## 📚 References - [LeadDev Career Development](https://leaddev.com/career-development) - [Google Senior Software Engineer](https://about.google/) ## 🗣️ Paraphrase - Technical leadership requires shifting focus from personal productivity metrics to team multiplication and cross-functional relationship building - Successful technical leads balance internal team guidance with external business communication, prioritizing approachability alongside technical competence - Effective communication strategies include accepting all discussions, maintaining transparent priorities, documenting decisions, and attributing credit appropriately to team members ## 📰 Newsletter 🚀 **Technical Leadership Beyond Code: Why Likeable Leaders Win** This week's leadership insight focuses on a critical transition many WordPress developers face: moving from individual contributor to technical lead. Jack Franklin's research at Google reveals that technical expertise alone won't carry you through leadership roles. **Key Learning**: The most successful technical leads master three areas beyond coding: graceful workload management, crystal-clear communication, and proper team credit attribution. Franklin's personal example of dismissing a product manager's idea shows how easily technical leads can damage crucial relationships. **Practical Application**: Start implementing post-meeting recap emails and shift your language from "my team delivered" to "we delivered." These small changes build the trust and approachability that distinguish great technical leaders. **WordPress Context**: Whether you're leading a plugin team, managing client projects, or contributing to WordPress Core, these principles apply directly. The WordPress community values collaborative leadership that elevates entire teams. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create "approachable technical leadership" talk series with case studies and anti-patterns - Education: Develop workshop curriculum on transitioning from IC to TL roles - Developer experience: Audit documentation for inclusive "we" language vs exclusive "I/my team" phrasing - Developer marketing: Campaign highlighting collaborative technical leadership success stories - Community management: Implement post-discussion recap protocols for community forums #### WordPress - Core: Model post-meeting documentation for core contributor meetings and decision processes - Community: Develop technical leadership mentorship programs pairing experienced leads with emerging ones - Training: Create learning path for WordPress developers transitioning to team lead roles - Documentation: Style guide updates promoting inclusive team language in all WordPress documentation - Meta: Implement transparent priority communication protocols for cross-team WordPress.org initiatives ## 🧪 Hypotheses - Technical leads who implement structured communication protocols (post-meeting recaps, decision documentation) achieve higher cross-functional satisfaction scores - Teams led by approachable technical leaders show measurably higher velocity and lower turnover than those led by purely technically-focused leaders - Organizations that train technical leads in relationship management see improved project success rates and stakeholder satisfaction - WordPress contributors who practice inclusive credit attribution language become more effective community leaders and maintainers ### 📊 Methodology - Study design to test hypothesis 1: Survey cross-functional partners on TL communication effectiveness before/after implementing structured protocols - Data sources and analysis for hypothesis 2: Correlation analysis of team performance metrics (velocity, retention, satisfaction) with leadership approachability ratings - Experiments to validate hypothesis 3: Controlled comparison of project outcomes between relationship-trained vs technically-trained TLs ### ❓ Questions - How do we measure "likeability" in technical leadership without introducing bias against underrepresented groups who may be perceived differently? - What specific communication training produces the highest ROI for technical leads transitioning from IC roles? - How can distributed open source projects like WordPress implement these relationship-building strategies across time zones and cultures? ### 🔮 Future Research - Longitudinal study tracking career progression of relationship-focused vs technically-focused technical leads - Cross-cultural validation of these leadership principles in global software development teams - Investigation of potential collaboration between psychology research and engineering management practices ### 💡 Implications - Practice: Technical leads should allocate significant time to communication and relationship building, not just technical problem-solving - Policy: Engineering organizations need formal training programs for IC-to-TL transitions focusing on soft skills - Education: Computer science curricula should include collaborative leadership and communication training alongside technical content - Funding: Organizations should budget for technical leadership development programs as core infrastructure investment ### 🧠 Learning Styles Assessment Reading level estimate: 9th grade (accessible to broad technical audience) #### 👀 Visual learners - Present: Clear section headers, bullet points, structured formatting - Improve: Communication flow diagrams, before/after leadership behavior charts #### 🔊 Aural learners - Present: Conversational tone, personal anecdotes, quoted examples - Improve: Podcast version or audio summary of key strategies #### 🗣️ Verbal learners - Present: Specific phrase examples ("we" vs "my team"), clear definitions of technical lead roles - Improve: More analogies comparing technical expertise to relationship skills #### 🧩 Kinesthetic learners - Present: Actionable strategies, step-by-step communication approaches - Improve: Interactive checklist for post-meeting recaps, practice scenarios #### 🧠 Logical learners - Present: Clear cause-and-effect relationships, structured argument progression - Improve: Decision trees for handling different types of stakeholder requests #### 🧑‍🤝‍🧑 Social learners - Present: Team dynamics focus, cross-functional collaboration emphasis - Improve: Discussion prompts for technical leadership communities #### 🧘‍♀️ Solitary learners - Present: Self-reflection opportunities, personal failure analysis - Improve: Private self-assessment tools for leadership communication style #### 🌿 Naturalistic learners - Present: Organic relationship building, natural communication patterns - Improve: Ecosystem thinking about technical teams within larger organizational environments ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy, descriptive section titles - Improve: Add skip navigation, ensure all quotes have proper attribution markup #### Keyboard navigation - Present: Standard web navigation, logical reading order - Improve: Focus indicators on interactive elements, skip links for long content #### Contrast and readability - Present: High contrast text, readable font sizes - Improve: Verify 4.5:1 contrast ratio, increase line spacing for dense content #### Text resizing and reflow - Present: Responsive layout supporting zoom - Improve: Test content reflow at 200% zoom, prevent horizontal scrolling #### Media and captions - Present: Text-based content accessible by default - Improve: Add audio version with full transcript #### Forms and interactions - Present: Minimal interactive elements - Improve: Ensure newsletter signup meets accessibility standards ### 🌍 DEIB Assessment #### Cultural breadth - Present: Google/tech industry perspective, Western business communication norms - Improve: Include examples from diverse cultural contexts, acknowledge different leadership styles #### Inclusive language - Present: Gender-neutral pronouns, accessible technical language - Improve: Address potential bias in "likeability" expectations for underrepresented groups #### Neurodiversity support - Present: Clear structure, consistent formatting, logical progression - Improve: Content warnings for anxiety-inducing topics like performance feedback #### Representation - Present: Single author perspective (white male in tech leadership) - Improve: Include diverse voices and leadership approaches, acknowledge cultural differences #### Psychological safety - Present: Acknowledges failure and learning, non-judgmental tone - Improve: Address power dynamics and bias in leadership perception ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Personal experience leads to general principles (moderate strength) - Inductive strength: Single case study generalized to broader leadership advice (limited sample size) - Causal reasoning: Claims likeable leaders perform better but lacks quantitative evidence - Analogical strength: Good analogies between technical problem-solving and relationship management #### Fallacies - Anecdotal evidence: Single personal failure story generalized to universal advice, needs broader data - False dichotomy: Implies choosing between technical expertise OR relationships rather than both #### Tone of voice - Overall tone: Conversational, humble, practical with personal vulnerability that builds credibility ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on accusers present - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: Positive, constructive tone focused on improvement rather than blame ## 🎯 Conclusion Technical leadership success requires mastering relationships and communication alongside technical expertise. Franklin's framework of approachable workload management, clear documentation practices, and inclusive credit attribution provides actionable steps for emerging technical leads. The shift from individual contributor to team multiplier demands intentional development of soft skills that many technical professionals have never formally learned. Organizations investing in comprehensive technical leadership development - covering both technical and interpersonal competencies - will see improved team performance, stakeholder satisfaction, and leader career progression. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Technical expertise becomes secondary to approachability in leadership > [!quote] [Likeable leaders go further](https://leaddev.com/career-development/likeable-leaders-go-further) by [[Jack Franklin]] via [[LeadDev]]. Published November 12, 2025. Accessed January 5, 2025. > "a good TL recognizes that their technical expertise is almost secondary to their approachability" Challenges conventional wisdom about technical leadership requiring primarily technical skills. [view highlight](https://leaddev.com/career-development/likeable-leaders-go-further#H1) #xref #leadership #articleseed ID:rw_tech_approachability_001 ### [H2] Team-first prioritization maximizes leadership effectiveness > [!quote] [Likeable leaders go further](https://leaddev.com/career-development/likeable-leaders-go-further) > "Put your own team first, every time. Their questions, 1:1s, code reviews...are my top priority" Provides clear hierarchy for competing demands on technical lead attention. [view highlight](https://leaddev.com/career-development/likeable-leaders-go-further#H2) #xref #prioritization ID:rw_team_first_priority_001 --- ### 🔖 Atomic Split Pad (Zettel Candidates) Purpose: Promote reusable claims into Atomic notes. Split level: H4 #### [Z1] Documentation prevents relationship damage from miscommunication - Applies to all collaborative technical work, not just leadership - Reference to post-meeting recap strategy - Links: [[Technical-Communication]] [[Stakeholder-Management]] #### [Z2] Language choice signals credit attribution and team