System Design (HLD)Migration Planning

Migration Planning

LevelAdvanced

Duration75 mins

TopicMigration Planning

2 / 5

Team Structure Considerations

Architecture Follows Organization

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." — Melvin Conway, 1967

This observation, known as Conway's Law, has profound implications for microservices migration. You cannot successfully transition to a distributed architecture while maintaining organizational structures optimized for monolithic development. The inverse is equally true: adopting microservices team structures while retaining a monolith creates friction, not value.

Every successful large-scale migration shares a common pattern: architectural transformation and organizational transformation proceed together. Teams are restructured to own services. Boundaries are redrawn to match domain contexts. Skills are developed to support distributed operations. Organizations that attempt microservices without organizational change consistently fail.

What You'll Learn

This page covers the organizational dimensions of migration planning: understanding Conway's Law and its inverse implications, evaluating team topologies for microservices, designing effective ownership models, addressing cross-cutting concerns, managing skill transitions, and structuring teams for both migration execution and long-term service ownership.

Conway's Law: The Invisible Force

Conway's Law isn't just an observation—it's a fundamental constraint that shapes every software system. When development organizations grow, they naturally partition into teams. These teams communicate internally with high bandwidth (same meetings, same code, same priorities) and externally with low bandwidth (formal APIs, scheduled syncs, ticket systems). This communication structure imprints directly onto the software.

Understanding the Imprinting Mechanism:

Monolith Organization Patterns

•Teams organized by technical layer (frontend, backend, DBA)
•Shared ownership of central codebase
•Cross-team coordination via architecture committees
•Deployment requires multi-team synchronization
•Skills specialized by technology rather than domain
•Long release cycles accommodate coordination overhead

Microservices Organization Patterns

•Teams organized by business domain/capability
•Clear ownership of specific services
•Integration via well-defined APIs and events
•Teams deploy independently on their schedule
•Full-stack skills within each domain team
•Continuous delivery enabled by team autonomy

The Inverse Conway Maneuver:

Smart organizations use Conway's Law strategically. Rather than accepting whatever architecture emerges from the current org structure, they design the organization to produce the desired architecture. This is called the Inverse Conway Maneuver:

Define target architecture: Design the microservices boundaries you want
Restructure teams to match: Create teams aligned to those boundaries
Let Conway's Law work for you: The organization naturally produces the target architecture

This approach is far more effective than trying to force an organizational structure to produce an architecture it's not optimized for.

The Org Chart Is Not the Architecture

A common mistake is assuming the formal org chart determines architecture. In reality, the actual communication patterns—who talks to whom, who attends which meetings, whose approval is required—shape the system. Map the real communication structure, not the official hierarchy, when planning team restructuring.

Team Topologies for Microservices

The Team Topologies framework, developed by Matthew Skelton and Manuel Pais, provides a structured approach to team organization optimized for fast flow of change. It defines four fundamental team types and three interaction modes that create sustainable patterns for microservices organizations.

The Four Fundamental Team Types:

Team Topologies: Core Team Types
Team Type	Purpose	Characteristics	Microservices Role
Stream-Aligned Teams	Deliver value in a specific business domain	Cross-functional, owns full feature delivery, autonomous deployment capability	Own and operate one or more closely related services within a bounded context
Platform Teams	Reduce cognitive load on stream-aligned teams	Provides self-service internal platforms, treats other teams as customers	Provides infrastructure, CI/CD, observability, service mesh, and other common capabilities
Enabling Teams	Help stream-aligned teams acquire new capabilities	Specialists who temporarily embed with teams, focus on knowledge transfer	During migration: help teams learn distributed systems patterns, testing strategies, etc.
Complicated Subsystem Teams	Handle complex technical domains requiring specialists	Deep expertise in specific area (ML, cryptography, etc.)	Own services requiring specialized skills that would overload stream-aligned teams

Team Interaction Modes:

How teams interact is as important as how they're structured:

Three Interaction Modes

•Collaboration Mode: Two teams work closely together on a shared goal. High communication, blurred boundaries. Use temporarily for exploration or complex integration. Expensive—don't maintain indefinitely.
•X-as-a-Service Mode: One team provides a capability that others consume via well-defined API. Clear boundaries, minimal direct communication. The target mode for most platform-to-stream relationships.
•Facilitating Mode: One team helps another acquire capabilities. Enabling team temporarily joins stream-aligned team, provides coaching/training, then exits. Used during migration transitions.

TeamTopologyExample.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
// Example: E-Commerce Platform Team Structure During Migration
 
interface Team {
  name: string;
  type: 'stream-aligned' | 'platform' | 'enabling' | 'complicated-subsystem';
  members: number;
  services: string[];
  interactionsWith: TeamInteraction[];
}
 
interface TeamInteraction {
  team: string;
  mode: 'collaboration' | 'x-as-a-service' | 'facilitating';
  purpose: string;
  duration: 'temporary' | 'ongoing';
}
 
const ecommerceTeamStructure: Team[] = [
  // STREAM-ALIGNED TEAMS (Deliver Business Value)
  {
    name: 'Order Management Team',
    type: 'stream-aligned',
    members: 7,
    services: ['order-service', 'order-history-service'],
    interactionsWith: [
      { team: 'Platform Team', mode: 'x-as-a-service', 
        purpose: 'CI/CD, monitoring, infrastructure', duration: 'ongoing' },
      { team: 'Payment Team', mode: 'x-as-a-service', 
        purpose: 'Process payments via Payment API', duration: 'ongoing' },
      { team: 'Migration Enablement', mode: 'facilitating', 
        purpose: 'Learn saga patterns for distributed transactions', duration: 'temporary' },
    ],
  },
  {
    name: 'Payment Team',
    type: 'stream-aligned',
    members: 6,
    services: ['payment-service', 'refund-service', 'wallet-service'],
    interactionsWith: [
      { team: 'Platform Team', mode: 'x-as-a-service', 
        purpose: 'Secrets management, PCI-compliant infrastructure', duration: 'ongoing' },
      { team: 'Fraud Detection Team', mode: 'x-as-a-service', 
        purpose: 'Fraud scoring via API', duration: 'ongoing' },
    ],
  },
  {
    name: 'Product Catalog Team',
    type: 'stream-aligned',
    members: 5,
    services: ['catalog-service', 'search-service', 'recommendation-service'],
    interactionsWith: [
      { team: 'Platform Team', mode: 'x-as-a-service', 
        purpose: 'Elasticsearch cluster, CDN', duration: 'ongoing' },
      { team: 'Inventory Team', mode: 'collaboration', 
        purpose: 'Define product-inventory sync mechanism', duration: 'temporary' },
    ],
  },
  {
    name: 'Inventory Team',
    type: 'stream-aligned',
    members: 4,
    services: ['inventory-service'],
    interactionsWith: [
      { team: 'Platform Team', mode: 'x-as-a-service', 
        purpose: 'Event streaming infrastructure', duration: 'ongoing' },
    ],
  },
  
  // PLATFORM TEAM
  {
    name: 'Platform Team',
    type: 'platform',
    members: 8,
    services: ['ci-cd-platform', 'monitoring-platform', 'service-mesh', 'secrets-manager'],
    interactionsWith: [
      // X-as-a-Service to all stream-aligned teams
      { team: 'All Stream-Aligned Teams', mode: 'x-as-a-service', 
        purpose: 'Self-service infrastructure and tooling', duration: 'ongoing' },
    ],
  },
  
  // ENABLING TEAM
  {
    name: 'Migration Enablement Team',
    type: 'enabling',
    members: 4,
    services: [], // Doesn't own services, enables others
    interactionsWith: [
      { team: 'Order Management Team', mode: 'facilitating', 
        purpose: 'Train on distributed transactions', duration: 'temporary' },
      { team: 'Product Catalog Team', mode: 'facilitating', 
        purpose: 'Help with search service extraction', duration: 'temporary' },
    ],
  },
  
  // COMPLICATED SUBSYSTEM TEAM
  {
    name: 'Fraud Detection Team',
    type: 'complicated-subsystem',
    members: 4,
    services: ['fraud-detection-service', 'ml-scoring-service'],
    interactionsWith: [
      { team: 'Payment Team', mode: 'x-as-a-service', 
        purpose: 'Provide fraud scoring API', duration: 'ongoing' },
      { team: 'Platform Team', mode: 'x-as-a-service', 
        purpose: 'ML infrastructure, model serving', duration: 'ongoing' },
    ],
  },
];

Team Size: The Two-Pizza Rule

Amazon's famous 'two-pizza team' rule suggests teams should be small enough to be fed with two pizzas. In practice, this means 5-9 people. Smaller teams communicate more efficiently, make decisions faster, and maintain stronger ownership. If your service boundaries require larger teams, consider whether the service should be further decomposed.

Ownership Models

Clear ownership is the backbone of successful microservices. Without it, services become orphans—maintained reluctantly, upgraded sporadically, and operated by whoever happens to be on-call when problems arise. Effective ownership creates accountability and enables autonomy.

The "You Build It, You Run It" Philosophy:

Amazon pioneered the insight that teams who build services should also operate them. This philosophy, articulated by Werner Vogels, creates powerful incentives:

Benefits of Full Ownership

•Quality Incentives: When you're on-call for your own code, you write more defensive code, better error handling, clearer logging.
•Operational Learning: Developers gain production insights that inform design decisions. They see how their code behaves under real load.
•Faster Debugging: The person who wrote the code debugs incidents faster than someone seeing it for the first time.
•Reduced Handoffs: No blame-passing between 'dev' and 'ops'. Single team owns the outcome.
•Continuous Improvement: Teams that operate services continuously improve operability based on pain points.

Shared Ownership Anti-Patterns:

Ownership Anti-Patterns to Avoid
Anti-Pattern	Symptoms	Consequences	Resolution
Orphan Service	No clear team ownership; service maintained 'by everyone'	No accountability; changes avoided; incidents handled reluctantly	Assign explicit ownership; treat as line item in team planning
Shared Service Committee	Multiple teams share ownership via rotating responsibilities	Slow decision-making; design by committee; conflicting priorities	Designate primary owner; others become consumers with influence rights
Operational Separation	Dev team builds, separate ops team runs	Blame shifting; operational requirements ignored; slow incident response	Move toward 'you build it, you run it'; SRE embedding if scale requires
Hero Dependency	Single person understands service; others defer to them	Single point of failure; no vacation; burnout risk	Knowledge sharing program; pair programming; documented runbooks
Cross-Team Sprawl	Service logic spread across multiple team codebases	No one can make complete changes; all changes require coordination	Consolidate logic into owning team's services; define clear APIs

OwnershipModel.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
// Explicit Ownership Model Documentation
 
interface ServiceOwnership {
  serviceId: string;
  serviceName: string;
  
  // Primary ownership
  owningTeam: Team;
  techLead: Person;          // Technical decisions
  productOwner: Person;       // Prioritization decisions
  
  // On-call responsibilities
  primaryOnCall: Person[];    // Current on-call rotation
  onCallSchedule: string;     // Link to schedule
  escalationPath: Person[];   // Who to escalate to
  
  // SLO commitments
  availabilitySLO: string;    // e.g., "99.9%"
  latencyP99SLO: string;      // e.g., "200ms"
  incidentResponseSLO: string; // e.g., "15 min to acknowledge"
  
  // Consumer relationships
  consumers: Consumer[];      // Who depends on this service
  
  // Governance
  changeApprovalRequired: Person[];  // Who approves breaking changes
  deprecationPolicy: string;  // How much notice for API changes
}
 
interface Consumer {
  team: Team;
  usagePattern: string;
  criticality: 'blocking' | 'important' | 'nice-to-have';
  slaExpectation: string;
  contactPerson: Person;
}
 
// Example
const orderServiceOwnership: ServiceOwnership = {
  serviceId: 'order-service',
  serviceName: 'Order Management Service',
  
  owningTeam: { name: 'Order Team', members: 7 },
  techLead: { name: 'Alice Chen', email: 'alice@company.com' },
  productOwner: { name: 'Bob Smith', email: 'bob@company.com' },
  
  primaryOnCall: [
    { name: 'Carol Davis', email: 'carol@company.com' },
    { name: 'Dan Wilson', email: 'dan@company.com' },
  ],
  onCallSchedule: 'https://pagerduty.com/schedules/order-team',
  escalationPath: [
    { name: 'Alice Chen (Tech Lead)', email: 'alice@company.com' },
    { name: 'VP Engineering', email: 'vpe@company.com' },
  ],
  
  availabilitySLO: '99.95%',
  latencyP99SLO: '400ms',
  incidentResponseSLO: '15 minutes to acknowledge, 1 hour to mitigate',
  
  consumers: [
    {
      team: { name: 'Mobile Team', members: 5 },
      usagePattern: 'Order creation, status queries',
      criticality: 'blocking',
      slaExpectation: 'Same as service SLO',
      contactPerson: { name: 'Eve Mobile', email: 'eve@company.com' },
    },
    {
      team: { name: 'Analytics Team', members: 3 },
      usagePattern: 'Batch order data export',
      criticality: 'nice-to-have',
      slaExpectation: 'Best effort',
      contactPerson: { name: 'Frank Analytics', email: 'frank@company.com' },
    },
  ],
  
  changeApprovalRequired: [
    { name: 'Alice Chen', email: 'alice@company.com' },
    { name: 'API Guild Lead', email: 'api-lead@company.com' },
  ],
  deprecationPolicy: '90 days notice for breaking changes; 30 days for deprecation',
};

Document Ownership Publicly

Ownership documentation should be publicly accessible, not buried in wikis. Many organizations embed ownership metadata in service registries or README files that tools can query. When incidents occur, anyone should be able to quickly answer: 'Who owns this service? Who's on-call? Who can I escalate to?'

