--- title: 'Leading Without Authority as an Individual Contributor' seoTitle: 'Leading Without Authority as an IC' author: 'Xinjiang Shao' date: '2025-08-17' description: 'How individual contributors can lead effectively without formal authority—through influence, expertise, and collaborative strategies.' tags: - Leadership - Career Development - Influence - Software Engineering coverImage: './images/cover.png' podcast: true --- # Leading Without Authority as an Individual Contributor ```mermaid graph TD Intern:::ic --> Junior["Software Engineer I / Junior"]:::ic Junior:::ic --> Mid["Software Engineer II / Mid-level"]:::ic %% IC Track Mid:::ic --> Senior["Senior Software Engineer"]:::ic Senior:::ic --> TL["Tech Lead"]:::ic TL:::ic --> Staff["Staff Engineer"]:::ic Staff:::ic --> Principal["Principal Engineer"]:::ic Principal:::ic --> DistEng["Distinguished Engineer / Fellow"]:::ic %% Management Track Senior --> EM["Engineering Manager"] EM --> SrEM["Senior Engineering Manager"] SrEM --> Dir["Director of Engineering"] Dir --> SrDir["Senior Director"] SrDir --> VP["VP of Engineering"] VP --> CTO["CTO"] %% Product Management Track Mid --> APM["Associate Product Manager / Business Analyst"] APM --> PM["Product Manager"] PM --> SrPM["Senior Product Manager"] SrPM --> DirPM["Director of Product"] DirPM --> VPProd["VP of Product"] VPProd --> CPO["CPO / Chief Product Officer"] classDef ic fill:#4f8ef7,stroke:#2d5aa0,color:#fff,font-weight:bold; ``` As software engineers advance in their careers, they often face a unique challenge: how to lead and drive change without formal management authority. This becomes especially relevant for senior engineers, staff engineers, and technical leads—roles that require influence across teams and organizations. Different organizational sizes call for different approaches. Over the past few years, I've had the chance to lead a team that grew from 5 members to more than 20 developers. The journey showed me that the career path of an IC leader is very different from that of a people manager. In this post, I want to reflect on what worked, what didn't, and the lessons I learned along the way. For me, any IC role above Senior Software Engineer qualifies as an IC leader—whether that's a Tech Lead, Staff Engineer, or Principal Engineer. These roles demand not just technical expertise but also the ability to influence and guide others without direct authority. ## The Reality of IC Leadership IC leadership is fundamentally different from people management. You can't rely on hierarchy or reporting lines to execute your vision. Instead, your influence comes from expertise, trust, and relationships. And the way you apply those depends heavily on team size and structure. ## Small Teams: The One-Pizza Team In small teams (4–6 members, often called "one-pizza teams"), ICs wear many hats and have outsized impact. Collaboration is close, influence is direct, and contributions are highly visible. Here's an example structure for a small co-located team: ```mermaid graph TD PO["Product Owner (1)"]:::po DM["Dev Manager (1)"]:::manager PO --- DM subgraph Team["One-Pizza Team (4 people)"] LD["Lead Dev Member (1)"]:::lead D1["Dev Member 1"]:::ic D2["Dev Member 2"]:::ic D3["Dev Member 3"]:::ic end DM --> LD DM --> D1 DM --> D2 DM --> D3 PO -->|Backlog & priorities| DM PO -.->|Tech alignment| LD LD -. mentoring .-> D1 LD -. mentoring .-> D2 LD -. mentoring .-> D3 classDef po fill:#ffd166,stroke:#c49a00,color:#000,font-weight:bold; classDef manager fill:#06d6a0,stroke:#049c76,color:#000,font-weight:bold; classDef lead fill:#118ab2,stroke:#0b5e7a,color:#fff,font-weight:bold; classDef ic fill:#ef476f,stroke:#b2354f,color:#fff; ``` In this setup, hierarchy matters less than shared ownership. IC leaders should: - Lead by example—through code quality, reviews, and knowledge sharing - Hold regular 1:1s to understand teammates' challenges and goals - Create space for informal mentoring and ad hoc conversations - Document onboarding guides, deployment steps, and common workflows early In small teams, IC leaders must stay hands-on with implementation. If the leader can't build a feature, it's hard to expect the team to succeed. Even if you're learning as you go, charting a path forward sets the tone for the rest of the team. ## Growing Teams: Co-Located and Remote Mix As organizations scale, teams diversify. You may end up with a mix of co-located and remote developers, or even multiple "pizza teams" across an org. That shift introduces new leadership challenges. ```mermaid graph TD Org["Engineering + Product Org"]:::org LD_SHARED["Lead Dev (Shared)"]:::leadShared %% Team Alpha PO_A["Product Owner A"]:::po DM_A["Dev Manager A"]:::manager Org --> PO_A Org --> DM_A PO_A --- DM_A subgraph TeamAlpha["Team Alpha — Mixed"] D1_A["Dev A1 (Co-locate)"]:::ic D2_A["Dev A2 (Remote)"]:::remote D3_A["Dev A3 (Remote)"]:::remote end style TeamAlpha fill:#f4f9ff,stroke:#a5c6ff,color:#000 DM_A --> LD_SHARED DM_A --> D1_A DM_A --> D2_A DM_A --> D3_A PO_A -->|Backlog & priorities| DM_A PO_A -.->|Tech alignment| LD_SHARED %% Team Beta PO_B["Product Owner B"]:::po DM_B["Dev Manager B"]:::manager Org --> PO_B Org --> DM_B PO_B --- DM_B subgraph TeamBeta["Team Beta — Remote"] D1_B["Dev B1 (Remote)"]:::remote D2_B["Dev B2 (Remote)"]:::remote D3_B["Dev B3 (Remote)"]:::remote end style TeamBeta fill:#fff7f0,stroke:#ffc78e,color:#000 DM_B --> LD_SHARED DM_B --> D1_B DM_B --> D2_B DM_B --> D3_B PO_B -->|Backlog & priorities| DM_B PO_B -.->|Tech alignment| LD_SHARED %% Team Gamma PO_C["Product Owner C"]:::po DM_C["Dev Manager C"]:::manager Org --> PO_C Org --> DM_C PO_C --- DM_C subgraph TeamGamma["Team Gamma — Co-located"] LD_C["Lead Dev (Dedicated)"]:::lead D1_C["Dev C1"]:::ic D2_C["Dev C2"]:::ic D3_C["Dev C3"]:::ic end style TeamGamma fill:#f5fff6,stroke:#98e6a9,color:#000 DM_C --> LD_C DM_C --> D1_C DM_C --> D2_C DM_C --> D3_C PO_C -->|Backlog & priorities| DM_C PO_C -.->|Tech alignment| LD_C classDef org fill:#e9ecef,stroke:#adb5bd,color:#000,font-weight:bold; classDef po fill:#ffd166,stroke:#c49a00,color:#000,font-weight:bold; classDef manager fill:#06d6a0,stroke:#049c76,color:#000,font-weight:bold; classDef lead fill:#118ab2,stroke:#0b5e7a,color:#fff,font-weight:bold; classDef leadShared fill:#2b2d42,stroke:#1a1b26,color:#fff,font-weight:bold; classDef ic fill:#ef476f,stroke:#b2354f,color:#fff; classDef remote fill:#6a4c93,stroke:#4b3368,color:#fff; ``` ### Team Alpha: Mixed (Remote + Onsite) - Overlapping hours (2–4 daily) are crucial - Junior remote devs need more pairing and context, not just async docs - Weekly checkpoints help surface blockers and maintain momentum ### Team Beta: Fully Remote - Harder to build culture—guardrails matter (standards, linting, tests) - IC leaders should partner closely with managers to keep direction clear - Too much triaging from the leader can stifle ownership ### Team Gamma: Fully Co-Located - Easiest to mentor, collaborate, and ship quickly - Mirrors the "pizza team" style but at larger scale ## Scaling Further: Multiple Pizza Teams ```mermaid graph TD Org["Engineering Org"]:::org PE["Principal Engineer (Shared)"]:::principal Org --> PE %% ========= TEAM ALPHA ========= PO_A["Product Owner A"]:::po DM_A["Dev Manager A"]:::manager Org --> PO_A Org --> DM_A PO_A --- DM_A subgraph TeamAlpha["Team Alpha — Co-located"] LD_A["Lead Dev A"]:::lead D1_A["Dev A1"]:::ic D2_A["Dev A2"]:::ic D3_A["Dev A3"]:::ic end style TeamAlpha fill:#f4f9ff,stroke:#a5c6ff,color:#000 DM_A --> LD_A DM_A --> D1_A DM_A --> D2_A DM_A --> D3_A PO_A -->|Backlog & priorities| DM_A PO_A -.->|Tech alignment| LD_A PE -.->|Architecture & Guidance| LD_A %% ========= TEAM BETA ========= PO_B["Product Owner B"]:::po DM_B["Dev Manager B"]:::manager Org --> PO_B Org --> DM_B PO_B --- DM_B subgraph TeamBeta["Team Beta — Co-located"] LD_B["Lead Dev B"]:::lead D1_B["Dev B1"]:::ic D2_B["Dev B2"]:::ic D3_B["Dev B3"]:::ic end style TeamBeta fill:#fff7f0,stroke:#ffc78e,color:#000 DM_B --> LD_B DM_B --> D1_B DM_B --> D2_B DM_B --> D3_B PO_B -->|Backlog & priorities| DM_B PO_B -.->|Tech alignment| LD_B PE -.->|Architecture & Guidance| LD_B %% ========= TEAM GAMMA ========= PO_C["Product Owner C"]:::po DM_C["Dev Manager C"]:::manager Org --> PO_C Org --> DM_C PO_C --- DM_C subgraph TeamGamma["Team Gamma — Co-located"] LD_C["Lead Dev C"]:::lead D1_C["Dev C1"]:::ic D2_C["Dev C2"]:::ic D3_C["Dev C3"]:::ic end style TeamGamma fill:#f5fff6,stroke:#98e6a9,color:#000 DM_C --> LD_C DM_C --> D1_C DM_C --> D2_C DM_C --> D3_C PO_C -->|Backlog & priorities| DM_C PO_C -.->|Tech alignment| LD_C PE -.->|Architecture & Guidance| LD_C %% ======= LEGEND ======= classDef org fill:#e9ecef,stroke:#adb5bd,color:#000,font-weight:bold; classDef po fill:#ffd166,stroke:#c49a00,color:#000,font-weight:bold; classDef manager fill:#06d6a0,stroke:#049c76,color:#000,font-weight:bold; classDef lead fill:#118ab2,stroke:#0b5e7a,color:#fff,font-weight:bold; classDef ic fill:#ef476f,stroke:#b2354f,color:#fff; classDef principal fill:#8d6aff,stroke:#5a3dbf,color:#fff,font-weight:bold; ``` Once you're leading across multiple teams, your role shifts. A Principal Engineer, for example, won't review every PR or join every standup. Instead, you'll: - Invest in developing lead developers across teams - Participate in org-level forums: architecture boards, vendor evaluations, roadmap discussions - Drive written agreements, processes, and technical design records to maintain clarity at scale At this stage, leadership is less about daily implementation and more about enabling leaders beneath you to succeed. For a deeper look at what this looks like in practice, I've written about [the toolbox Principal Engineers use](/blog/2025-10-05-the-toolbox-for-principal-software-engineers) to stay effective across multiple teams. ## Key Strategies for Leading Without Authority ### 1. Lead by Example Your technical decisions and work ethic set the bar. ### 2. Build Technical Credibility - Be the go-to expert in your domain - Share knowledge (talks, docs, mentoring) - Prevent tech debt before it grows ### 3. Master Influence - Listen first - Use data to back decisions - Tie technical choices to business goals — for a real example, see how [shared packages replaced shared applications](/blog/2026-02-14-share-packages-not-applications) to solve deployment coupling across five brand teams ### 4. Foster Collaboration - Host informal forums for discussion - Enable cross-team knowledge sharing - Resolve conflicts through shared objectives ### 5. Develop Others - Mentor juniors - Celebrate contributions - Help teammates grow into new challenges ## Overcoming Challenges #### Resisting the "Do It All" Trap It's tempting to handle everything yourself, especially early on. But scaling requires delegation, trust, and shared ownership. #### Navigating Politics Tech decisions are rarely purely technical. Build relationships, understand stakeholder incentives, and communicate broader impact. ## Long-Term Impact Leading without authority develops skills that serve you in any career path: - Strategic thinking about tech + business - Communication across audiences - Emotional intelligence with diverse stakeholders - Systems thinking at both org and tech levels ## Key Takeaways IC leadership is about creating impact through influence, expertise, and collaboration. Titles don't define leadership—trust and competence do. Some of the most influential figures in tech history were ICs whose ideas, code, and vision reshaped entire organizations. You don't need authority to lead—you need clarity, credibility, and the courage to set the example.