Best of Leadership — December 2025

1. 1
   Article

   Tech Lead Digest·23w

   Traits of a good Tech Lead

   Tech Leads are responsible for technical direction across three pillars: architecture (defining decisions, managing technical debt), quality (maintaining standards), and mentorship (enabling team growth). Good Tech Leads use written artifacts like RFCs and PoCs to structure decisions, actively negotiate technical scope with product stakeholders, and establish operating principles that enable autonomous decision-making. They generate team velocity through clarity, reduce ambiguity, and influence without authority. Key anti-patterns include making improvised decisions without documentation, overdesigning solutions, and centralizing knowledge instead of distributing it across the team.

   261

   1
2. 2
   Article

   DEV·22w

   Technical Debt Is a Myth Created By Bad Managers

   The term "technical debt" is a fundamentally broken metaphor that shifts blame from management decisions to engineers. Most code quality issues stem from impossible deadlines, resource constraints, and business pressures rather than deliberate shortcuts. Code naturally ages as requirements evolve and platforms change, which isn't debt but normal software evolution. The metaphor obscures that engineering decisions are trade-offs made under specific constraints, not moral failures. Better alternatives include "maintenance cost," "context shift," or "technical consequences of business decisions" to accurately reflect accountability and enable realistic planning.

   201

   20
3. 3
   Article

   Manager.dev·23w

   5 engineering dogmas it's time to retire

   Five common software engineering practices deserve reconsideration: relying heavily on third-party packages creates security and maintenance risks, mandatory code reviews slow teams down unnecessarily, 2-4 week sprints drain joy from development, overusing feature flags creates codebase complexity, and avoiding all code comments is an extreme position. Each practice has merit but shouldn't be treated as absolute dogma. Engineering managers should balance these principles with their team's specific context rather than following them blindly.

   91

   9
4. 4
   Article

   Programming Digest·24w

   No code reviews by default

   Raycast's engineering team operates without mandatory code reviews, allowing engineers to push directly to the main branch and request reviews only when needed. This trust-based approach emerged from their early startup days and scaled with their distributed team. They prioritize rapid iteration through daily internal releases, dogfooding changes within 24 hours, and shipping public updates every two weeks. Code reviews are still used selectively for unfamiliar code areas, database migrations, or onboarding new team members. The team relies on post-commit notifications, quick video calls, and continuous integration to maintain quality while avoiding the bottlenecks of traditional pull request workflows.

   80

   27
5. 5
   Article

   The Architect Elevator·23w

   Being an architect isn’t the sum of skills. It’s the product.

   Effective architects must master the intersection of multiple skill domains rather than simply accumulating separate capabilities. Architecture requires synthesizing technical expertise, communication skills, business understanding, and people management into a unified force-multiplying capability. The role demands being a technical communicator who can present complex trade-offs to executives, a technical leader who multiplies team effectiveness, and a platform builder who bridges business and technology domains. Success comes from the product of these skills working together, not their sum.

   79

   2
6. 6
   Video

   The Serious CTO·22w

   7 Signs You’re a Stuck Developer (And How Senior Engineers Break Free)

   Seven behavioral patterns distinguish developers who advance from those who stagnate: taking initiative without permission, working around obstacles instead of complaining, documenting achievements systematically, admitting knowledge gaps confidently, measuring progress against past self rather than peers, curating relationships that support growth, and taking ownership instead of blaming external factors. Each pattern is actionable through specific weekly practices like maintaining a brag document, proposing solutions proactively, and auditing time spent with colleagues.

   52

   5
7. 7
   Article

   sean goedecke·21w

   You can't design software you don't work on

   Generic software design advice is largely useless for real-world engineering work on large existing codebases. Effective design requires intimate knowledge of concrete implementation details, not abstract principles. The most valuable design discussions happen between engineers actively working on the system, focusing on specific subsystems, dependencies, and constraints. Generic advice has limited utility: guiding new projects, tie-breaking decisions, and ensuring cross-codebase consistency. Formal architect roles that design without implementation responsibility often fail because they lack the concrete understanding needed to create actionable plans. Engineers who design systems should be accountable for their success or failure.

   45

   2
8. 8
   Article

   Cassidy's blog·24w

   The ABCD framework for feedback

   The ABCD framework provides a structured approach to giving and receiving feedback through four specific questions: what's Awesome, what's Boring, what's Confusing, and what Didn't you believe. This simple method helps elicit specific, actionable responses instead of vague reactions when reviewing blog posts, tutorials, projects, or products.

   44

   1