Handling Cross-Cutting Concerns

Not everything fits neatly into service boundaries. Some concerns—security, observability, API design, data governance—cut across all services. How do you maintain consistency without creating central bottlenecks that undermine team autonomy?

Common Cross-Cutting Concerns:

Cross-Cutting Categories

•Security: Authentication, authorization, encryption, secrets management, vulnerability scanning
•Observability: Logging formats, metric collection, distributed tracing, alerting standards
•API Design: Naming conventions, versioning strategy, error formats, documentation requirements
•Data Governance: Privacy regulations, data retention, cross-border data handling
•Testing Standards: Test coverage requirements, integration test patterns, contract testing
•Deployment: CI/CD pipelines, rollout strategies, feature flag usage
•Reliability: SLO definitions, chaos engineering practices, incident management

Governance Models:

Cross-Cutting Concern Governance Models
Model	How It Works	Best For	Risks
Centralized Standards	Central team defines standards; all teams must comply	Security, compliance requirements	Bottleneck risk; standards lag team needs; resentment
Platform Abstraction	Platform team provides capability; teams consume via API/SDK	Observability, deployment, infrastructure	Platform team becomes critical path; may not meet all needs
Guild/Chapter Model	Representatives from each team form working groups for each concern	API design, testing practices, architectural patterns	Coordination overhead; voluntary compliance varies
Inner Source	One team open-sources solution; others contribute and adopt	Logging libraries, common utilities, SDK development	Adoption varies; maintenance burden on originating team
Paved Roads	Platform provides easy default paths; alternatives allowed with justification	Everything: 'golden path' with escape hatches	Escape hatch abuse; paved road may not evolve fast enough

GuildStructure.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
// Guild-Based Governance for Cross-Cutting Concerns
 
interface Guild {
  name: string;
  domain: string;
  description: string;
  
  // Structure
  lead: Person;
  members: GuildMember[];  // One representative per service team
  meetingCadence: string;
  
  // Responsibilities
  owns: string[];          // What the guild is responsible for
  produces: string[];      // Artifacts/standards the guild maintains
  
  // Governance
  decisionProcess: string;
  enforcement: 'mandatory' | 'recommended' | 'advisory';
}
 
interface GuildMember {
  person: Person;
  team: Team;
  role: 'lead' | 'core' | 'participant';
  timeCommitment: string;  // % of time allocated
}
 
const apiGuild: Guild = {
  name: 'API Guild',
  domain: 'API Design and Governance',
  description: 'Ensures consistent, well-designed APIs across all services',
  
  lead: { name: 'Sarah API-Lead', email: 'sarah@company.com' },
  members: [
    { person: { name: 'Tom Orders', email: 'tom@company.com' }, 
      team: { name: 'Order Team', members: 7 }, role: 'core', timeCommitment: '10%' },
    { person: { name: 'Uma Payments', email: 'uma@company.com' }, 
      team: { name: 'Payment Team', members: 6 }, role: 'core', timeCommitment: '10%' },
    { person: { name: 'Vic Catalog', email: 'vic@company.com' }, 
      team: { name: 'Catalog Team', members: 5 }, role: 'participant', timeCommitment: '5%' },
    // ... one member from each stream-aligned team
  ],
  meetingCadence: 'Bi-weekly 1-hour sync; async decision-making in between',
  
  owns: [
    'API design standards and guidelines',
    'API review process for new endpoints',
    'API deprecation policy and communication',
    'OpenAPI/AsyncAPI specification standards',
    'API versioning strategy',
  ],
  
  produces: [
    'API Style Guide (living document)',
    'API Review Checklist',
    'Breaking Change Notification Template',
    'Recommended API Libraries/SDKs',
    'API Scorecard for service health',
  ],
  
  decisionProcess: 'RFC-based: propose, discuss, revise, consent-based approval',
  enforcement: 'recommended',  // Not mandatory, but tracked in service scorecards
};
 
const securityGuild: Guild = {
  name: 'Security Guild',
  domain: 'Application and Infrastructure Security',
  description: 'Ensures security best practices and compliance across all services',
  
  lead: { name: 'Security Lead', email: 'security-lead@company.com' },
  // ... members from each team
  meetingCadence: 'Weekly sync; immediate escalation for security incidents',
  
  owns: [
    'Security standards and requirements',
    'Vulnerability disclosure process',
    'Secure coding guidelines',
    'Security review for sensitive changes',
    'Penetration testing coordination',
  ],
  
  produces: [
    'Security Requirements Checklist',
    'Threat Modeling Template',
    'Incident Response Runbook',
    'Dependencies Vulnerability Report (automated)',
    'Security Training Curriculum',
  ],
  
  decisionProcess: 'Security team has authority for security decisions; RFC for process changes',
  enforcement: 'mandatory',  // Security standards are not optional
};

The Paved Road Philosophy

Netflix's 'paved road' approach provides the best of both worlds. The platform team creates an easy default path that handles common cases well. Teams can deviate if they have good reasons, but the default path is so convenient that most choose to stay on it. This maintains consistency without mandating compliance.

Skills Transition and Development

Microservices require skills that monolith developers may not possess. Distributed systems thinking, API design, asynchronous communication, and operational ownership represent significant learning curves. A migration plan must include deliberate skill development.

The Skills Gap Analysis:

Monolith vs Microservices Skill Requirements
Skill Area	Monolith Mindset	Microservices Mindset	Development Path
Error Handling	Throw exception; let framework handle	Handle degraded modes gracefully; circuit breakers; retries with backoff	Chaos engineering; failure mode workshops; resilience patterns training
Data Management	ACID transactions; JOIN across tables	Eventual consistency; saga patterns; API-based data access	Event-driven architecture training; hands-on saga implementation
Testing	Integration tests against shared database	Contract testing; consumer-driven contracts; isolated service tests	Pact/contract testing workshops; TDD for APIs
Deployment	Coordinate release across all teams	Independent deployment; feature flags; canary releases	CI/CD hands-on; feature flag implementation; gradual rollout practice
Debugging	Stack traces; single system logs; debugger	Distributed tracing; log correlation; observability tools	Observability training; incident response drills; Jaeger/Zipkin workshops
API Design	Internal method calls; change freely	Contract-first design; versioning; backward compatibility	API design workshops; OpenAPI training; API review participation
Operational Ownership	Hand off to ops for production issues	Own build, deploy, run; on-call for your services	SRE practices training; runbook creation; incident management certification

Structured Skill Development Program:

Recommended Training Approach

