Table of Contents

1. Overview
2. Team Structure Patterns
3. Domain-Driven Team Organization
4. Architectural Roles & Responsibilities
5. Collaboration Patterns
6. Scaling Team Structures

---

Overview

Team architecture refers to how development teams are structured, how they interact, and how architectural decisions are made and governed across the organization. Effective team architecture aligns team boundaries with system boundaries, promotes autonomy while maintaining consistency, and enables teams to deliver value independently.

Why Team Architecture Matters

• Conway’s Law: Organizations design systems that mirror their communication structure
• Autonomy: Well-structured teams can make decisions and deliver without excessive coordination
• Consistency: Clear architectural roles ensure consistency across teams
• Scalability: Good team architecture enables organizations to scale development efforts
• Quality: Clear ownership leads to better system design and code quality

---

Team Structure Patterns

Feature Teams vs. Component Teams

Feature Teams

What they are: Cross-functional teams organized around business features or customer-facing capabilities.

Structure:

• Include all skills needed to deliver end-to-end features (frontend, backend, database, etc.)
• Own complete vertical slices of functionality
• Responsible for full lifecycle (development, testing, deployment, maintenance)

When to use:

• Product-focused organizations
• When delivering customer value quickly is priority
• Teams working on distinct product areas
• Organizations embracing microservices

Benefits:

• Faster delivery of customer value
• Reduced handoffs and dependencies
• Clear ownership and accountability
• Better understanding of business domain

Challenges:

• Potential code duplication across teams
• Maintaining technical consistency
• Shared component ownership can be unclear

Component Teams

What they are: Teams organized around technical components or layers (UI team, API team, database team).

Structure:

• Specialized by technical layer or component
• Deep expertise in specific technologies
• Work on requests from multiple feature teams

When to use:

• Legacy systems with strong layer coupling
• Highly specialized technical domains
• Platform or infrastructure teams
• Organizations with strong architectural governance

Benefits:

• Deep technical expertise
• Consistency within technical domains
• Efficient use of specialized skills
• Easier to maintain technical standards

Challenges:

• Handoffs between teams slow delivery
• Lack of end-to-end ownership
• Harder to prioritize work
• Risk of becoming bottlenecks

Hybrid Models

Practical Reality: Most organizations use a hybrid approach:

• Feature teams for product development
• Platform/component teams for shared infrastructure (authentication, data platform, CI/CD)
• Architecture team for governance and standards

---

Domain-Driven Team Organization

Bounded Contexts and Team Boundaries

Bounded Context: A logical boundary within which a particular domain model is defined and applicable.

Aligning teams with bounded contexts:

• Each team owns one or more bounded contexts
• Context boundaries define team boundaries
• Clear interfaces between contexts minimize coordination
• Teams can evolve their context independently

Domain APIs Within Monoliths

Even in monolithic applications, domain-driven organization provides benefits:

Internal Domain APIs:

• Each domain exposes clear API boundaries
• Other domains interact through these APIs, not direct database access
• Enables future extraction to microservices
• Maintains encapsulation and reduces coupling

Example in a Monolithic E-Commerce System:

• Catalog Domain: Product information, categories, search
• Order Domain: Order management, order history
• Payment Domain: Payment processing, billing
• Shipping Domain: Shipping calculation, fulfillment tracking

Each domain has clear APIs, even though all code is in one codebase.

Team Ownership

Clear Responsibility:

• Each team owns their domain’s code, data, and services
• Teams responsible for quality, performance, and reliability of their domain
• Teams handle operational support for their domain

Benefits:

• Reduced cognitive load (teams focus on their domain)
• Faster decision-making within domain boundaries
• Clear accountability
• Domain expertise develops naturally

---

Architectural Roles & Responsibilities

Optimal Team Structure

For organizations with significant architectural complexity, consider this structure:

System Architect

Responsibilities:

• Define overall technical vision and strategy
• Establish architectural standards and patterns
• Review and approve significant architectural decisions
• Ensure system-wide quality attributes (performance, security, scalability)
• Facilitate architecture reviews across teams
• Mentor layer architects and senior engineers

Skills:

• Broad technical expertise across all layers
• Strong communication and leadership
• Strategic thinking and business alignment
• Experience with multiple architectural styles

Layer Architects / Technical Leads

UI Architect:

• Define frontend architecture and standards
• Ensure consistent user experience across features
• Select and govern frontend frameworks and libraries
• Lead UI technology decisions
• Coordinate feature team frontend work

Service/API Architect:

• Define service architecture and API standards
• Ensure API consistency and quality
• Govern service communication patterns
• Lead backend technology decisions
• Design integration patterns

Data Architect:

• Define data architecture and storage strategies
• Ensure data consistency and integrity
• Govern database technologies and patterns
• Design data access layers
• Plan data migration and evolution strategies

Responsibilities shared across layer architects:

• Lead technical design in their domain
• Review and approve designs in their layer
• Provide technical guidance to feature teams
• Maintain and evolve layer-specific standards
• Coordinate with other layer architects

Feature Team Leads

Responsibilities:

