What is it called?
👉 AI-Augmented Leadership, Human-AI Teaming, Future of Work

How is it actually done?

Key shifts from traditional to AI-augmented leadership:

AI-augmented team model:

Human Team Members          AI Agents
    ↓                        ↓
Collaborative Decision-Making
    ↓
Orchestrated by Leader
    ↓
Outcomes Delivered

Leader responsibilities in AI-augmented teams:

1. Define boundaries — what decisions are human-only vs AI vs collaborative
2. Establish guardrails — ensure AI operates within ethical, legal, and business constraints
3. Build AI literacy — ensure team understands AI capabilities/limitations
4. Foster psychological safety — encourage experimentation, admit AI mistakes
5. Measure outcomes — track team performance, not AI usage metrics

Key technical terms:

How dots connect:

• Assess team AI readiness → define decision rights → provide training → establish guardrails → measure outcomes → iterate

Technical flow:

Current State Assessment → AI Capability Mapping → Decision Rights Framework → Training Program → Guardrail Implementation → Outcome Metrics → Continuous Improvement

What is it called?
👉 Distributed Leadership, Remote-First Management, Asynchronous Collaboration

How is it actually done?

Principles of distributed leadership:

1. Context over control — provide clear goals and constraints, not step-by-step instructions
2. Async-first communication — default to async (documentation, Loom, text), synchronous only when necessary
3. Explicit documentation — decisions, processes, and knowledge are documented, not tribal
4. Outcome-based evaluation — measure results, not hours or activity
5. Intentional relationship-building — create opportunities for human connection despite distance

Tools and practices:

Communication:
  - Async: Slack (threaded), Notion, Confluence, Loom
  - Sync: Weekly team syncs, 1:1s, quarterly in-person offsites

Decision-Making:
  - RFC process (Request for Comments) for major decisions
  - Decision logs (ADRs) for transparency
  - Clear decision owners and escalation paths

Collaboration:
  - Pair programming with VS Code Live Share or Tuple
  - Miro/Mural for virtual workshops
  - GitHub PRs for code review asynchronously