•Foundational Training (Month 1-2): Distributed systems fundamentals for all engineers. Cover CAP theorem, eventual consistency, network partitions, Byzantine failures. Focus on mindset shift from synchronous to asynchronous.
•Hands-On Workshops (Month 2-4): Practical workshops on specific technologies. API design with OpenAPI, event-driven architecture with Kafka, containerization with Docker/Kubernetes, observability with Prometheus/Jaeger.
•Pilot Projects (Month 3-6): Each team extracts a simple, non-critical service. Low stakes environment to practice new skills. Enabling team provides close support and coaching.
•Production Experience (Month 6+): Teams take ownership of extracted services including on-call. Real incidents provide accelerated learning. Regular retrospectives capture lessons learned.
•Cross-Team Learning (Ongoing): Brown bag sessions where teams share experiences. Guild meetings discuss patterns and anti-patterns discovered. Internal blog/wiki captures institutional knowledge.

The Dip in Productivity

Expect a temporary productivity dip as teams learn new skills. Experienced monolith developers who were highly productive will initially slow down in the microservices context. Build this into timeline expectations. Communicate to leadership that short-term velocity reduction enables long-term velocity gains.

Team Formation During Migration

During migration, organizations often operate in a hybrid state—some teams work on the monolith while others build and operate extracted services. Different team formation patterns handle this transition differently.

Pattern 1: Dedicated Migration Team

Advantages

•Deep expertise in migration techniques develops
•Consistent extraction approach across services
•Feature teams continue delivering value without disruption
•Clear accountability for migration progress

Disadvantages

•Extracted services lack domain expertise
•Knowledge transfer to eventual owners is challenging
•'Throw it over the wall' anti-pattern risk
•Feature teams don't develop microservices skills

Pattern 2: Feature Teams Do Extraction

Advantages

•Domain experts extract their own domains
•Natural ownership established from day one
•Teams build microservices skills by doing
•No knowledge transfer needed

Disadvantages

•Feature velocity slows during extraction
•Inconsistent approaches across teams
•Teams may lack extraction expertise
•Migration progress depends on team priorities

Pattern 3: Hybrid with Enabling Team (Recommended)

HybridMigrationPattern.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
// Hybrid Migration Pattern with Enabling Team
 
interface MigrationStructure {
  enablingTeam: Team;
  streamAlignedTeams: StreamTeamMigrationState[];
  platformTeam: Team;
}
 
interface StreamTeamMigrationState {
  team: Team;
  currentState: 'pre-migration' | 'learning' | 'extracting' | 'operating';
  assignedEnablers: Person[];  // Enabling team members embedded
  extractionTarget: Service;
  timeline: {
    learningComplete: Date;
    extractionStart: Date;
    extractionComplete: Date;
    fullOwnership: Date;
  };
}
 
const hybridMigration: MigrationStructure = {
  enablingTeam: {
    name: 'Migration Enablement',
    type: 'enabling',
    members: 6,  // Senior distributed systems engineers
    services: [],  // Don't own services; enable others
    purpose: 'Build organizational capability for microservices',
    operation: [
      'Embed 1-2 members with each stream team during extraction',
      'Provide hands-on coaching, not just training',
      'Establish patterns that teams can replicate',
      'Document lessons learned for organizational knowledge',
      'Rotate to next team once current team is self-sufficient',
    ],
  },
  
  streamAlignedTeams: [
    {
      team: { name: 'Order Team', members: 7 },
      currentState: 'extracting',
      assignedEnablers: [
        { name: 'Enabler Alex', email: 'alex@company.com' },
      ],
      extractionTarget: { name: 'order-service', complexity: 'high' },
      timeline: {
        learningComplete: new Date('2024-02-15'),
        extractionStart: new Date('2024-02-15'),
        extractionComplete: new Date('2024-05-30'),
        fullOwnership: new Date('2024-06-30'),
      },
    },
    {
      team: { name: 'Catalog Team', members: 5 },
      currentState: 'learning',
      assignedEnablers: [
        { name: 'Enabler Blake', email: 'blake@company.com' },
      ],
      extractionTarget: { name: 'catalog-service', complexity: 'medium' },
      timeline: {
        learningComplete: new Date('2024-03-31'),
        extractionStart: new Date('2024-04-01'),
        extractionComplete: new Date('2024-06-30'),
        fullOwnership: new Date('2024-07-31'),
      },
    },
    // ... more teams in pipeline
  ],
  
  platformTeam: {
    name: 'Platform Team',
    type: 'platform',
    members: 8,
    services: ['kubernetes-platform', 'ci-cd', 'observability', 'service-mesh'],
    purpose: 'Provide self-service infrastructure for service teams',
    operation: [
      'Build golden path for service deployment',
      'Provide observability stack (Prometheus, Grafana, Jaeger)',
      'Operate Kubernetes clusters',
      'Provide templates and scaffolding for new services',
      'Support teams during production issues (not own services)',
    ],
  },
};

Enabler Rotation Strategy

The enabling team should rotate through stream-aligned teams, not permanently embed. A typical pattern: 6-8 weeks of close collaboration during initial extraction, then 2-4 weeks of light-touch support, then handoff. This ensures knowledge spreads across the organization and prevents the enabling team from becoming a bottleneck.

Designing Communication Structures

In a microservices architecture, team-to-team communication largely happens through service APIs rather than direct human collaboration. But some human communication is still essential. The goal is to design communication structures that support autonomy while enabling necessary coordination.

Principles for Microservices Communication Design:

Communication Design Principles

•Minimize Synchronous Dependencies: If teams must coordinate deployments or attend the same meetings to ship, the architecture has implicit coupling. Reduce.
•Formalize Cross-Team Contracts: APIs, events, and SLOs become the communication mechanism. Human negotiation happens at contract definition, not every change.
•Create Broadcasts, Not Meetings: Use async channels (Slack, email, internal blogs) for announcements. Reserve synchronous meetings for genuine discussion needs.
•Enable Discovery, Not Permission: Teams should be able to discover and use other teams' services without approval. Self-service documentation and service catalogs.
•Incident Bridging: While teams operate independently, incidents may require cross-team coordination. Define incident communication protocols.

Communication Mechanisms by Purpose
Purpose	Mechanism	Participants	Frequency
Strategic Alignment	Architecture review; quarterly planning	Tech leads, architects, product leaders	Quarterly
Cross-Team Standards	Guild meetings; RFC reviews	Guild members (1 per team)	Bi-weekly
API Changes	Async RFC; change announcement channel	Service owners, consumers	As needed
Incident Coordination	War room (virtual); incident channel	Affected service owners, incident commander	During incidents
Knowledge Sharing	Brown bag talks; internal blog posts	All engineering	Weekly optional sessions
Team-to-Team Issues	Direct Slack/Teams conversation	Individuals involved	As needed

CommunicationChannelStructure.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# Microservices Communication Channel Structure
 
## Team-Specific Channels
- #team-orders         (Order Team internal)
- #team-payments       (Payment Team internal)
- #team-catalog        (Catalog Team internal)
- #team-platform       (Platform Team internal)
 
## Service-Specific Channels (Public)
- #svc-orders          (Service announcements, questions)
- #svc-payments        (Service announcements, questions)
- #svc-catalog         (Service announcements, questions)
- #svc-platform        (Platform updates, support requests)
 
