엔지니어 3명에게 통하는 관행은 30명에서 깨집니다. 비공식적 조율, tribal knowledge, 수동 프로세스는 확장되지 않습니다. senior TL은 성장 곡선보다 앞서 관행을 진화시켜야 합니다. 관료주의 없이 velocity를 유지할 딱 충분한 구조를 공식화하는 것입니다.
무엇이 확장되어야 하는가
text
✓ CI/CD — 빠르고, 신뢰할 수 있고, 자동화된; 수동 배포는 성장에서 살아남지 못한다
✓ TESTING — 자동화된 suite; 모든 것을 수동으로 검증할 수 없다
✓ CODE REVIEW — 명확한 규범, 합리적 turnaround, ownership 경계
✓ DOCUMENTATION — 작성된 지식이 "Bob에게 물어봐"를 대체한다
✓ ONBOARDING — 입사자마다 맞춤이 아니라 반복 가능하게
✓ 의사결정 — 명확한 ownership; 누가 무엇을 결정하는가
✓ ON-CALL / OWNERSHIP — 정의되고, 순환되며, 영웅적이지 않게
구체적인 예시
5명일 때는 모두가 전체 시스템을 알고 손으로 배포합니다. 25명일 때 그것은 혼돈입니다. 진짜 CI/CD 파이프라인, service ownership, 작성된 runbook, 리뷰 규범이 필요합니다, 아니면 팀은 서로 싸우며 멈춰 섭니다.
적시에 구조를 더하라
작은 팀에 무거운 프로세스를 강요하지 말고(그들을 옥죕니다), 큰 팀에 스타트업의 비공식성을 고집하지 마십시오(무너집니다). 각 구조 조각을 , 이상적으로는 직전에 더하십시오. 신호를 주시하십시오: 늘어나는 merge conflict, 지식 bottleneck, 불안정한 배포.