Culture:
  - Virtual coffee chats (Donut random pairings)
  - Recognition channels (#kudos, #wins)
  - Value demonstration through actions, not just words

Common pitfalls:

• Proximity bias — favoring those in time zones or locations you're in
• Meeting overload — defaulting to sync meetings instead of async alternatives
• Documentation neglect — "we'll just explain it" → knowledge silos
• Burnout — always-on culture, unclear boundaries across time zones

Mitigation strategies:

• Rotate meeting times to share burden across time zones
• Establish core collaboration hours (4-5 hours overlap expectation)
• Budget for annual team offsites to build relationships
• Train managers on remote leadership skills
• Use "focus time" blocks and respect them

Key technical terms:

How dots connect:

• Async tools → async habits → async culture → distributed teams that function smoothly without constant oversight

Technical flow:

Tool Selection → Process Design → Manager Training → Team Onboarding → Iterate based on Feedback → Culture Establishment

What is it called?
👉 Decision Rights Framework, Delegation Matrix, Autonomy Spectrum

How is it actually done?

Step 1: Catalog decision types

Examples:

• Architectural decisions (tech stack, patterns)
• Product prioritization (what to build)
• Hiring decisions (who to hire)
• Budget allocation (how to spend money)
• Operational processes (how work gets done)
• Customer commitments (promises to customers)
• Security exceptions (deviations from security standards)

Step 2: Define roles

Common roles:

• Individual contributor/team
• Engineering manager
• Principal engineer/architect
• VP Engineering
• CTO
• Product manager
• Cross-functional forum

Step 3: Assign decision rights using autonomy spectrum

Decision rights matrix template:

Decision Type: Architecture Patterns
  Decide: Principal Engineers, Architects
  Input: Engineering teams
  Escalate: VP Engineering if cross-cutting
  AI Involvement: AI agents can recommend, humans decide

Decision Type: Hiring
  Decide: Hiring manager (after interview panel)
  Input: Interview team
  Approve: Engineering manager for L4+, VP for L6+
  Escalate: CTO for L7+ (Staff+)

Decision Type: Product Priorities
  Decide: Product Manager (with team input)
  Consult: Engineering manager, designers
  Escalate: VP Product if resource conflicts

Implementation:

1. Document decision rights in a shared matrix
2. Socialize and get buy-in from all stakeholders
3. Reference during meetings: "According to decision rights, who owns this?"
4. Review quarterly; adjust as organization evolves

Common challenges:

• Role ambiguity: Overlapping responsibilities → clarify through RACI-like diagrams
• Micromanagement: Leaders not delegating → coach on trust, set boundaries
• Decision paralysis: No one feels empowered → clarify who has final say
• AI decision boundaries: Unclear what agents can decide → create agent charters

Key technical terms:

How dots connect:

• Identify decision categories → define roles → assign rights (using autonomy levels) → document → socialize → reference in practice → review periodically

Technical flow:

Workshop with Leaders → Decision Catalog → Role Mapping → Autonomy Assignment → Documentation (RACI/Matrix) → Team Communication → Daily Referral → Quarterly Review → Update

What is it called?
👉 AI-Augmented Culture, Psychological Safety, Growth Mindset, Learning Organization

How is it actually done?

Cultural pillars for AI-augmented organizations:

1. Psychological Safety — "It's safe to admit AI mistakes, ask for help, challenge decisions"
2. Growth Mindset — "AI skills can be learned; we're all getting smarter together"
3. Experimentation — "Try AI tools, measure results, iterate" (safe to fail)
4. Transparency — "How and why we use AI is open and explainable"
5. Human-Centered — "AI augments humans; technology serves people, not vice versa"

Practical interventions:

Leadership Behaviors:
  - Admit your own AI limitations and learning journey
  - Celebrate "intelligent failures" from AI experiments
  - Reward sharing of AI knowledge and helping others
  - Ask "What did AI help you achieve?" in demos/retros

Team Practices:
  - Dedicated learning time (e.g., 4 hours/month for AI skill-building)
  - AI experimentation sprints with "show and tell"
  - Peer mentoring on AI tool mastery
  - Blameless post-mortems when AI systems cause issues

Organizational Support:
  - Budget for AI training and conferences
  - Internal AI guild or community of practice
  - Recognition programs for AI innovation
  - Career paths that reward AI-augmented productivity

Measuring culture change:

Common culture blockers:

• Fear — "AI will replace me" → address through transparent communication, reskilling promises
• Resistance — "We've always done it this way" → showcase quick wins, peer champions
• Surveillance creep — using AI to monitor employees → establish ethical guidelines
• Skill gap anxiety — "I can't learn this" → provide training, mentorship, time

Change management approach:

1. Assess current culture (surveys, interviews)
2. Define target state (what does AI-augmented culture look like?)
3. Identify gaps (what's blocking us?)
4. Design interventions (training, rituals, leadership modeling)
5. Pilot with volunteer teams
6. Scale iteratively based on learnings

Key technical terms:

How dots connect:

• Diagnose current culture → define aspirational culture → identify gaps → design interventions → pilot → measure → scale → continuous reinforcement

Technical flow:

Culture Assessment → Target State Definition → Intervention Design → Leadership Alignment → Pilot Execution → Metrics Collection → Adaptation & Scaling → Ongoing Reinforcement

What is it called?
👉 Fractional CTO, Part-time VP Engineering, Interim Leadership, CTO-as-a-Service

How is it actually done?

Common fractional models:

When to choose fractional vs full-time:

Fractional is ideal when:

• Revenue < $5M (can't justify full-time CTO salary)
• Co-founder with technical background needs strategic partner
• Organization is stable, needs occasional guidance
• Between full-time CTOs during transition
• Specific expertise needed (AI, platform, compliance)

Full-time is better when:

• Revenue > $10-15M with engineering org > 50 people
• Daily technical leadership required
• Deep organizational knowledge essential
• Hands-on architecture and code review needed

Fractional engagement structure:

Typical Week (Fractional CTO, 15 hrs/week):
  Monday: 2hrs - async review of PRs, decisions from weekend
  Tuesday: 3hrs - 1:1 with VP Engineering, team sync
  Wednesday: 3hrs - Architecture review meeting, ADR approvals
  Thursday: 3hrs - Strategy session with CEO, board meeting preparation
  Friday: 4hrs - Writing (documentation, roadmaps), async coaching

Monthly Focus:
  Week 1: Planning and alignment
  Week 2: Deep architecture work
  Week 3: Team enablement (1:1s, mentoring)
  Week 4: Executive leadership (CEO/Board)

Success factors for fractional leaders:

1. Clear scope — define what's in/out of scope upfront
2. Executive sponsor — direct access to CEO/board, not mediated through managers
3. Context sharing — regular updates, documentation, meeting invites
4. Team access — ability to meet with engineers, not just executives
5. Measurable outcomes — specific deliverables or KPIs

Common pitfalls:

• Scope creep — trying to do full-time work part-time → guardrails
• Being treated as junior — "just another contractor" → executive-level expectations
• Lack of context — decisions without full background → invest in knowledge transfer
• Team resistance — "part-timer can't understand our codebase" → demonstrate competence quickly

Pricing models:

• Monthly retainer ($8K-25K/month depending on experience, industry, time commitment)
• Daily rate ($1.5K-3K/day for workshops)
• Hourly ($250-500/hr for ad-hoc咨询)
• Equity + cash (early-stage startups, < $3M revenue)

Key technical terms:

How dots connect:

• Assess need → choose model → define scope → negotiate terms → onboard (context, team access) → deliver → review quarterly

Technical flow:

Client Assessment → Model Selection → Proposal & Contract → Knowledge Transfer → Regular Cadence (weekly/monthly) → Outcome Tracking → Quarterly Review → Renew/Adjust/Complete

What is it called?
👉 Team Topology, Role Clarity, Org Design, Team Cognitive Load

How is it actually done?

Team Topology patterns (from Team Topologies book):

AI-augmented team topologies:

[Product Teams]
  ↓ use
[Platform Teams]
  ↓ build & operate
[AI Infrastructure Team] ← New for AI workloads
  ↓ support
[Data & ML Teams]
  ↓ collaborate with
[Product Managers + Domain Experts]

Role clarity framework:

For each role define:

• Purpose: Why does this role exist?
• Accountabilities: What is this role responsible for (and NOT responsible for)?
• Decision rights: What decisions can this role make autonomously?
• Interface: Who does this role work with daily?
• Career ladder: Levels, expectations, promotion criteria

Example: AI Engineer role

Purpose: Build and maintain AI/ML systems that deliver business value
Accountabilities:
  - Design and implement AI models and pipelines
  - Ensure model performance, monitoring, and retraining
  - Collaborate with product on AI use cases
  - Stay current with AI research and tools
NOT Accountable for:
  - Traditional software development (unless full-stack AI)
  - Data engineering (separate data team)
  - Business outcomes (product manager owns that)
Decision Rights:
  - Choose AI frameworks and tools within approved list
  - Experiment with new AI techniques (within budget)
  - Escalate tech debt in AI infrastructure
Interface:
  - Works closely with: Data Engineers, Product Managers, ML Engineers
  - Reports to: Engineering Manager
  - Collaborates with: AI Governance team

Team cognitive load:

• Each team has limited capacity (cognitive load)
• Assign teams based on domain boundaries
• Avoid "spanish孵化器" (team that owns too many domains)
• Use the Conway's Law corollary: team boundaries shape system boundaries

Implementation checklist:

• Map current teams and roles
• Identify cognitive load issues (too broad, too many dependencies)
• Define target team topology (stream-aligned, platform, enabling, etc.)
• Create/modify team assignments
• Define roles with clear accountabilities
• Document and socialize
• Adjust based on feedback (iteration)

Common role definitions to update for AI era:

• Software Engineer → "AI-Augmented Software Engineer" (prompt engineering, AI coding tools)
• Tech Lead → "Technical Lead for AI-Integrated Systems" (architecture, AI governance)
• Product Manager → "AI Product Manager" (AI use case identification, ROI measurement)
• QA Engineer → "Quality Engineer for AI Systems" (AI testing, bias detection, robustness)

Key technical terms:

How dots connect:

• Analyze current state → determine target topology → design team boundaries → define roles → assign people → monitor cognitive load → adjust iteratively

Technical flow:

Current State Assessment → Cognitive Load Analysis → Target Team Topology Design → Role Definition → Team Assignments → Communication & Documentation → Monitor & Iterate