## Guild Channels
- #guild-api           (API design discussions)
- #guild-security      (Security standards, alerts)
- #guild-observability (Monitoring, alerting practices)
 
## Cross-Cutting Channels
- #engineering-all     (All-engineering announcements)
- #breaking-changes    (API breaking change notifications)
- #incidents           (Active incident coordination)
- #incident-review     (Post-incident analysis)
- #migrations          (Migration progress, updates)
 
## Async Decision-Making
- #rfcs                (RFC submissions and discussions)
- #architecture-review (Architecture decision records)
 
## Support & Help
- #help-platform       (Platform team support)
- #help-oncall         (General on-call questions)

Async by Default

High-performing microservices organizations default to asynchronous communication. Written RFCs, recorded videos, documented decisions. Synchronous meetings are exceptions for high-bandwidth problem-solving, not the default mode. This enables globally distributed teams and respects maker schedules.

Summary: Organizational Transformation

Team structure isn't a side effect of microservices migration—it's a first-class concern that determines success or failure. Let's consolidate the key principles:

Key Takeaways

•Conway's Law is inescapable — Your architecture will mirror your organization. Use this strategically by designing the org structure you want your architecture to reflect.
•Team Topologies provide a framework — Stream-aligned teams deliver value; platform teams reduce cognitive load; enabling teams build capability; complicated-subsystem teams handle specialized domains.
•Ownership must be explicit — 'You build it, you run it' creates accountability and improves quality. Shared ownership creates orphan services.
•Cross-cutting concerns need governance — Use guilds, platforms, and paved roads to maintain consistency without creating bottlenecks.
•Skills must be developed deliberately — Budget time and resources for training. Expect a productivity dip during the transition.
•The hybrid enabling model works best — Feature teams do extraction with embedded enablers from a specialist team. Combines domain expertise with migration skills.
•Communication structures matter — Design for autonomy with asynchronous defaults. Synchronous coordination should be the exception.

Page Complete

You now understand the organizational dimensions of migration planning. The next page covers tooling and infrastructure—the technical capabilities required to support microservices development, deployment, and operation at scale.

2 / 5

Loading learning content...

System Design (HLD)Migration Planning

Migration Planning

LevelAdvanced

Duration75 mins

TopicMigration Planning

2 / 5

Team Structure Considerations

Architecture Follows Organization

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." — Melvin Conway, 1967

What You'll Learn

Conway's Law: The Invisible Force

Understanding the Imprinting Mechanism:

Monolith Organization Patterns

•Teams organized by technical layer (frontend, backend, DBA)
•Shared ownership of central codebase
•Cross-team coordination via architecture committees
•Deployment requires multi-team synchronization
•Skills specialized by technology rather than domain
•Long release cycles accommodate coordination overhead

Microservices Organization Patterns

•Teams organized by business domain/capability
•Clear ownership of specific services
•Integration via well-defined APIs and events
•Teams deploy independently on their schedule
•Full-stack skills within each domain team
•Continuous delivery enabled by team autonomy

The Inverse Conway Maneuver:

Define target architecture: Design the microservices boundaries you want
Restructure teams to match: Create teams aligned to those boundaries
Let Conway's Law work for you: The organization naturally produces the target architecture

This approach is far more effective than trying to force an organizational structure to produce an architecture it's not optimized for.

The Org Chart Is Not the Architecture

Team Topologies for Microservices

The Four Fundamental Team Types:

Team Topologies: Core Team Types
Team Type	Purpose	Characteristics	Microservices Role
Stream-Aligned Teams	Deliver value in a specific business domain	Cross-functional, owns full feature delivery, autonomous deployment capability	Own and operate one or more closely related services within a bounded context
Platform Teams	Reduce cognitive load on stream-aligned teams	Provides self-service internal platforms, treats other teams as customers	Provides infrastructure, CI/CD, observability, service mesh, and other common capabilities
Enabling Teams	Help stream-aligned teams acquire new capabilities	Specialists who temporarily embed with teams, focus on knowledge transfer	During migration: help teams learn distributed systems patterns, testing strategies, etc.
Complicated Subsystem Teams	Handle complex technical domains requiring specialists	Deep expertise in specific area (ML, cryptography, etc.)	Own services requiring specialized skills that would overload stream-aligned teams

Team Interaction Modes:

How teams interact is as important as how they're structured:

Three Interaction Modes

•Collaboration Mode: Two teams work closely together on a shared goal. High communication, blurred boundaries. Use temporarily for exploration or complex integration. Expensive—don't maintain indefinitely.
•X-as-a-Service Mode: One team provides a capability that others consume via well-defined API. Clear boundaries, minimal direct communication. The target mode for most platform-to-stream relationships.
•Facilitating Mode: One team helps another acquire capabilities. Enabling team temporarily joins stream-aligned team, provides coaching/training, then exits. Used during migration transitions.

TeamTopologyExample.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
// Example: E-Commerce Platform Team Structure During Migration
 
interface Team {
  name: string;
  type: 'stream-aligned' | 'platform' | 'enabling' | 'complicated-subsystem';
  members: number;
  services: string[];
  interactionsWith: TeamInteraction[];
}
 
interface TeamInteraction {
  team: string;
  mode: 'collaboration' | 'x-as-a-service' | 'facilitating';
  purpose: string;
  duration: 'temporary' | 'ongoing';
}
 
