Estágio 05 · 05-03
Locked"Sistemas refletem a estrutura organizacional que os criou." Conway (1967). Esta lei é evidência crua: monolitos vêm de teams sem contratos; microsserviços que viram distributed monolith vêm de teams sem ownership claro; APIs ruins vêm de teams sem cliente interno.
Staff/Principal desenha o time, não só o código. Recommend split do time em squads aligned com bounded contexts (DDD, 04-06). Argumenta com VP/CTO sobre quando decompor, quando consolidate, quando criar platform team. Reduz dependency hell entre teams. Identifica quando "a arquitetura é ruim porque o org chart é ruim", frequentemente o caso.
Este módulo é organizational design pro engineer técnico. Não vira manager, mas precisa falar a língua de manager pra negociar reorganization. Conway's Law, Inverse Conway Maneuver, Team Topologies (stream-aligned, platform, complicated subsystem, enabling), bus factor org-wide, hiring strategy, levels (IC ladder), career frameworks.
Pra Staff, isto não é overhead: é a alavanca real que move sistema grande. "Vamos refatorar microservice X" não funciona se 3 teams compartilham X sem owner. Resolve org primeiro, código depois.
Mel Conway, 1967: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
Implicação: arquitetura espelha comunicação. 4 teams escrevendo lib comum produzem 4 dialetos. 1 team escrevendo backend monolítico produz monolito coerente. 5 teams produzindo microservices sem clear contracts produzem distributed monolith.
Princípio prático: mude o time pra mudar o código.
Quer microservices independentes? Forme teams independentes com ownership de domain. Quer modular monolith? Mantenha team unificado com module boundaries.
Não basta declarar "microservices". Sem squad ownership de cada serviço, microservices são theater.
Quatro tipos de team:
Modes de interaction:
Match topology to stage of product e nature de domain.
DDD bounded context = unidade de modelo coerente. Idealmente um team owns.
Dois bounded contexts no mesmo team: ok se team grande. Um bounded context em N teams: avoid (spaghetti governance).
Mapping:
Nomes claros. Contratos explícitos (gRPC, REST com OpenAPI, events com schema).
Conceito chave de Team Topologies: cada team tem carga cognitiva finita.
Stream-aligned team com 8 microservices, 3 stacks, 5 deploys diferentes, sem platform support → overload. Velocity cai.
Platform team reduces extraneous load: oferece deploy padrão, observability built-in, auth library, etc. Stream team foca no domain.
Cada serviço/repo/datastore tem um team owner. CODEOWNERS file (GitHub), wiki, qualquer registro.
Sem owner: rot. Múltiplos owners: ninguém é responsável (tragedy of commons). Owner team disbanded: priorize transfer.
Padrões comuns:
Time menor que 4: bus factor frágil. Time maior que 10: subgroups informais aparecem.
Times muito específicos podem ser 2-3 (complicated subsystem). Stream-aligned típico 6-8.
Cada cross-team dependency é fricção. Patterns pra reduzir:
Anti-pattern: ticket queue de "infra team" servindo todos. Bottleneck.
Staff often advise sobre roles. "We need backend engineer" é vague. Better:
Specificity attracts right candidates e ajusta expectativas.
Empresas maduras têm IC (Individual Contributor) ladder paralelo a manager:
Differences entre níveis: scope, ambiguity, autonomy, impact, influence.
Promo case: Staff documenta evidence de impact e scope. Brag doc + sponsor com weight no comitê.
Sair pra manager = liderança formal, hiring, perf reviews, less code. Ficar IC = depth técnico, design, mentoring, less people management.
Staff IC = mostly IC com strong influence. Principal IC = strategic technical leadership.
Decision pessoal. Algumas orgs forçam manager pós-Senior; melhores orgs (Stripe, Google, Meta) mantêm IC ladder competitiva.
Reorgs frequentes destroem trust. Reorgs raros + bem-comunicados ok.
Senior técnico sometimes propose reorg. Considerations:
Não propose reorg como first solution. Last solution.
M&A: 2 codebases + 2 culturas + 2 stacks. Patterns:
Tech leadership com role active em integration: arquitetar transition, save talent, reduce attrition.
Estruturas afetam comunicação afetam código (Conway de novo):
Engineering practices ajustam: code review obrigatório (substitui hallway), pull-request descriptions densas, ADR formal, recordings.
Time homogêneo é frágil:
Diversity (gender, race, age, neurodiversity) melhora outcomes mensuráveis. Mas DEI exige hiring deliberado, retention work, sponsorship.
Não vira política; é engineering reliability, reduz blind spots.
Levels não são padronizados entre empresas. L5 Google ≈ L6 Meta ≈ Senior+ Stripe. Sites como levels.fyi ajudam comparison.
Impact em transição de empresa: title pode aumentar ou cair. Comp + scope > title.
Staff Eng não é "Senior +". Tipos:
Cada um valida differently. Saiba qual é seu archetype + qual sua org valoriza.
Glue work = trabalho de coordenar, mentor, escrever doc, organizar meetings. Crítico mas invisível em perf review.
Senior IC must balance code (visible, promotable) com glue (impact, retention). Female / underrepresented ICs frequentemente acabam com mais glue, less promo. Sniff e push back.
Você precisa, sem consultar:
Produzir proposta de organização da Logística v3 + 1 estudo de caso real.
Parte 1: Logística (hipotética em scale)
Cenário: Logística cresceu pra 60 engenheiros. Você é Staff novo. Mapeie:
Output: ORG-PROPOSAL.md (~2000 palavras) + diagrama mermaid.
Parte 2: Estudo de caso real
Escolha uma org pública (Stripe, GitLab, Shopify, Spotify) que documenta org publicamente (via blog/talks). Analise:
Output: CASE-STUDY.md (~1500 palavras).
Parte 3: Pessoal
Escreva MY-PATH.md:
git log + ownership stats vs current arch.Destrava
05-03 é prereq dos seguintes módulos: