aigroup-workflow 1.0.1 → 1.1.0

package/skills/jarvis/engineering-team/c-level-advisor/chro-advisor/references/org_design.md

@@ -1,333 +0,0 @@
-# Org Design Reference
-
-Spans of control, layering decisions, reorgs, title frameworks, career ladders, and the founder→professional management transition.
-
----
-
-## Core Org Design Principles
-
-1. **Structure follows strategy.** Reorg after strategy shifts, not before.
-2. **Optimize for the bottleneck.** Where does work get slow? Design around that.
-3. **Minimize coordination cost.** Conway's Law: your org structure becomes your product architecture. Design intentionally.
-4. **Bias toward flatness until it breaks.** Adding layers adds cost and slows decisions.
-5. **Reorgs have transition costs.** Relationships reset. Count the cost before you restructure.
-
----
-
-## Spans of Control
-
-Span of control = number of direct reports a manager has.
-
-### Benchmarks
-
-| Role Type | Optimal Span | Min | Max |
-|-----------|-------------|-----|-----|
-| IC manager (predictable work) | 7–10 | 5 | 12 |
-| IC manager (complex/creative work) | 5–7 | 4 | 8 |
-| Manager of managers | 4–6 | 3 | 7 |
-| VP / Director | 4–7 | 3 | 8 |
-| C-Suite | 5–9 | 4 | 10 |
-
-**Too narrow (< 4 ICs):** Over-management, high cost per output, manager becomes a bottleneck
-**Too wide (> 12 ICs):** Under-management, degraded 1:1 quality, feedback loops collapse
-
-### Factors that allow wider spans
-- Highly autonomous, senior team (L3+ ICs)
-- Predictable, well-defined work (support, ops)
-- Strong tooling and process (reduces manager overhead)
-- Experienced manager
-
-### Factors that require narrower spans
-- High-complexity, undefined problems (research, early product)
-- Junior or newly promoted team members
-- High interdependence between reports (coordination overhead)
-- Manager is also an IC contributor (player-coach)
-
----
-
-## When to Add Management Layers
-
-**The wrong reason to add layers:** "We need to give good people somewhere to grow."
-**The right reason:** "This manager has too many direct reports to do the job well."
-
-### Layer triggers by growth stage
-
-**0 → 15 people:** No layers. Everyone reports to founders.
-
-**15 → 30 people:** First managers emerge. Usually technical leads or function leads. Should still be player-coaches.
-
-**30 → 60 people:** Second layer forms. Engineering splits into squads. Sales gets a frontline manager. Each function has a head.
-
-**60 → 150 people:** Director layer becomes necessary in large functions. Engineering VP + Engineering Directors + Team Managers.
-
-**150+ people:** VP layer fully staffed. Senior Director / Director split. Clear IC → M → Senior M → Director → VP paths.
-
-### The Rule of 7
-
-When any manager has 7 or more direct reports and:
-- 1:1s are skipped regularly
-- Feedback quality drops
-- Manager can't answer "how is each person doing?" without checking notes
-
-→ Time to split or hire a manager.
-
-### Management overhead cost
-
-Every manager layer costs 10–15% in decision speed (communication hops).
-Every management role without a team = pure overhead.
-
-**Litmus test for each management role:**
-- Does this person have at least 4 ICs under them?
-- Would removing this role improve decision speed?
-- Is this a management job or a "we ran out of IC levels" job?
-
----
-
-## Functional vs. Product Org Structures
-
-### Functional Structure (by discipline)
-
-```
-CEO
-├── VP Engineering
-│   ├── Backend Team
-│   ├── Frontend Team
-│   └── DevOps
-├── VP Product
-│   ├── PM (Feature A)
-│   └── PM (Feature B)
-└── VP Design
-    └── UX Designers
-```
-
-**Best for:** Early stage, < 100 people, single product
-**Advantage:** Deep expertise development, clear career paths per discipline
-**Disadvantage:** Cross-functional coordination is heavy; features require synchronization across silos
-
-### Product/Pod Structure (by product area)
-
-```
-CEO
-├── Product Area A (autonomous team)
-│   ├── EM
-│   ├── PM
-│   └── Designer
-├── Product Area B (autonomous team)
-│   ├── EM
-│   ├── PM
-│   └── Designer
-└── Platform (shared services)
-    └── Platform EM + team
-```
-
-**Best for:** Multiple products or large user segments, 50+ in product/eng
-**Advantage:** Speed and autonomy; less cross-team coordination for most features
-**Disadvantage:** Duplication risk; harder to maintain technical coherence; harder career paths
-
-### When to shift from Functional → Product org
-- You have 2+ distinct product lines that rarely share features
-- Cross-functional feature delivery takes > 3 sprints of coordination overhead
-- Teams are > 8 engineers and still waiting on shared resources
-
-### Hybrid / Matrix (avoid unless necessary)
-Matrix reporting (e.g., engineer reports to EM + PM) creates accountability confusion. Avoid at < 500 people.
-
----
-
-## Title Frameworks
-
-### The Problem with Title Inflation
-
-Early startups over-title to compete with cash. "VP of Engineering" with 2 reports. "Head of Marketing" with no team.
-
-**Consequences:**
-- Can't add leadership above inflated titles without awkward conversations
-- Candidates from mature companies expect scope commensurate with titles
-- Internal equity breaks when the same title means different things
-
-### Preventing Title Inflation
-
-**Rule 1:** VP titles require managing managers (not just ICs).
-**Rule 2:** Director titles require managing multiple ICs or a large function.
-**Rule 3:** No more than one "Head of X" per function.
-**Rule 4:** Document scope expectations per title before making offers.
-
-### Engineering Title Ladder (example)
-
-| Title | Level | Scope | Reports |
-|-------|-------|-------|---------|
-| Software Engineer I | L1 | Executes defined tasks | — |
-| Software Engineer II | L2 | Independent delivery | — |
-| Senior Software Engineer | L3 | Leads features, mentors | — |
-| Staff Software Engineer | L4 | Cross-team technical leadership | — |
-| Principal Software Engineer | L5 | Company-wide technical direction | — |
-| Distinguished Engineer | L6 | External recognition, defining practice | — |
-| Engineering Manager | M1 | Team of 4–8 engineers | 4–8 ICs |
-| Senior Engineering Manager | M2 | Larger team or manager of managers | 2–4 managers |
-| Director of Engineering | M3 | Functional area | Multiple managers |
-| VP of Engineering | M4 | Engineering org | Directors |
-| CTO | M5 | Technical organization + strategy | VPs |
-
-**IC vs. Management track:** Explicitly separate. Senior ICs should not need to move to management for career advancement. Staff/Principal/Distinguished track provides this.
-
-### Go-to-Market Title Ladder (example)
-
-| Title | Level | Focus |
-|-------|-------|-------|
-| SDR / BDR | S1 | Outbound prospecting |
-| Account Executive I | S2 | SMB closing |
-| Account Executive II | S3 | Mid-market closing |
-| Senior Account Executive | S4 | Enterprise closing |
-| Principal / Strategic AE | S5 | Named accounts, complex deals |
-| Sales Manager | M1 | 6–8 reps |
-| Director of Sales | M2 | Multiple teams or segments |
-| VP of Sales | M3 | Full sales org |
-| CRO | M4 | Revenue org (sales + CS + marketing) |
-
----
-
-## Career Ladders
-
-A career ladder is a documented set of expectations per level. Not aspirational — behavioral. "What does a P3 engineer do that a P2 doesn't?"
-
-### Why career ladders matter for HR
-
-1. **Retention:** Employees can see where they're going
-2. **Consistency:** Managers use the same criteria for promotions
-3. **Compensation:** Bands anchor to levels; levels require definitions
-4. **Equity:** Removes "who's the manager's favorite" from promotion decisions
-
-### Career Ladder Structure
-
-For each level, define 4 dimensions:
-
-**1. Scope** — How big is the problem space? Team / cross-team / org-wide / company-wide?
-**2. Impact** — How does work connect to outcomes? (Task → Feature → Product → Business)
-**3. Craft** — Technical/functional skill expectations
-**4. Influence** — How does this person improve others? (Self → peers → team → org)
-
-**Example: Senior Software Engineer (L3) vs. Staff Software Engineer (L4)**
-
-| Dimension | L3 (Senior SWE) | L4 (Staff SWE) |
-|-----------|----------------|----------------|
-| Scope | Owns features or services | Owns technical domains across teams |
-| Impact | Ships features that improve user outcomes | Shapes technical direction for a product area |
-| Craft | Writes high-quality code, good design skills | Sets coding standards, contributes to architecture |
-| Influence | Mentors L1–L2, code reviews | Mentors L3+, identifies org-wide technical gaps |
-
-### How to build a career ladder from scratch
-
-1. **Interview your best performers** — "What do you do that your junior peers don't?" Collect behaviors, not aspirations.
-2. **Draft 3 levels** — Don't start with 6. Start with junior, mid, senior. Add staff/principal only when you have enough people to warrant it.
-3. **Manager calibration** — Every manager rates 5 current employees against the draft. Gaps surface immediately.
-4. **Publish and iterate** — Don't wait for perfection. A 70% ladder shipped is better than a 100% ladder in a drawer.
-
----
-
-## Reorg Playbook
-
-### When reorgs are necessary
-- Strategy pivot requires different team structure (e.g., single product → multi-product)
-- Acquisition or team merger
-- Function is genuinely too slow due to coordination overhead
-- Leadership departure creates structural opportunity
-
-### When reorgs are a mistake
-- "We need to shake things up" (disruption for its own sake)
-- Avoiding a specific personnel decision (use the right tool)
-- Solving a cultural problem with a structural change
-- Reacting to one team's complaint without systemic evidence
-
-### Reorg Process (4–8 weeks)
-
-**Week 1–2: Diagnose**
-- Map current org: every role, reporting line, team output
-- Identify where work is slow, duplicated, or falling through cracks
-- Interview 5–10 people across teams: "What takes longer than it should? What decisions are hard to make?"
-
-**Week 3–4: Design options**
-- Draft 2–3 structural alternatives
-- For each: estimated coordination costs, manager span impact, open roles created
-- Validate with CEO + 1–2 trusted operators. Don't crowdsource the design.
-
-**Week 5–6: Decide and prepare**
-- Select option; finalize all reporting changes
-- Prepare communications for every affected person (individual conversations before all-hands)
-- Write the "why" — employees need to understand the business reason, not just the result
-
-**Week 7–8: Communicate and implement**
-- Individual conversations with all manager+ changes (first)
-- Team-level conversations with managers (second)
-- All-hands with full context (third)
-- Updated org chart published within 24 hours of announcement
-
-### Communication sequence (non-negotiable)
-
-1. Affected individuals first (private, before anything else)
-2. Affected managers second (to prepare for team conversations)
-3. Full team/company third (all-hands or company note)
-4. External (clients, board) only if materially impacted
-
-**Never:** Email blast first. No individual conversations. Discovered on the org chart.
-
----
-
-## Founder → Professional Management Transition
-
-The most common scaling failure point in startups.
-
-### Stage 1: Founder-Led (0–30 people)
-
-Founders make all decisions, know everyone personally, set culture through behavior. Works because trust and context are built directly.
-
-**What breaks:**
-- Decisions bottleneck at founders
-- New hires don't get enough context (founders can't be everywhere)
-- Culture transmitted through osmosis, not documentation
-
-### Stage 2: First Managers (30–80 people)
-
-Founders can no longer manage all ICs. First manager layer typically = promoted high performers.
-
-**The "brilliant IC → struggling manager" trap:**
-- Individual contributor skills ≠ management skills
-- Promoted ICs often continue doing IC work while ignoring management work
-- No one holds them accountable to management output (1:1 quality, team health, performance feedback)
-
-**What to do:**
-- Explicit manager training before promotion (not after)
-- Management KPIs separate from IC KPIs
-- Peer community for new managers (monthly cohort session)
-- HR check-ins on manager health at 30/60/90 days
-
-### Stage 3: Professional Management (80–200 people)
-
-External hires at Director/VP level bring professional management skills but lack company context.
-
-**Common failure modes:**
-- Hired "too senior" — VP who's used to 200-person teams in a 50-person function
-- Culture clash — Big-company manager who adds process that kills startup speed
-- Authority vacuum — External VP doesn't earn trust; team ignores them; founder continues to bypass hierarchy
-
-**Mitigation:**
-- Hiring bar: Has this person scaled from this stage to 2x this stage before? Not managed a team at 2x — built a team to 2x.
-- Explicit onboarding on "how we make decisions here"
-- 90-day milestones focused on relationship-building before any structural changes
-- Founders explicitly hand off ownership and reinforce new manager's authority publicly
-
-### Stage 4: Founder Transition from Operator to Executive
-
-The hardest personal transition. Founder moves from doing to enabling.
-
-**Signs you haven't made the transition:**
-- You're still in every technical decision
-- Teams come to you instead of their manager for approvals
-- You know more about the team's work than the manager does
-- Managers feel they need to check in before acting
-
-**What the transition requires:**
-- Explicit authority delegation in writing (not just verbal)
-- Willingness to let managers make decisions you'd make differently
-- Redirecting team members to their manager consistently
-- Measuring managers on outcomes, not just process adherence
-- Letting managers hire and fire without founder override (except final call on VPs)

