
Organizational Design
Choose functional vs divisional structure, plan a reorg, or shape product teams using Lenny-guest frameworks before headcount commits you.
Overview
Organizational Design is an agent skill most often used in Build (also Operate, Grow) that applies Lenny podcast frameworks to functional vs divisional teams and reorg trade-offs.
Install
npx skills add https://github.com/refoundai/lenny-skills --skill organizational-designWhat is this skill?
- Synthesizes 2 Lenny’s Podcast guests on org structure (2 mentions in corpus)
- Compares centralized Apple-style vs decentralized Amazon-style dependency models
- Covers functional reset vs divisional models and reducing non-craft people managers
- Prompts for company stage, current structure, and trade-offs before recommending a shape
- Frames reorgs as solving a specific coordination problem—not copying big-tech org charts
- 2 guest insights
Adoption & trust: 1.3k installs on skills.sh; 1k GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You are growing past one-person execution but every org chart option feels like copying Big Tech without knowing which trade-offs matter at your stage.
Who is it for?
Founder-PMs planning first hires, squad splits, or a deliberate shift from generalists to functional experts.
Skip if: Solo builders with no near-term hires who only need personal task systems—not company structure.
When should I use this skill?
Use when someone is thinking about team structure, deciding between functional vs. divisional models, planning a reorg, or figuring out how to structure product teams.
What do I get? / Deliverables
You leave with a clarified centralization vs parallel-work model and role boundaries aligned to the problem you are actually solving.
- Trade-off framing between centralized and decentralized models
- Structure recommendations tied to your stated constraints
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Org design first appears when a solo builder turns a product into a coordinated team—canonical on the Build PM shelf even though reorgs also touch Operate. pm covers how work is grouped, who owns product surfaces, and management layers—not infra uptime or marketing funnels.
Where it fits
Decide whether design and frontend stay one craft group before your second hire starts.
Choose squad boundaries so lifecycle experiments do not queue behind unrelated platform work.
Flatten layers after shipping slowed because managers did not own the product surface.
How it compares
Use for strategic structure conversations distilled from operators—not for Jira setup, RACI templates, or legal entity design.
Common Questions / FAQ
Who is organizational-design for?
Solo founders and small product leaders deciding team shape, functional vs divisional models, or how to structure product engineering groups.
When should I use organizational-design?
In Build PM when hiring or splitting ownership; in Grow when coordination slows delivery; in Operate when a reorg is needed to reduce layers or unclear managers.
Is organizational-design safe to install?
It is advisory research content—check the Security Audits panel on this page and treat recommendations as input to your own leadership and legal context.
SKILL.md
READMESKILL.md - Organizational Design
# Organizational Design - All Guest Insights *2 guests, 2 mentions* --- ## Brian Chesky *Brian Chesky* > "We went to a functional model. We went back to a startup." **Insight:** Brian discusses the fundamental shift from divisional to functional models, the removal of management layers, and the restructuring of roles to eliminate 'people managers' who don't know the work. ## Gustav Söderström *Gustav Söderström* > "On one spectrum, you have something like Amazon... minimize dependencies so you can run in parallel... On the other spectrum, you have something like Apple... centrally organized by something that is close to single individual." **Insight:** The guest provides a deep framework comparing centralized (Apple) vs. decentralized (Amazon) models and how they impact user experience and speed. --- name: organizational-design description: Help users design effective organizational structures. Use when someone is thinking about team structure, deciding between functional vs. divisional models, planning a reorg, or figuring out how to structure product teams. --- # Organizational Design Help the user design effective organizational structures using frameworks from 2 product leaders. ## How to Help When the user asks for help with organizational design: 1. **Understand their context** - Ask about their current structure, company stage, what problem they're trying to solve, and what trade-offs they're willing to make 2. **Identify the core trade-off** - Help them see the spectrum between centralized (Apple-style) and decentralized (Amazon-style) models 3. **Evaluate options** - Walk through the implications of different structures for speed, coherence, and cross-team dependencies 4. **Guide implementation** - Help them think through how to transition to a new structure ## Core Principles ### The fundamental trade-off: speed vs. coherence Gustav Soderström: "On one spectrum, you have Amazon - minimize dependencies so you can run in parallel. On the other, you have Apple - centrally organized close to a single individual." Amazon optimizes for speed through autonomous teams with minimal dependencies. Apple optimizes for coherent user experience through central coordination. Neither is universally better - choose based on what matters most for your product. ### Functional models can restore startup speed Brian Chesky: "We went to a functional model. We went back to a startup." Airbnb eliminated divisional structures and management layers that separated leaders from the work. Functional models concentrate expertise and reduce the "telephone game" between executives and ICs. ### Eliminate managers who don't know the work Brian Chesky's restructuring removed "people managers" who couldn't do the work themselves. Leaders should have enough context to make decisions, not just manage reports. If a manager can't review the actual output, the structure is broken. ### Structure follows strategy The right org structure depends on what you're optimizing for. If you need rapid, parallel execution on independent initiatives: decentralize. If you need a tightly integrated product experience: centralize. ## Questions to Help Users - "What problem are you trying to solve with this restructuring?" - "Do you optimize more for speed of independent teams, or coherence across the product?" - "How many layers are between your executives and the people doing the work?" - "Can your managers actually review and understand the output of their teams?" - "What are the biggest coordination failures you're experiencing today?" ## Common Mistakes to Flag - **Reorging without a clear problem** - Structure changes are disruptive. Be clear about what specific problem you're solving - **Copying another company's structure** - Amazon's structure works for Amazon's strategy. Make sure you're choosing based on your needs, not prestige - **Too many management layers** - Every layer adds latency and information loss. Minimize distance between d