• Lead feature team delivery and execution
• Participate in architectural discussions
• Ensure team follows architectural standards
• Escalate architectural concerns
• Facilitate team collaboration and decision-making

Skills:

• Technical leadership within domain
• Good understanding of system architecture
• Collaboration and communication
• Domain/business knowledge

Architecture Review Process

Regular Architecture Reviews:

• Scheduled design review sessions (weekly or bi-weekly)
• Teams present significant design decisions
• System architect and relevant layer architects review
• Identify cross-team impacts and dependencies
• Ensure alignment with architectural principles

When to Require Architecture Review:

• New services or major components
• Changes to APIs or interfaces
• New technology introductions
• Significant refactoring efforts
• Cross-team dependencies

---

Collaboration Patterns

Cross-Team Coordination

UI Architect Leadership: When feature teams need to coordinate on user-facing functionality:

• UI Architect leads design sessions
• Ensure consistent user experience
• Define shared UI components and patterns
• Coordinate frontend technology decisions
• Resolve conflicts between team preferences

Service Architect Leadership: When teams need to integrate services or APIs:

• Service Architect facilitates integration design
• Define API contracts and integration patterns
• Ensure service autonomy and loose coupling
• Review performance and scalability implications

Data Architect Leadership: When teams share data or need data integration:

• Data Architect designs data sharing strategies
• Define data ownership and access patterns
• Plan for data consistency and synchronization
• Review data model changes for cross-team impact

Communication Structures

Preventing Silos:

• Regular cross-team technical discussions
• Architectural guild meetings
• Internal tech talks and knowledge sharing
• Rotation programs between teams
• Shared documentation and decision records

Ensuring Alignment:

• Clear architectural principles and standards
• Architecture Decision Records (ADRs)
• Regular architecture review meetings
• Cross-team retrospectives
• Technical roadmap visibility

Inner Source Practices

Enabling Cross-Team Contributions:

• Well-documented codebases with contribution guides
• Code ownership files (CODEOWNERS)
• Open pull requests visible to all teams
• Cross-team code reviews encouraged
• Shared coding standards and tools

Benefits:

• Reduces duplication through code reuse
• Spreads knowledge across teams
• Faster resolution of cross-cutting issues
• Builds collaborative culture

---

Scaling Team Structures

Small Organizations (1-3 Teams)

Structure:

• Lightweight architectural governance
• Shared system architect role (may be senior engineer)
• Feature teams with cross-functional skills
• Frequent informal coordination

Focus:

• Establish architectural principles early
• Build foundation for scaling
• Maintain high communication frequency
• Document key decisions

Medium Organizations (4-10 Teams)

Structure:

• Dedicated system architect
• Layer architects or technical leads
• Mix of feature teams and platform teams
• Regular architecture review meetings

Focus:

• Formalize architectural governance
• Establish clear team boundaries
• Define inter-team interfaces
• Balance autonomy with consistency

Large Organizations (10+ Teams)

Structure:

• Architecture team with system and layer architects
• Multiple product-focused feature teams
• Dedicated platform and infrastructure teams
• Formal architecture review boards
• Communities of practice by technology or domain

Focus:

• Maintain architectural consistency at scale
• Enable team autonomy through clear standards
• Platform teams provide self-service capabilities
• Strong documentation and decision-making processes

Two-Pizza Team Rule

Amazon’s guideline: Teams should be small enough to feed with two pizzas (typically 6-10 people).

Why it works:

• Smaller teams have better communication
• Reduced coordination overhead
• Faster decision-making
• Clearer accountability

When teams grow beyond 10:

• Consider splitting by domain or feature area
• Ensure clear boundaries and interfaces
• May require additional coordination mechanisms

---

Team Anti-Patterns to Avoid

The Knowledge Silo

Problem: Critical knowledge concentrated in single individuals or small groups.

Solution:

• Pair programming and mob programming
• Code review requirements
• Documentation of key decisions and systems
• Knowledge sharing sessions
• Rotation through different areas

The Bottleneck Team

Problem: A team that all other teams depend on, slowing everyone down.

Solution:

• Build self-service platforms
• Delegate decision-making authority
• Increase team capacity
• Reduce dependencies through better boundaries

The Ivory Tower Architects

Problem: Architects disconnected from implementation, making impractical decisions.

Solution:

• Architects stay close to code
• Regular involvement in code reviews
• Time spent on hands-on technical work
• Proof-of-concept implementations
• Close collaboration with development teams

The Competitive Teams

Problem: Teams competing rather than collaborating, duplicating work or working at cross purposes.

Solution:

• Align incentives around shared goals
• Encourage cross-team collaboration
• Celebrate collective wins
• Clear domain boundaries
• Regular cross-team communication

---

Keys to Successful Team Architecture

1. Align Team Structure with System Architecture: Use Conway’s Law to your advantage
2. Balance Autonomy and Alignment: Teams need freedom to move fast, but consistency is important
3. Clear Ownership: Every piece of code, service, and domain should have a clear owner
4. Invest in Platforms: Platform teams enable feature team autonomy
5. Communication Over Process: Good communication reduces the need for heavy coordination processes
6. Evolve Continuously: Team structure should adapt as the organization and system evolve