package/skills/jarvis/engineering-team/c-level-advisor/chro-advisor/references/people_strategy.md

@@ -1,320 +0,0 @@
-# People Strategy Reference
-
-Hiring, retention, performance, and remote/hybrid frameworks for each growth stage.
-
----
-
-## Hiring Strategy by Growth Stage
-
-### Pre-Seed / Seed (1–15 people)
-
-**Who you're hiring:** Generalists who can do multiple jobs. Specialists are a luxury you can't afford unless the specialty is your core product.
-
-**The test:** Could this person be the 5th employee at a startup and thrive? If they need a defined role, clear process, and a manager — not yet.
-
-**Sourcing at this stage:**
-- Founder networks first (highest signal, lowest cost)
-- Angel List / Wellfound — self-selected for startup risk tolerance
-- Referrals from existing employees (offer a referral bonus from day 1)
-- GitHub / Dribbble / published work for technical roles
-- Avoid: Big job boards, recruiters (unless technical retained search for C-suite)
-
-**Interview process (keep it lean):**
-1. 30-min intro call (culture/motivation fit, comp alignment)
-2. Take-home or live work sample (2–4 hours max, paid for senior roles)
-3. 60-min deep-dive with founders
-4. Reference checks (3 calls, not emails — you want the real story)
-
-**Offer timeline:** Decision within 48 hours. Top candidates have multiple offers.
-
-**What to get right:**
-- Written job scorecard (outcomes expected in 30/60/90 days) — not a job description
-- Equity range disclosed in first conversation
-- No exploding offers. Pressure tactics lose good people.
-
----
-
-### Series A (15–50 people)
-
-**The hiring shift:** You need some specialists now. First management layer emerges. First "culture carries" — people who reinforce what you want to become.
-
-**Critical hires at this stage (in priority order):**
-1. VP/Head of Engineering (if founder isn't technical)
-2. Head of Product
-3. First dedicated recruiter (when you're hiring > 10/year)
-4. First Finance/Operations hire
-5. Head of Sales (when product-market fit is real)
-
-**Building the recruiting function:**
-- First recruiter should be a generalist with hustle, not a specialist
-- Set up an ATS (Ashby, Greenhouse, or Lever) before you need it — not after
-- Create interview scorecards for every role
-- Track: time to fill, offer acceptance rate, source quality
-
-**Common mistakes at Series A:**
-- Promoting top ICs to management without management training
-- Hiring "brand name" executives who've never operated lean
-- Over-indexing on experience, under-indexing on trajectory
-- No onboarding process → 90-day regrettable turnover
-
-**Job scorecards (required for every role):**
-```
-Role: [Title]
-Reports to: [Manager]
-Start date: [Target]
-Why this role now: [Business case in 1-2 sentences]
-
-Outcomes (90 days):
-- [Concrete deliverable 1]
-- [Concrete deliverable 2]
-- [Concrete deliverable 3]
-
-Outcomes (12 months):
-- [Strategic impact 1]
-- [Strategic impact 2]
-
-Competencies (top 3 only):
-- [What, why it matters for THIS role]
-- [What, why it matters for THIS role]
-- [What, why it matters for THIS role]
-
-Comp range: [Base] + [Equity] + [Benefits summary]
-```
-
----
-
-### Series B (50–150 people)
-
-**The scaling inflection point.** Tribal knowledge breaks. Process matters now. Culture requires deliberate investment.
-
-**What changes:**
-- Recruiters become specialists (technical, GTM, exec)
-- Manager training becomes non-negotiable
-- Performance management needs structure (not just "we'll know it when we see it")
-- Onboarding needs to scale without founders in every session
-- Comp bands become essential — people are comparing notes
-
-**Hiring velocity benchmarks (Series B):**
-| Function | Avg time to fill | Avg interviews | Benchmark offer acceptance |
-|----------|-----------------|----------------|---------------------------|
-| Engineering IC | 35–45 days | 4–5 rounds | 80–85% |
-| Engineering Manager | 45–60 days | 5–6 rounds | 75–80% |
-| Sales IC | 25–35 days | 3–4 rounds | 85–90% |
-| Sales Manager | 40–55 days | 4–5 rounds | 80–85% |
-| G&A (Finance, HR, Ops) | 30–45 days | 3–4 rounds | 85–90% |
-
-**Internal mobility:** By 50 people, start tracking internal promotion rates. Target: 20–30% of manager+ roles filled internally. If it's < 10%, your career development is failing.
-
----
-
-### Series C+ (150+ people)
-
-**Professional management era.** Founders can't know everyone. Systems and culture carry what personal relationships used to.
-
-**HR function maturity required:**
-- Dedicated HRBPs per business unit (1:75–100 employees)
-- L&D budget (1–2% of salary budget minimum)
-- Succession planning for all VP+ roles
-- Structured calibration process for performance reviews
-- Total rewards strategy reviewed annually with board
-
----
-
-## Retention Programs That Actually Work
-
-### What drives retention (in order of impact)
-
-1. **Manager quality** — Gallup: 70% of team engagement variance is explained by the manager. Fix managers first.
-2. **Growth trajectory** — People leave when they can't see their next role. Career ladders are retention tools.
-3. **Compensation competitiveness** — Being at P25 on salary is a slow leak. Audit annually.
-4. **Mission/product belief** — Especially for senior ICs. They want to work on something that matters.
-5. **Team quality** — "I stay because of the people I work with." True at every level.
-6. **Flexibility** — Location, hours, autonomy. Low cost, high impact.
-
-### What doesn't work (but companies do anyway)
-- Pizza parties and ping pong tables
-- "Perks" that substitute for salary
-- Annual reviews with no action on feedback
-- Forced fun events
-- Vague "culture improvement" initiatives without specific behavior changes
-
-### The 30-60-90 Onboarding Framework
-
-Structured onboarding cuts 90-day turnover by 50%+.
-
-**Days 1–30: Learn**
-- Complete admin setup (day 1, before lunch)
-- Meet all key stakeholders (scheduled by their manager, not on the new hire)
-- Understand: business model, current priorities, team processes, how success is measured
-- No deliverables expected. Learning is the job.
-- Weekly 1:1 with manager: "What's confusing? What do you need?"
-
-**Days 31–60: Contribute**
-- First real project (scoped to be completable)
-- Present findings or work to the team
-- Identify one process that could be improved (observation only — don't fix yet)
-- 30-day check-in: formal feedback from manager
-
-**Days 61–90: Lead**
-- Own a deliverable end-to-end
-- Offer one specific improvement recommendation with data
-- 90-day review: mutual assessment — manager on new hire, new hire on onboarding
-- Set 6-month goals
-
-### Stay Interviews (underused, high ROI)
-
-Run with every employee once per year. Not their manager — HR or skip-level.
-
-**Questions that surface real risk:**
-- "What's keeping you here?"
-- "What would make you consider leaving?"
-- "What's one thing your manager could do differently?"
-- "Is your role what you expected when you joined?"
-- "What career path do you want? Are we helping you get there?"
-- "Are you fairly compensated? Do you know how you'd get a raise?"
-
-**Act on answers within 30 days or don't ask.** Unanswered feedback is worse than no feedback.
-
-### Exit Interviews — What to Actually Learn
-
-Skip the happiness survey. Ask these:
-- "When did you first think about leaving?"
-- "Was there a specific event that triggered your decision?"
-- "What could we have done to retain you?"
-- "Where are you going and why?" (What does the other offer have that we don't?)
-- "Would you recommend us as an employer? Why or why not?"
-
-Track exit themes by manager. If one manager's exits cite "micromanagement" three times — that's data.
-
----
-
-## Performance Management
-
-### The System That Works
-
-**Continuous > annual.** Annual reviews with no mid-year touchpoints are theater.
-
-**Structure:**
-- **Weekly 1:1s** (30 min): blockers, priorities, relationship
-- **Monthly check-ins** (1 hr): progress against goals, feedback exchange
-- **Quarterly reviews** (formal): written self-assessment + manager assessment + goal revision
-- **Annual calibration** (rating + comp): cross-manager calibration session, then individual conversations
-
-### Calibration Sessions
-
-**Purpose:** Prevent manager bias. Ensure "exceeds expectations" means the same thing across teams.
-
-**Process:**
-1. Managers submit preliminary ratings independently
-2. HR facilitates 2-hr calibration with all managers in a function
-3. Managers must justify outliers (top and bottom)
-4. Ratings adjusted for consistency
-5. Managers deliver final ratings with rationale
-
-**Distribution guidance (enforce with calibration):**
-- Exceptional (5): < 10% — if everyone's exceptional, no one is
-- Exceeds (4): 20–25%
-- Meets (3): 55–65%
-- Needs improvement (2): 8–12%
-- Underperforming (1): 2–5%
-
-### Managing Underperformers
-
-**The most avoided management task. And the most damaging when avoided.**
-
-High performers notice when underperformers are tolerated. They leave.
-
-**The 4-step framework:**
-
-**Step 1: Diagnose before acting** (Week 1–2)
-- Is this a skill gap (can't do it) or a will gap (won't do it)?
-- Skill gap → training, clearer expectations, different role
-- Will gap → direct feedback, clear consequences, then PIP
-
-**Step 2: Direct feedback conversation** (Week 2–3)
-- Specific: "Your last 3 sprint deliveries were 40% incomplete"
-- Not: "You're not meeting expectations"
-- Document. Send written summary after every feedback conversation.
-
-**Step 3: Performance Improvement Plan (PIP)**
-Required when: two rounds of direct feedback haven't produced change.
-
-PIP structure:
-```
-Name: [Employee]
-Manager: [Name]
-Date: [Start]
-Review date: [30/60 days out]
-
-Current performance issues:
-- [Specific, observable behavior with examples and dates]
-- [Metric not met: target X, actual Y for Z weeks]
-
-Required improvements:
-- [Specific, measurable outcome 1] by [date]
-- [Specific, measurable outcome 2] by [date]
-
-Support provided:
-- [Training, coaching, additional resources]
-
-Consequences if not met: [Role change / separation]
-
-Check-in schedule: [Weekly with manager + HR]
-```
-
-**Step 4: Exit or role change**
-- If PIP milestones not met: proceed to separation
-- Don't extend PIPs indefinitely — it's unfair to the employee and the team
-- Offer a graceful exit where possible: "This role isn't the right fit. Here's a package and a reference."
-
-**What not to do:**
-- "Quiet manage out" without clear feedback (legally risky, unfair)
-- PIP as a formality before termination (if you know you're firing them, just do it)
-- Tolerating underperformance "because we're understaffed" (it makes understaffing worse)
-
----
-
-## Remote / Hybrid Strategy
-
-### The question isn't "remote or not" — it's "what kind of collaboration does our work require?"
-
-**Work type taxonomy:**
-| Work type | Remote-compatible? | Hybrid compatible? |
-|-----------|-------------------|-------------------|
-| Deep individual work (coding, writing, analysis) | Yes | Yes |
-| Async collaboration (code review, doc review) | Yes | Yes |
-| Synchronous problem-solving (debugging, design) | Yes (video) | Yes |
-| Relationship-building (onboarding, new team) | Harder | Yes |
-| Executive alignment, strategy | Harder | Yes — quarterly in-person |
-| Sales (enterprise, relationship-based) | No | Depends on market |
-
-### Making Hybrid Work (Not Just a Policy)
-
-**The failure mode:** "Hybrid" = go to office on Tuesday/Thursday, but no one coordinates, all meetings are still Zoom anyway.
-
-**What actually works:**
-
-1. **Anchor days with purpose** — Office days should have things that require the office: workshops, team rituals, whiteboarding sessions. Not just "presence."
-
-2. **Async-first culture, not async-only** — Document decisions. Write things down. Use Loom for walkthroughs. Reduce "quick sync" meetings.
-
-3. **Equal experience for remote participants** — If some are in the room and some are on video, the remote folks are second-class. Either everyone's remote or set up rooms properly.
-
-4. **Manager standards for remote teams:**
-   - 1:1s are non-negotiable (video, not async)
-   - Over-communicate on priorities (people can't absorb hallway context)
-   - Write down decisions (remote employees miss casual office decisions)
-   - Recognize work publicly (Slack shoutouts, all-hands wins)
-
-### Remote Compensation Philosophy (pick one, be explicit)
-
-**Option A: Location-based pay**
-Pay based on where the employee lives. Lower cost in lower-cost markets. Harder to hire in high-cost cities.
-
-**Option B: Role-based (location-neutral)**
-One band for each role regardless of location. Simpler, more equitable. Higher overall payroll cost.
-
-**Option C: Zone-based**
-Define 2–3 geographic zones (e.g., Tier 1 cities, Tier 2 cities, international). Set bands per zone. Common at mid-stage startups.
-
-**The wrong answer:** No stated policy, and every offer is negotiated individually. Creates pay equity problems fast.