vibecosystem

VP Engineering Perspective

Engineering Org Design (Team Topologies)

Team Types

| Type | Purpose | Characteristics | Size | |------|---------|----------------|------| | Stream-aligned | Deliver user/business value | Full-stack, autonomous, owns entire feature slice | 5-8 | | Platform | Reduce cognitive load for stream teams | Internal products, self-service APIs/tools | 3-6 | | Enabling | Help teams adopt new capabilities | Coaching, not doing; temporary engagement | 2-3 | | Complicated subsystem | Deep specialist expertise | ML, payments, security, real-time systems | 2-4 |

Interaction Modes

| Mode | Description | When to Use | |------|-------------|-------------| | Collaboration | Teams work together closely | New capability discovery, high uncertainty | | X-as-a-Service | One team provides, other consumes | Well-defined API/platform capability | | Facilitating | One team coaches another | Skill transfer, technology adoption |

Org Design Template

## Engineering Organization: [Company Name]

### Team Map

Stream-aligned Teams:
├── Team Alpha: [product area] (5 people)
│   Owns: [service/feature list]
│   Stack: [tech stack]
├── Team Beta: [product area] (6 people)
│   Owns: [service/feature list]
│   Stack: [tech stack]
└── Team Gamma: [product area] (5 people)
    Owns: [service/feature list]
    Stack: [tech stack]

Platform Team:
└── Team Platform (4 people)
    Provides: CI/CD, observability, developer portal
    Interaction: X-as-a-Service

Enabling Team:
└── Team Enable (2 people)
    Focus: [current initiative - e.g., Kubernetes migration]
    Interaction: Facilitating (rotates every quarter)

Complicated Subsystem:
└── Team ML (3 people)
    Owns: ML pipeline, model serving, feature store
    Interaction: Collaboration with stream teams

### Cognitive Load Assessment
| Team | Intrinsic (domain) | Extraneous (tools) | Total | Status |
|------|-------------------|--------------------|----|--------|
| Alpha | 6/10 | 3/10 | 9/10 | At capacity |
| Beta | 5/10 | 4/10 | 9/10 | At capacity |
| Platform | 7/10 | 2/10 | 9/10 | At capacity |

Org Design Anti-Patterns

| Anti-Pattern | Symptom | Fix | |-------------|---------|-----| | Conway's Law violation | Architecture doesn't match team structure | Align teams to desired architecture | | Shared services bottleneck | Every team waits for "core team" | Split into platform + self-service | | Matrix management | Unclear ownership, split loyalty | Single reporting line per IC | | Too many meetings | "Alignment" overhead > execution | Reduce interaction surface, use async | | Hero culture | One person knows everything | Document, pair, rotate on-call |

Process Improvement (Agile Maturity)

Agile Maturity Model

| Level | Name | Characteristics | |-------|------|----------------| | 1 | Initial | Ad-hoc, no process, firefighting | | 2 | Managed | Basic scrum/kanban, inconsistent | | 3 | Defined | Consistent process, metrics tracked | | 4 | Measured | Data-driven decisions, predictable delivery | | 5 | Optimizing | Continuous improvement, experiments |

Process Improvement Framework

## Process Improvement Cycle

### 1. Observe (1 sprint)
- Shadow team ceremonies
- Measure cycle time, WIP, defects
- Interview team members (1-on-1)

### 2. Diagnose
| Problem | Root Cause | Impact |
|---------|-----------|--------|
| [symptom] | [why] | [what it costs] |

### 3. Hypothesize
"If we [change], then [expected outcome], measured by [metric]"

### 4. Experiment (2-3 sprints)
- Implement ONE change at a time
- Measure baseline vs. new
- Collect team feedback

### 5. Evaluate
- Did the metric improve?
- Did the team feel the improvement?
- Any unintended side effects?

### 6. Adopt or Revert
- Improvement verified: document and standardize
- No improvement: revert and try next hypothesis

Common Process Fixes

| Problem | Fix | Metric | |---------|-----|--------| | Missed deadlines | Smaller stories, better estimation | Story completion rate | | Too much WIP | WIP limits (Kanban) | Cycle time | | Unclear requirements | Refinement meetings, acceptance criteria | Defect rate | | Deployment fear | Feature flags, canary deploys | Deploy frequency | | Slow code reviews | SLA (24h max), small PRs | Review turnaround | | Meeting overload | No-meeting days, async updates | Focus time % |

Cross-Team Dependency Management

Dependency Mapping

## Cross-Team Dependencies: [Quarter]

### Dependency Matrix
| Providing Team | Consuming Team | Dependency | Type | Status | Risk |
|---------------|---------------|-----------|------|--------|------|
| Platform | Alpha | Auth service v2 | Blocking | In progress | Medium |
| Alpha | Beta | User API | Non-blocking | Available | Low |
| ML | Gamma | Rec engine | Blocking | Not started | High |

### Dependency Types
- **Blocking:** Must be completed before consumer can start
- **Non-blocking:** Can work in parallel with mocked interface
- **Soft:** Nice to have, workaround exists

### Visualization
Team Alpha ──blocks──→ Team Beta (User API)
Team Platform ──blocks──→ Team Alpha (Auth v2)
Team ML ──blocks──→ Team Gamma (Rec engine) ← HIGH RISK

Dependency Resolution Strategies

| Strategy | When to Use | |----------|-------------| | Contract-first | Define API contract, both teams implement independently | | Embedded engineer | Loan an engineer from providing team | | Shared interface | Agree on interface, mock until ready | | Prioritize differently | Move blocking work to top of providing team's backlog | | Decouple | Feature flags, adapter pattern, event-driven | | Eliminate | Redesign to remove dependency entirely |

Dependency Anti-Patterns

| Anti-Pattern | Neden Yanlis | Dogru Yol | |-------------|-------------|-----------| | Hidden dependencies | Discovered too late | Map dependencies in planning | | Dependency as excuse | "Blocked by Team X" for weeks | Escalate immediately, find alternatives | | Hub team (everything flows through one) | Bottleneck | Distribute ownership, self-service | | Cross-team code ownership | Slow PRs, merge conflicts | Clear ownership boundaries |

Engineering Culture Building

Culture Pillars

## Engineering Culture: [Company Name]

### Our Values (with behaviors)

1. **Ownership**
   - Do: Take responsibility end-to-end (build, deploy, monitor)
   - Don't: "Not my code" / "That's ops problem"
   - Measure: On-call engagement, post-incident participation

2. **Craft**
   - Do: Write tests, review thoughtfully, refactor proactively
   - Don't: "Ship now, fix later" (unless P0)
   - Measure: Code review quality, tech debt ratio

3. **Transparency**
   - Do: Share context, document decisions, default to public channels
   - Don't: Hoarding information, private DMs for team decisions
   - Measure: Documentation coverage, team survey

4. **Learning**
   - Do: Blameless retros, share mistakes, invest in growth
   - Don't: Blame individuals, hide failures
   - Measure: Retro action items completed, conference talks

5. **Speed**
   - Do: Small PRs, feature flags, iterate quickly
   - Don't: Big bang releases, analysis paralysis
   - Measure: Lead time, deploy frequency

Culture Building Practices

| Practice | Frequency | Owner | Goal | |----------|-----------|-------|------| | Blameless post-mortems | Per incident | Engineering managers | Learn from failures | | Engineering all-hands | Monthly | VP Engineering | Alignment, wins, direction | | Tech talks / brown bags | Biweekly | Rotating engineers | Knowledge sharing | | Hack days / hackathon | Quarterly | Engineering leads | Innovation, morale | | Architecture review | Biweekly | Architects | Consi