const ecommerceTeamStructure: Team[] = [
  // STREAM-ALIGNED TEAMS (Deliver Business Value)
  {
    name: 'Order Management Team',
    type: 'stream-aligned',
    members: 7,
    services: ['order-service', 'order-history-service'],
    interactionsWith: [
      { team: 'Platform Team', mode: 'x-as-a-service', 
        purpose: 'CI/CD, monitoring, infrastructure', duration: 'ongoing' },
      { team: 'Payment Team', mode: 'x-as-a-service', 
        purpose: 'Process payments via Payment API', duration: 'ongoing' },
      { team: 'Migration Enablement', mode: 'facilitating', 
        purpose: 'Learn saga patterns for distributed transactions', duration: 'temporary' },
    ],
  },
  {
    name: 'Payment Team',
    type: 'stream-aligned',
    members: 6,
    services: ['payment-service', 'refund-service', 'wallet-service'],
    interactionsWith: [
      { team: 'Platform Team', mode: 'x-as-a-service', 
        purpose: 'Secrets management, PCI-compliant infrastructure', duration: 'ongoing' },
      { team: 'Fraud Detection Team', mode: 'x-as-a-service', 
        purpose: 'Fraud scoring via API', duration: 'ongoing' },
    ],
  },
  {
    name: 'Product Catalog Team',
    type: 'stream-aligned',
    members: 5,
    services: ['catalog-service', 'search-service', 'recommendation-service'],
    interactionsWith: [
      { team: 'Platform Team', mode: 'x-as-a-service', 
        purpose: 'Elasticsearch cluster, CDN', duration: 'ongoing' },
      { team: 'Inventory Team', mode: 'collaboration', 
        purpose: 'Define product-inventory sync mechanism', duration: 'temporary' },
    ],
  },
  {
    name: 'Inventory Team',
    type: 'stream-aligned',
    members: 4,
    services: ['inventory-service'],
    interactionsWith: [
      { team: 'Platform Team', mode: 'x-as-a-service', 
        purpose: 'Event streaming infrastructure', duration: 'ongoing' },
    ],
  },
  
  // PLATFORM TEAM
  {
    name: 'Platform Team',
    type: 'platform',
    members: 8,
    services: ['ci-cd-platform', 'monitoring-platform', 'service-mesh', 'secrets-manager'],
    interactionsWith: [
      // X-as-a-Service to all stream-aligned teams
      { team: 'All Stream-Aligned Teams', mode: 'x-as-a-service', 
        purpose: 'Self-service infrastructure and tooling', duration: 'ongoing' },
    ],
  },
  
  // ENABLING TEAM
  {
    name: 'Migration Enablement Team',
    type: 'enabling',
    members: 4,
    services: [], // Doesn't own services, enables others
    interactionsWith: [
      { team: 'Order Management Team', mode: 'facilitating', 
        purpose: 'Train on distributed transactions', duration: 'temporary' },
      { team: 'Product Catalog Team', mode: 'facilitating', 
        purpose: 'Help with search service extraction', duration: 'temporary' },
    ],
  },
  
  // COMPLICATED SUBSYSTEM TEAM
  {
    name: 'Fraud Detection Team',
    type: 'complicated-subsystem',
    members: 4,
    services: ['fraud-detection-service', 'ml-scoring-service'],
    interactionsWith: [
      { team: 'Payment Team', mode: 'x-as-a-service', 
        purpose: 'Provide fraud scoring API', duration: 'ongoing' },
      { team: 'Platform Team', mode: 'x-as-a-service', 
        purpose: 'ML infrastructure, model serving', duration: 'ongoing' },
    ],
  },
];

Team Size: The Two-Pizza Rule

Ownership Models

The "You Build It, You Run It" Philosophy:

Amazon pioneered the insight that teams who build services should also operate them. This philosophy, articulated by Werner Vogels, creates powerful incentives:

Benefits of Full Ownership

•Quality Incentives: When you're on-call for your own code, you write more defensive code, better error handling, clearer logging.
•Operational Learning: Developers gain production insights that inform design decisions. They see how their code behaves under real load.
•Faster Debugging: The person who wrote the code debugs incidents faster than someone seeing it for the first time.
•Reduced Handoffs: No blame-passing between 'dev' and 'ops'. Single team owns the outcome.
•Continuous Improvement: Teams that operate services continuously improve operability based on pain points.

Shared Ownership Anti-Patterns:

Ownership Anti-Patterns to Avoid
Anti-Pattern	Symptoms	Consequences	Resolution
Orphan Service	No clear team ownership; service maintained 'by everyone'	No accountability; changes avoided; incidents handled reluctantly	Assign explicit ownership; treat as line item in team planning
Shared Service Committee	Multiple teams share ownership via rotating responsibilities	Slow decision-making; design by committee; conflicting priorities	Designate primary owner; others become consumers with influence rights
Operational Separation	Dev team builds, separate ops team runs	Blame shifting; operational requirements ignored; slow incident response	Move toward 'you build it, you run it'; SRE embedding if scale requires
Hero Dependency	Single person understands service; others defer to them	Single point of failure; no vacation; burnout risk	Knowledge sharing program; pair programming; documented runbooks
Cross-Team Sprawl	Service logic spread across multiple team codebases	No one can make complete changes; all changes require coordination	Consolidate logic into owning team's services; define clear APIs

OwnershipModel.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
// Explicit Ownership Model Documentation
 
interface ServiceOwnership {
  serviceId: string;
  serviceName: string;
  
  // Primary ownership
  owningTeam: Team;
  techLead: Person;          // Technical decisions
  productOwner: Person;       // Prioritization decisions
  
  // On-call responsibilities
  primaryOnCall: Person[];    // Current on-call rotation
  onCallSchedule: string;     // Link to schedule
  escalationPath: Person[];   // Who to escalate to
  
  // SLO commitments
  availabilitySLO: string;    // e.g., "99.9%"
  latencyP99SLO: string;      // e.g., "200ms"
  incidentResponseSLO: string; // e.g., "15 min to acknowledge"
  
  // Consumer relationships
  consumers: Consumer[];      // Who depends on this service
  
  // Governance
  changeApprovalRequired: Person[];  // Who approves breaking changes
  deprecationPolicy: string;  // How much notice for API changes
}
 
interface Consumer {
  team: Team;
  usagePattern: string;
  criticality: 'blocking' | 'important' | 'nice-to-have';
  slaExpectation: string;
  contactPerson: Person;
}
 
// Example
const orderServiceOwnership: ServiceOwnership = {
  serviceId: 'order-service',
  serviceName: 'Order Management Service',
  
  owningTeam: { name: 'Order Team', members: 7 },
  techLead: { name: 'Alice Chen', email: 'alice@company.com' },
  productOwner: { name: 'Bob Smith', email: 'bob@company.com' },
  
  primaryOnCall: [
    { name: 'Carol Davis', email: 'carol@company.com' },
    { name: 'Dan Wilson', email: 'dan@company.com' },
  ],
  onCallSchedule: 'https://pagerduty.com/schedules/order-team',
  escalationPath: [
    { name: 'Alice Chen (Tech Lead)', email: 'alice@company.com' },
    { name: 'VP Engineering', email: 'vpe@company.com' },
  ],
  
  availabilitySLO: '99.95%',
  latencyP99SLO: '400ms',
  incidentResponseSLO: '15 minutes to acknowledge, 1 hour to mitigate',
  
  consumers: [
    {
      team: { name: 'Mobile Team', members: 5 },
      usagePattern: 'Order creation, status queries',
      criticality: 'blocking',
      slaExpectation: 'Same as service SLO',
      contactPerson: { name: 'Eve Mobile', email: 'eve@company.com' },
    },
    {
      team: { name: 'Analytics Team', members: 3 },
      usagePattern: 'Batch order data export',
      criticality: 'nice-to-have',
      slaExpectation: 'Best effort',
      contactPerson: { name: 'Frank Analytics', email: 'frank@company.com' },
    },
  ],
  
  changeApprovalRequired: [
    { name: 'Alice Chen', email: 'alice@company.com' },
    { name: 'API Guild Lead', email: 'api-lead@company.com' },
  ],
  deprecationPolicy: '90 days notice for breaking changes; 30 days for deprecation',
};

Document Ownership Publicly

Handling Cross-Cutting Concerns

Common Cross-Cutting Concerns:

Cross-Cutting Categories