9. 9
   Article

   Tech Lead Digest·23w

   Proof of Concept

   Succession planning is critical for organizational continuity and long-term impact. Leadership transitions should be prepared years in advance through long shadowing periods where successors gain exposure to key responsibilities. Successful handoffs like Apple's Tim Cook, Microsoft's Satya Nadella, and Nike's Mark Parker share common traits: successors already performed pieces of the job, developed their own style, and were visible to the organization long before the transition. Effective succession requires delegating real responsibility, removing single points of failure, ensuring industry knowledge, and treating it as an adaptive, ongoing process rather than a one-time event.

   38
10. 10
    Article

    swizec.com·24w

    How good engineering unlocks fast scaling

    Manual processes that work early on become bottlenecks as companies grow. A four-step framework helps engineers automate repetitive work: do the task manually first, document it as a standard operating procedure, convert stable procedures into scripts, and finally build self-service tools for non-engineers. This progression removes engineering as a blocker, empowers other teams to self-serve, and frees up time for high-value work. Real examples include building a CMS for appointment types that saved a month of engineering work annually.

    30
11. 11
    Article

    sean goedecke·22w

    Nobody knows how large software products work

    Large software systems at tech companies are poorly understood even by their own engineers. Complex features like enterprise controls, localization, and compliance requirements create intricate interactions that affect every new feature. Documentation struggles to keep pace with rapid changes, and many system behaviors emerge unintentionally from default choices. Engineers who can reliably answer questions about how software works are rare and valuable, as most prefer writing code to explaining it. The ability to investigate and understand existing systems is a distinct skill from coding, requiring comfort with uncertainty and summarization.

    29

    2
12. 12
    Article

    All Things Distributed·23w

    A little bit uncomfortable

    Growth happens at the edges of discomfort. Fear and anxiety are signals that you're pushing into unknown territory where real development occurs. The relationship between stress and performance follows a bell curve—optimal performance happens under heightened stress, but falls off when anxiety becomes overwhelming. For leaders, recognizing these moments in yourself and others creates opportunities to support growth. Bravery isn't loud or impulsive; it's the quiet persistence of choosing difficult paths with eyes open. The key is becoming aware of discomfort and considering leaning into it rather than avoiding it.

    16

    5
13. 13
    Article

    Manager.dev·25w

    The 'delayed opinions givers' - engineering teams everybody hates

    When another team needs work done in your domain, you face three choices: ignore them, give delayed attention, or prioritize helping them. Delayed attention is the worst option—it wastes engineer-weeks through blocked work and messy merges while gaining nothing. Teams that prioritize unblocking others (even at the cost of their own deadlines) build better reputations and create reciprocal relationships. The key is responding promptly to requests like code reviews and consultations, treating cross-team dependencies with the same urgency as internal work. Set boundaries with teams that abuse this approach, but default to being a 'giver' team that puts others' needs first 90% of the time.

    14
14. 14
    Article

    The Art of Simplicity·22w

    Why you can't have a ‘work self’ and a ‘home self’

    Having separate professional and personal values is a myth. We operate with one set of core values that should guide behavior across all contexts—work, home, and everywhere else. The challenge isn't choosing between different value systems, but living in alignment with your true values consistently, even when it's difficult or costly. This unified approach eliminates the cognitive dissonance of maintaining multiple versions of yourself and frees up energy for authentic living. The key is identifying what you truly value and finding the courage to honor those values in every situation.

    13
15. 15
    Article

    Game Developer·22w

    Backlash over Larian CEO's AI comments is a leadership problem

    Larian Studios CEO Swen Vincke faced backlash after describing the company's use of generative AI for tasks like placeholder text, reference images, and QA automation. The controversy stems not just from AI ethics concerns, but from power dynamics where employees feel pressured to adopt tools they oppose. Former employees confirmed internal pushback exists despite Vincke's claims workers are "more or less OK" with it. The situation highlights broader industry tensions where leadership mandates AI adoption while workers face difficult choices between compliance and job security, especially given Larian's demanding hiring process requiring international relocation and extensive unpaid tests.

    13

    9
16. 16
    Article

    Changelog·22w

    Agents in the database with Ajay Kulkarni, CEO of Tiger Data (Changelog Interviews #671)

    Ajay Kulkarni, CEO of Tiger Data (formerly Timescale), discusses his journey from enterprise work to founding a database company. The conversation covers how founder values shape company culture, the evolution from Timescale to Tiger Data, and the emerging concept of agents in databases. Topics include the speed of modern development, database interaction patterns, and the API/CLI/MCP/Skills ecosystem for AI agents.

    12