•Security: Authentication, authorization, encryption, secrets management, vulnerability scanning
•Observability: Logging formats, metric collection, distributed tracing, alerting standards
•API Design: Naming conventions, versioning strategy, error formats, documentation requirements
•Data Governance: Privacy regulations, data retention, cross-border data handling
•Testing Standards: Test coverage requirements, integration test patterns, contract testing
•Deployment: CI/CD pipelines, rollout strategies, feature flag usage
•Reliability: SLO definitions, chaos engineering practices, incident management

Governance Models:

Cross-Cutting Concern Governance Models
Model	How It Works	Best For	Risks
Centralized Standards	Central team defines standards; all teams must comply	Security, compliance requirements	Bottleneck risk; standards lag team needs; resentment
Platform Abstraction	Platform team provides capability; teams consume via API/SDK	Observability, deployment, infrastructure	Platform team becomes critical path; may not meet all needs
Guild/Chapter Model	Representatives from each team form working groups for each concern	API design, testing practices, architectural patterns	Coordination overhead; voluntary compliance varies
Inner Source	One team open-sources solution; others contribute and adopt	Logging libraries, common utilities, SDK development	Adoption varies; maintenance burden on originating team
Paved Roads	Platform provides easy default paths; alternatives allowed with justification	Everything: 'golden path' with escape hatches	Escape hatch abuse; paved road may not evolve fast enough

GuildStructure.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
// Guild-Based Governance for Cross-Cutting Concerns
 
interface Guild {
  name: string;
  domain: string;
  description: string;
  
  // Structure
  lead: Person;
  members: GuildMember[];  // One representative per service team
  meetingCadence: string;
  
  // Responsibilities
  owns: string[];          // What the guild is responsible for
  produces: string[];      // Artifacts/standards the guild maintains
  
  // Governance
  decisionProcess: string;
  enforcement: 'mandatory' | 'recommended' | 'advisory';
}
 
interface GuildMember {
  person: Person;
  team: Team;
  role: 'lead' | 'core' | 'participant';
  timeCommitment: string;  // % of time allocated
}
 
const apiGuild: Guild = {
  name: 'API Guild',
  domain: 'API Design and Governance',
  description: 'Ensures consistent, well-designed APIs across all services',
  
  lead: { name: 'Sarah API-Lead', email: 'sarah@company.com' },
  members: [
    { person: { name: 'Tom Orders', email: 'tom@company.com' }, 
      team: { name: 'Order Team', members: 7 }, role: 'core', timeCommitment: '10%' },
    { person: { name: 'Uma Payments', email: 'uma@company.com' }, 
      team: { name: 'Payment Team', members: 6 }, role: 'core', timeCommitment: '10%' },
    { person: { name: 'Vic Catalog', email: 'vic@company.com' }, 
      team: { name: 'Catalog Team', members: 5 }, role: 'participant', timeCommitment: '5%' },
    // ... one member from each stream-aligned team
  ],
  meetingCadence: 'Bi-weekly 1-hour sync; async decision-making in between',
  
  owns: [
    'API design standards and guidelines',
    'API review process for new endpoints',
    'API deprecation policy and communication',
    'OpenAPI/AsyncAPI specification standards',
    'API versioning strategy',
  ],
  
  produces: [
    'API Style Guide (living document)',
    'API Review Checklist',
    'Breaking Change Notification Template',
    'Recommended API Libraries/SDKs',
    'API Scorecard for service health',
  ],
  
  decisionProcess: 'RFC-based: propose, discuss, revise, consent-based approval',
  enforcement: 'recommended',  // Not mandatory, but tracked in service scorecards
};
 
const securityGuild: Guild = {
  name: 'Security Guild',
  domain: 'Application and Infrastructure Security',
  description: 'Ensures security best practices and compliance across all services',
  
  lead: { name: 'Security Lead', email: 'security-lead@company.com' },
  // ... members from each team
  meetingCadence: 'Weekly sync; immediate escalation for security incidents',
  
  owns: [
    'Security standards and requirements',
    'Vulnerability disclosure process',
    'Secure coding guidelines',
    'Security review for sensitive changes',
    'Penetration testing coordination',
  ],
  
  produces: [
    'Security Requirements Checklist',
    'Threat Modeling Template',
    'Incident Response Runbook',
    'Dependencies Vulnerability Report (automated)',
    'Security Training Curriculum',
  ],
  
  decisionProcess: 'Security team has authority for security decisions; RFC for process changes',
  enforcement: 'mandatory',  // Security standards are not optional
};

The Paved Road Philosophy

Skills Transition and Development

The Skills Gap Analysis:

Monolith vs Microservices Skill Requirements
Skill Area	Monolith Mindset	Microservices Mindset	Development Path
Error Handling	Throw exception; let framework handle	Handle degraded modes gracefully; circuit breakers; retries with backoff	Chaos engineering; failure mode workshops; resilience patterns training
Data Management	ACID transactions; JOIN across tables	Eventual consistency; saga patterns; API-based data access	Event-driven architecture training; hands-on saga implementation
Testing	Integration tests against shared database	Contract testing; consumer-driven contracts; isolated service tests	Pact/contract testing workshops; TDD for APIs
Deployment	Coordinate release across all teams	Independent deployment; feature flags; canary releases	CI/CD hands-on; feature flag implementation; gradual rollout practice
Debugging	Stack traces; single system logs; debugger	Distributed tracing; log correlation; observability tools	Observability training; incident response drills; Jaeger/Zipkin workshops
API Design	Internal method calls; change freely	Contract-first design; versioning; backward compatibility	API design workshops; OpenAPI training; API review participation
Operational Ownership	Hand off to ops for production issues	Own build, deploy, run; on-call for your services	SRE practices training; runbook creation; incident management certification

Structured Skill Development Program:

Recommended Training Approach

•Foundational Training (Month 1-2): Distributed systems fundamentals for all engineers. Cover CAP theorem, eventual consistency, network partitions, Byzantine failures. Focus on mindset shift from synchronous to asynchronous.
•Hands-On Workshops (Month 2-4): Practical workshops on specific technologies. API design with OpenAPI, event-driven architecture with Kafka, containerization with Docker/Kubernetes, observability with Prometheus/Jaeger.
•Pilot Projects (Month 3-6): Each team extracts a simple, non-critical service. Low stakes environment to practice new skills. Enabling team provides close support and coaching.
•Production Experience (Month 6+): Teams take ownership of extracted services including on-call. Real incidents provide accelerated learning. Regular retrospectives capture lessons learned.
•Cross-Team Learning (Ongoing): Brown bag sessions where teams share experiences. Guild meetings discuss patterns and anti-patterns discovered. Internal blog/wiki captures institutional knowledge.

The Dip in Productivity

Team Formation During Migration

Pattern 1: Dedicated Migration Team

Advantages

•Deep expertise in migration techniques develops
•Consistent extraction approach across services
•Feature teams continue delivering value without disruption
•Clear accountability for migration progress

Disadvantages

•Extracted services lack domain expertise
•Knowledge transfer to eventual owners is challenging
•'Throw it over the wall' anti-pattern risk
•Feature teams don't develop microservices skills

Pattern 2: Feature Teams Do Extraction

Advantages

•Domain experts extract their own domains
•Natural ownership established from day one
•Teams build microservices skills by doing
•No knowledge transfer needed

Disadvantages

•Feature velocity slows during extraction
•Inconsistent approaches across teams
•Teams may lack extraction expertise
•Migration progress depends on team priorities

Pattern 3: Hybrid with Enabling Team (Recommended)

HybridMigrationPattern.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
// Hybrid Migration Pattern with Enabling Team
 
interface MigrationStructure {
  enablingTeam: Team;
  streamAlignedTeams: StreamTeamMigrationState[];
  platformTeam: Team;
}
 
interface StreamTeamMigrationState {
  team: Team;
  currentState: 'pre-migration' | 'learning' | 'extracting' | 'operating';
  assignedEnablers: Person[];  // Enabling team members embedded
  extractionTarget: Service;
  timeline: {
    learningComplete: Date;
    extractionStart: Date;
    extractionComplete: Date;
    fullOwnership: Date;
  };
}
 
const hybridMigration: MigrationStructure = {
  enablingTeam: {
    name: 'Migration Enablement',
    type: 'enabling',
    members: 6,  // Senior distributed systems engineers
    services: [],  // Don't own services; enable others
    purpose: 'Build organizational capability for microservices',
    operation: [
      'Embed 1-2 members with each stream team during extraction',
      'Provide hands-on coaching, not just training',
      'Establish patterns that teams can replicate',
      'Document lessons learned for organizational knowledge',
      'Rotate to next team once current team is self-sufficient',
    ],
  },
  
  streamAlignedTeams: [
    {
      team: { name: 'Order Team', members: 7 },
      currentState: 'extracting',
      assignedEnablers: [
        { name: 'Enabler Alex', email: 'alex@company.com' },
      ],
      extractionTarget: { name: 'order-service', complexity: 'high' },
      timeline: {
        learningComplete: new Date('2024-02-15'),
        extractionStart: new Date('2024-02-15'),
        extractionComplete: new Date('2024-05-30'),
        fullOwnership: new Date('2024-06-30'),
      },
    },
    {
      team: { name: 'Catalog Team', members: 5 },
      currentState: 'learning',
      assignedEnablers: [
        { name: 'Enabler Blake', email: 'blake@company.com' },
      ],
      extractionTarget: { name: 'catalog-service', complexity: 'medium' },
      timeline: {
        learningComplete: new Date('2024-03-31'),
        extractionStart: new Date('2024-04-01'),
        extractionComplete: new Date('2024-06-30'),
        fullOwnership: new Date('2024-07-31'),
      },
    },
    // ... more teams in pipeline
  ],
  
  platformTeam: {
    name: 'Platform Team',
    type: 'platform',
    members: 8,
    services: ['kubernetes-platform', 'ci-cd', 'observability', 'service-mesh'],
    purpose: 'Provide self-service infrastructure for service teams',
    operation: [
      'Build golden path for service deployment',
      'Provide observability stack (Prometheus, Grafana, Jaeger)',
      'Operate Kubernetes clusters',
      'Provide templates and scaffolding for new services',
      'Support teams during production issues (not own services)',
    ],
  },
};

Enabler Rotation Strategy

Designing Communication Structures

Principles for Microservices Communication Design:

Communication Design Principles

•Minimize Synchronous Dependencies: If teams must coordinate deployments or attend the same meetings to ship, the architecture has implicit coupling. Reduce.
•Formalize Cross-Team Contracts: APIs, events, and SLOs become the communication mechanism. Human negotiation happens at contract definition, not every change.
•Create Broadcasts, Not Meetings: Use async channels (Slack, email, internal blogs) for announcements. Reserve synchronous meetings for genuine discussion needs.
•Enable Discovery, Not Permission: Teams should be able to discover and use other teams' services without approval. Self-service documentation and service catalogs.
•Incident Bridging: While teams operate independently, incidents may require cross-team coordination. Define incident communication protocols.

Communication Mechanisms by Purpose
Purpose	Mechanism	Participants	Frequency
Strategic Alignment	Architecture review; quarterly planning	Tech leads, architects, product leaders	Quarterly
Cross-Team Standards	Guild meetings; RFC reviews	Guild members (1 per team)	Bi-weekly
API Changes	Async RFC; change announcement channel	Service owners, consumers	As needed
Incident Coordination	War room (virtual); incident channel	Affected service owners, incident commander	During incidents
Knowledge Sharing	Brown bag talks; internal blog posts	All engineering	Weekly optional sessions
Team-to-Team Issues	Direct Slack/Teams conversation	Individuals involved	As needed

CommunicationChannelStructure.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# Microservices Communication Channel Structure
 
## Team-Specific Channels
- #team-orders         (Order Team internal)
- #team-payments       (Payment Team internal)
- #team-catalog        (Catalog Team internal)
- #team-platform       (Platform Team internal)
 
## Service-Specific Channels (Public)
- #svc-orders          (Service announcements, questions)
- #svc-payments        (Service announcements, questions)
- #svc-catalog         (Service announcements, questions)
- #svc-platform        (Platform updates, support requests)
 
## Guild Channels
- #guild-api           (API design discussions)
- #guild-security      (Security standards, alerts)
- #guild-observability (Monitoring, alerting practices)
 
## Cross-Cutting Channels
- #engineering-all     (All-engineering announcements)
- #breaking-changes    (API breaking change notifications)
- #incidents           (Active incident coordination)
- #incident-review     (Post-incident analysis)
- #migrations          (Migration progress, updates)
 
## Async Decision-Making
- #rfcs                (RFC submissions and discussions)
- #architecture-review (Architecture decision records)
 
## Support & Help
- #help-platform       (Platform team support)
- #help-oncall         (General on-call questions)

Async by Default

Summary: Organizational Transformation

Team structure isn't a side effect of microservices migration—it's a first-class concern that determines success or failure. Let's consolidate the key principles:

Key Takeaways

•Conway's Law is inescapable — Your architecture will mirror your organization. Use this strategically by designing the org structure you want your architecture to reflect.
•Team Topologies provide a framework — Stream-aligned teams deliver value; platform teams reduce cognitive load; enabling teams build capability; complicated-subsystem teams handle specialized domains.
•Ownership must be explicit — 'You build it, you run it' creates accountability and improves quality. Shared ownership creates orphan services.
•Cross-cutting concerns need governance — Use guilds, platforms, and paved roads to maintain consistency without creating bottlenecks.
•Skills must be developed deliberately — Budget time and resources for training. Expect a productivity dip during the transition.
•The hybrid enabling model works best — Feature teams do extraction with embedded enablers from a specialist team. Combines domain expertise with migration skills.
•Communication structures matter — Design for autonomy with asynchronous defaults. Synchronous coordination should be the exception.

Page Complete

2 / 5