초급
AI 시대의 엔지니어링 팀 관리 방법
AI 시대의 엔지니어링 팀 관리 방법
Fiona Fung은 Anthropic 컨퍼런스에서 AI 시대의 엔지니어링 팀 관리 방법에 대해 28분간 강연했습니다.
그녀가 이 슬라이드 덱을 만들 당시, Anthropic은 아직 Routines 기능을 출시하지 않았습니다.
3주 후, Routines이 출시되었습니다. 이 기능은 Claude Code가 로컬에서 터미널을 열어둘 필요 없이 클라우드에서 예약된 작업을 자동으로 실행할 수 있게 해줍니다. 그녀가 실제로 2026년 Code with Claude 컨퍼런스 무대에 올랐을 때는 이미 여러 슬라이드가 구식이 되어 있었습니다.
Fiona Fung은 Anthropic에서 Claude Code와 Cowork 제품 라인의 엔지니어링 및 제품 책임자입니다. 그녀는 이전에 Microsoft에서 12년을 보냈고(Visual Studio에서 시작), Meta에서 Facebook Marketplace와 Instagram의 엔지니어링 팀을 이끌었으며, 2025년 9월에 Anthropic에 합류했습니다. 이 강연은 30분 미만이었고, 주제는 평범해 보였습니다: "AI 시대의 엔지니어링 팀 관리 방법." 하지만 그녀는 지난 1년 동안 Claude Code 팀이 실제로 겪은 함정, 그들이 깨뜨린 기존 규칙, 그리고 아직 해결하지 못한 실질적인 과제만을 공유했을 뿐, 추상적인 격언은 전혀 없었습니다.
핵심 요점#
- 소프트웨어 엔지니어링의 병목 현상은 과거에는 "코드 작성이 느리다"는 것이었지만, 이제는 검증, 리뷰, 교차 기능 협업, 보안으로 이동했습니다. 과거 프로세스는 "코드 작성이 비싸다"는 가정을 기반으로 설계되었습니다. "코드 작성이 이제 거의 무료"이므로 모든 프로세스를 재구축해야 합니다.
- 프로세스는 거의 자연사하지 않습니다. 조직은 계속해서 더 많은 SLA, 규정, 리뷰를 추가할 뿐입니다. AI로 엔지니어링 팀을 혁신하는 첫 번째 단계는 사람들이 구식 프로세스를 명시적으로 제거할 수 있도록 허용하는 것입니다.
- 기술 논쟁 방식이 바뀌었습니다. 사람들을 화이트보드 방으로 불러모아 아키텍처 다이어그램을 그리는 대신, 이제는 Claude가 동시에 세 개의 PR을 생성하고 실제 API 영향 범위와 함께 코드를 논의하도록 할 수 있습니다.
- Claude Code 팀에서는 모든 PR에 Claude가 관여합니다. "이 코드를 실제로 누가 작성했는가?"라는 질문은 점차 의미를 잃어가고 있습니다.
- 관리자는 반드시 개인 기여자(IC) 출신이어야 합니다. Fiona는 채용 시 이를 고집하며, 그녀의 채용 동료들은 처음에 이해하지 못했습니다: "어떤 관리자가 기꺼이 다시 코드를 작성하러 돌아가겠습니까?" 그녀의 답변은 단호했습니다: "관심이 없다면, 빨리 헤어지는 것이 낫습니다."
- 조직은 가능한 한 평평하게 유지하고, 모든 팀이 단일 팀 미션을 공유해야 합니다. 그 이유는 간단합니다: 미션이 변경될 때, 계층이 많을수록 정렬 마찰이 더 커집니다. 평평함은 유연함을 의미합니다.
- 코드가 단일 진실 공급원이지, 설계 문서가 아닙니다. 명세서를 유지해야 한다면, 코드베이스에 커밋하고 Claude가 코드와 문서 간의 일관성을 검증하도록 하세요.
- 효과성은 세 가지 지표로 측정하세요: 신규 채용 온보딩 시간, PR 수명 주기, Claude 지원 제출 비율. 하지만 그녀는 또한 경고합니다: "AI가 작성한 코드의 양"에 집착하지 마세요 — 이는 단순한 허영 지표일 뿐입니다. 제품 품질과 안정성에 집중하세요.
[1] 20년 만에 업계가 두 번 재편성되었습니다#
강연 시작 부분에서 Fiona는 시간을 2000년대 초반으로 되돌렸습니다. 그녀는 Microsoft에서 Visual Studio 2005를 작업하고 있었습니다 — 세계 최고의 개발 도구 중 하나였습니다. 당시 소프트웨어는 여전히 CD로 배포되었습니다(그리고 더 이전에는 플로피 디스크). 소프트웨어를 조립 라인으로 보내 프레스, 포장, 매장 배송을 해야 했기 때문에 모든 버전에는 변경할 수 없는 릴리스 일정이 있었습니다.
그런 다음 인터넷이 등장하여 배포가 CD에서 온라인 전송으로 전환되었고, 엔지니어링 리듬이 뒤집혔습니다. 이제는 AI의 차례지만, 이번에는 릴리스 주기만 바뀌는 것이 아니라 "코드 작성" 자체가 변화하고 있습니다.
"과거에 도움이 되었던 것이 더 이상 도움이 되지 않을 수 있습니다."
그녀는 강연 내내 이 문장을 반복해서 언급했습니다. 수년 동안 엔지니어링 리듬은 하나의 가정을 기반으로 구축되었습니다: 코드 작성은 비싸고, 테스트 작성은 비싸고, 리팩토링은 비싸다. 폭포수에서 애자일까지, 모든 방법론은 이 희소 자원을 할당하는 데 관한 것이었습니다.
작년에 그녀는 여전히 "바이브 코딩"(OpenAI 공동 창립자 Andrej Karpathy가 2025년 초에 만든 용어)에 대해 불평하고 있었습니다: "왜 모든 곳에 상수가 있나요? 나쁜 엔지니어링 관행입니다." 1년 후, 모델은 훨씬 더 강력해졌습니다. 이 돌파구는 단순한 "속도 향상"을 훨씬 넘어서는 것으로, 전체 처리량에서 직접적인 규모의 차수 도약입니다.
[2] 코딩이 더 이상 병목이 아닐 때, 새로운 장애물은 어디에 나타날까요?#
Claude Code 팀의 현재 병목 현상은 검증, 리뷰, 교차 기능 협업, 보안입니다.
코드 양이 증가한 후, 그녀가 다른 엔지니어링 리더들로부터 가장 많이 받은 질문은: "인간이 이 모든 코드를 어떻게 리뷰할 수 있습니까?"였습니다. 그녀는 또한 유지보수 비용을 계산하는 방법을 알고 싶어 했습니다. 코드 생성 비용은 거의 0에 가깝지만, 유지보수 비용은 그렇지 않을 것입니다.
참고: 강연에서 "Claude Code로 Claude Code 구축"에 대한 언급은 Anthropic의 공개 관행입니다. Boris Cherny는 여러 인터뷰에서 Claude Code를 사용하여 비기술 사용자를 위한 데스크톱 에이전트인 Cowork를 10일 만에 구축했다고 언급했습니다. 이는 수사학이 아닌 엔지니어링 현실입니다.
그녀는 "조용히 실패하고 있는" 구식 프로세스 목록을 제시했습니다: 6개월 제품 로드맵, 번거로운 일정 회의, 코드 소유권 분할, 마라톤 코드 리뷰 세션, 단계별 전통적 팀 구조, 지식 베이스 공유, 긴 신규 채용 온보딩. 이 모든 것은 "개발 비용이 너무 높다"는 원래 가정에 의해 강제로 존재하게 된 역사적 유물입니다.
"프로세스는 거의 스스로 죽지 않습니다. 우리는 계속해서 더 많은 프로세스를 추가할 뿐입니다."
그녀는 고통스러운 예를 들었습니다: 이전 팀에서 SLA(서비스 수준 계약)가 너무 많아서 엔지니어들이 어떤 것을 우선시해야 할지 파악하기 위해 대규모 스프레드시트로 강제 순위를 매겨야 했습니다. 그녀는 이 과잉 축적을 오랫동안 정리해야 한다고 느꼈지만, Anthropic에 합류한 후에야 실제로 조치를 취했습니다.
[3] 줄일 것: 6개월 로드맵, 디자인 문서, 제품 리뷰#
그녀가 Claude Code에 처음 합류했을 때, "6개월 로드맵이 필요하지 않나요?"라고 물었습니다.
로드맵을 작성했고, 처음 3개월 동안은 유용했습니다. 새해가 지나자 대부분이 이미 변경되었습니다. 그녀는 이제 "jit 플래닝"(적시 계획)이라는 한 단어를 사용합니다. 프로그래밍의 적시 컴파일 개념을 빌려온 것입니다. 필요할 때만 계획한다는 뜻인데, 프로토타입 제작 비용이 거의 0에 가까워졌고 "사전 계획"의 레버리지가 사라졌기 때문입니다.
디자인 문서도 대폭 줄었습니다. Claude Code 팀의 기본 논의 방식은 "먼저 문서를 작성하라"에서 "먼저 PR을 보내라"로 바뀌었습니다. 아이디어가 있으면 바로 빌드하는 것입니다. 제품 리뷰 회의도 빈도가 줄었습니다. 제품 변화가 너무 빠르기 때문입니다. 목업을 검토하는 대신, 내부 버전을 Anthropic 전체에 푸시하고(회사 이름 Anthropic에 "ant"가 들어있어 그녀는 이것을 "ant-feeding"이라고 부릅니다), 그다음 외부 사용자에게 푸시하여 그들이 어떻게 사용하는지 듣습니다.
[4] 늘릴 것: 검증, 품질 보증의 상류 이동#
그녀는 팀이 검증에 집중하기를 바라며, 이를 "시프트 레프트(shift left)"라고 부릅니다. 전통적인 소프트웨어 파이프라인에서 왼쪽은 소스(source)이고 오른쪽은 전달(delivery)입니다. 시프트 레프트는 품질 보증을 전달 쪽의 수동 테스트에서 소스 쪽의 자동화된 검사로 이동시키는 것을 의미합니다.
이것이 왜 중요해졌을까요? 역할 경계가 흐려지고 있기 때문입니다. 그녀의 디자이너 동료들은 이제 코드를 제출하고 있습니다. Fiona는 실제로 있었던 작은 불안감을 공유했습니다. 한 번은 채용 지원과 관련된 버그를 수정했는데, 다음 날 Boris의 메시지 피드를 훑어보다가 누군가가 그에게 새 버그에 대해 @멘션을 한 것을 보았습니다. 그녀는 "심장이 철렁 내려앉았다"고 당시 기분을 표현했으며, 자신이 망가뜨린 것일까 봐 무서웠다고 말했습니다.
아무도 자신의 커밋으로 서비스를 중단시키고 싶어 하지 않습니다. 이 높은 처리량 환경에서 이것은 매우 현실적인 심리적 부담입니다. 전통적인 수동 QA는 이렇게 높은 코드 출력 속도를 따라잡을 수 없기 때문에, 품질 보증은 프로세스 초기 단계의 자동화된 메커니즘에 더 크게 의존해야 합니다.
[5] 기술 논쟁 방식의 변화: 화이트보드에서 세 개의 PR로#
그녀가 처음 Claude Code 팀에 합류했을 때, 코드베이스를 익히기 위해 리팩터링을 하고 싶었습니다. 기술적 접근 방식에 대해 Boris와 의견이 달랐고, 거의 본능적으로 "화이트보드 방에 가서 스케치해보자"고 말할 뻔했습니다.
다음 순간, 그녀는 Claude에게 세 가지 다른 버전의 PR을 동시에 생성하도록 하여 완전한 코드 구현을 직접 비교하고, 모든 호출자에 미치는 영향까지 확인할 수 있다는 것을 깨달았습니다. 화이트보드에서는 이렇게 직관적이고 전체적인 시야를 얻을 수 없지만, 코드는 그것을 제공할 수 있습니다.
"빌드하는 것이 저렴해지면, 논쟁하는 것은 비싸진다."
그녀가 이 요점을 말할 때 목소리가 특히 진지했습니다. 청중에게 즉시 상기시켰습니다. 코드 생성 비용이 거의 0에 가까워지고 있기 때문에, 팀 문화와 기본 합의가 더욱 중요해진다는 점입니다.
절대 "마지막으로 커밋한 사람이 이긴다"는 상황이 되어서는 안 됩니다. 예를 들어, 누군가 새벽 3시까지 깨어서 몰래 커밋을 하거나, 배포 직전에 예약된 작업을 설정하여 변경 사항을 끼워 넣는 것은 절대 허용되지 않습니다. 코드가 더 이상 가치 있는 자원이 아니기 때문에, 팀 전체의 수평적 정렬에는 더 명확한 기준선이 필요합니다.
[6] 코드 리뷰: Claude가 처리할 것과 사람이 유지할 것#
Cat Wu는 이미 오전 기조연설에서 Claude의 자동화된 PR 리뷰 기능을 다루었습니다. Fiona의 관점은 여기서 더 구체적입니다. 무엇을 Claude에 넘기고, 무엇을 사람이 유지할지에 대한 것입니다.
참고: Cat Wu는 Claude Code의 제품 리드이며, Boris Cherny와 함께 제품 방향을 공동으로 이끌고 있습니다.
Claude에 넘길 것: 스타일 검사, 린트 중복 제거, 코드 리뷰 코멘트 응답, 일반적인 버그 포착, 단위 테스트 작성. 그녀는 Claude가 이제 PR을 "정리(grooming)"하는 데 매우 능숙하며, 보통 사람이 건드리기 전에 대부분의 더러운 작업을 처리한다고 말합니다.
여전히 사람의 개입이 필요한 세 가지 범주: 법률 및 규정 준수 리뷰(위험 노출 때문), 보안에 민감한 코드 경계 확인(취약점 비용이 너무 높기 때문), 제품 감각과 취향(현재 대규모 언어 모델에게는 여전히 큰 장벽).
세 번째 범주에 대해 그녀는 가벼운 예를 들었습니다. 그녀에게는 작은 취미가 있습니다. 명절마다 Claude의 터미널 아이콘을 꾸미는 것입니다. 크리스마스에는 Claude를 눈사람으로 만들고 싶어서 Claude에게 ASCII 아트로 그려달라고 했습니다. 결과를 디자이너 동료에게 피드백을 위해 보냈더니, "땅콩 아저씨(Mr. Peanut)로 만들어버렸네요"라는 답변이 돌아왔습니다.
참고: Mr. Peanut은 미국의 유명 스낵 브랜드 Planters의 마스코트입니다. 모자와 단안경을 쓰고 있으며, 실루엣이 눈사람과 비슷합니다.
결국 그녀는 간단한 방법을 선택했습니다. 얼음 파랑 + 눈송이입니다. 이 이야기를 통해 제품 감각의 중요성을 설명했습니다. 추상적인 판단은 자동화하기 매우 어렵습니다.
[7] 코드 경계는 흐려지고, 역할 분담은 재편되고 있다#
Claude Code 팀에서는 거의 모든 PR에 Claude가 관여합니다. "이 코드를 실제로 누가 작성했는가?"라는 질문은 점점 터무니없고 심지어 무의미해지고 있습니다.
Fiona는 이 표면적인 질문에 집착하지 말라고 조언합니다. 대신, 당신이 정말로 알고 싶은 것이 무엇인지 파고들라고 말합니다. 누구의 변경 사항이 버그를 촉발했는가? 고객에게 기술적 세부 사항을 설명할 충분한 컨텍스트를 가진 사람은 누구인가? 이 코드 모듈의 이력을 가장 잘 아는 사람은 누구인가? 이렇게 더 구체적인 하위 질문을 하면, 종종 더 나은 자동화된 답변 경로가 있다는 것을 알게 됩니다. 예를 들어, 그녀에게는 매일 아침 커피 한 잔을 내리고 Claude Code를 사용하여 고객 피드백 채널에 연결해 요약을 실행하는 습관이 있었습니다. 이제 그 작업은 Routines 자동화 작업으로 오케스트레이션되어 수동 명령 입력조차 필요 없게 되었습니다.
참고: Routines는 Claude Code의 기능으로, 예약 또는 트리거 기반 자동화 작업을 설정할 수 있습니다. Fiona가 이 발표를 준비하는 동안 이 기능이 막 출시되어, 그녀의 슬라이드 내용조차 업데이트가 필요했습니다.
이러한 역할 혼합은 양방향으로 발생합니다. 한쪽에서는 비기술 직군이 직접 코딩에 뛰어들고 있습니다. Claude Code 팀의 PM은 적극적으로 PR을 제출하고 있습니다. 다른 한쪽에서는 엔지니어들이 자신의 영역을 벗어나 전통적으로 다른 역할에 속했던 업무를 맡고 있습니다. Fiona는 자신을 예로 들었습니다. Claude Code의 사용자 설문조사를 개선하고 싶었지만 콘텐츠 디자이너를 찾을 수 없었습니다. 과거에는 콘텐츠 팀과 단어 선택에 대해 반복적으로 지적해야 했을 것입니다. 이제 그녀는 Claude를 카피라이팅 파트너로 사용합니다. 전형적인 엔지니어로서 "카피를 간결하게 만드는 데는 정말 최악"이라고 농담했습니다.
채용에서 Claude Code 팀은 두 가지 유형의 사람에 주목합니다. 하나는 제품 감각을 가진 창의적인 빌더입니다. 호기심이 많고, 문제를 보면 그것을 해결할 제품을 만들고 경험을 반복하고 싶어 하는 사람입니다. 다른 하나는 깊이 있는 시스템 전문가입니다. Claude Code Remote를 구축할 때 분산 시스템 경험이 있는 사람이 부족하다는 것을 깨달았습니다. 그녀가 더 이상 가치를 두지 않는 것은 원시적인 코딩 처리량입니다. 모델이 이미 그 격차를 평준화했기 때문입니다.
[8] 조직 구조: 플랫하게 유지하고, 매니저는 IC부터 시작#
Anthropic이 그녀를 Claude Code에 영입했을 때, 기본 구조는 "매니저 1명당 IC 10명, 그리고 아래로 중첩"이었습니다. 피오나는 이를 원하지 않았습니다.
그녀는 가능한 한 플랫한 구조를 원했습니다. Claude Code와 Cowork 라인은 각 하위 그룹이 자체적으로 정의하지 않고, 단일 팀 미션을 공유합니다. 그 이유는 실용적입니다. 미션이 변경될 때, 여러 계층이 있으면 하향 조정에 많은 시간이 소요됩니다. 플랫함은 유연성을 의미합니다.
그녀는 또한 모든 Claude Code 팀 매니저는 먼저 IC(개인 기여자, 최전선 엔지니어)로 일해야 한다고 주장했습니다.
채용 담당자의 초기 반응은 "당신 미쳤군요"였는데, 이는 어떤 매니저도 기꺼이 IC를 먼저 하려 하지 않을 것이라는 의미였습니다.
"이것이 Claude Code 팀의 도그푸딩(dogfooding)이 의미하는 바이며, 이것이 제가 기대하는 바입니다. 누군가 관심이 없다면, 저희는 일찍 결별하는 것이 더 낫습니다."
이 규칙은 그녀 자신에게도 적용됩니다. 그녀의 마지막 프로덕션 푸시는 2017년이었습니다. 그녀는 Anthropic에 합류한 후에야 다시 코드를 작성하기 시작했습니다. 그녀는 Meta에서 1년에 한 번 PR을 제출하려고 노력했지만, 내부 도구가 너무 빨리 변경되어 한 해에 한 명령어를 배우면 다음 해에는 쓸모없게 되었다고 말했습니다.
"요즘은 git 명령어조차 기억나지 않아서, 항상 Claude에게 모든 것을 도와달라고 요청합니다."
[9] 문서화 폐기, 코드를 "단일 진실 공급원"으로 만들기#
Claude Code 팀은 이제 코드를 궁극적인 진실의 원천으로 취급합니다. 예를 들어, 피오나는 현재 기술 지원 문의를 어떻게 처리할까요? 그녀는 데스크톱 버전의 Claude Code를 직접 실행하고, 로컬 저장소를 마운트한 다음, LLM이 코드에서 직접 로직을 찾아 질문에 답변하도록 합니다. 이 접근 방식은 소프트웨어 업계의 천년 묵은 문제, 즉 개발 문서가 항상 코드와 동기화되지 않는 문제를 효과적으로 제거합니다.
하지만 그녀는 특히 주의사항을 덧붙였습니다. 이 경험이 보편적인 규칙은 아니라는 것입니다. 팀의 업무에 포괄적인 요구 사항 문서가 필요하다면, 코드 저장소에 스펙도 포함시켜 Claude가 최종 코드가 문서에 명시된 내용과 일치하는지 교차 검증하도록 하는 것이 합리적입니다.
이러한 변경 사항을 구현할 때 피오나는 두 가지 계층, 즉 "통합되어야 하는 것"과 "팀에 위임하는 것"을 구분했습니다. 통합되어야 하는 핵심 원칙은 다음과 같습니다. 모든 팀 구성원은 Claude Code를 사용해야 하며(교차 기능 파트너 포함, Cowork도 포함), 가능한 한 많은 작업을 Claude로 자동화하고(내부적으로는 "모든 것을 Claudify"라고 함), 더 이상 사람들에게 도움이 되지 않는 오래된 프로세스를 명시적으로 종료할 수 있도록 허용하는 것입니다.
마지막 요점에 대해 그녀는 구체적인 예를 들었습니다. Claude Code 팀은 한때 스탠드업 미팅을 가졌지만, 팀이 성장함에 따라 공유 스프레드시트에 주간 진행 상황을 작성하는 방식으로 전환했습니다. 어느 날, 이 거대한 표를 보면서 그녀는 그것이 완전히 무의미하다는 것을 깨달았습니다. 정보는 분명히 Claude가 읽을 수 있는 곳에 있었습니다. 실제로 Claude가 요약 스크립트를 작성하여 거기에 넣어두면, 누구든지 언제든지 다른 사람의 상태 요약을 가져올 수 있는 것이 사람들에게 양식을 작성하라고 재촉하는 것보다 훨씬 낫습니다.
그러나 팀이 스스로 결정할 수 있는 공간도 매우 명확합니다. 버그 분류 메커니즘, 일정 리듬, 누가 언제 온콜(on-call)이고 어떻게 할 것인지, 심지어 어떤 워크플로우가 우선순위가 더 높아 먼저 Claude로 마이그레이션되어야 하는지 등은 모두 팀이 스스로 결정하도록 위임됩니다.
[10] 세 가지 관찰 가능한 지표와 한 가지 경고#
그녀는 구체적인 수치를 공개하지 않았지만, 세 가지 방향을 지적했습니다.
- 신규 입사자의 적응 시간이 크게 단축되었습니다. 엔지니어, 디자이너, PM 모두 새로운 팀에서 훨씬 더 빨리 생산성을 발휘합니다.
- PR 주기 시간이 눈에 띄게 단축되었습니다. 그녀는 이것이 실제로 파고들 가치가 있는 지표라고 언급했는데, 그 변화는 AI 도구에 대한 팀의 수용도뿐만 아니라 다운스트림 인프라의 약점, 예를 들어 CI 파이프라인이나 제품 인프라 환경이 엔지니어의 급격히 증가한 커밋 속도를 감당하지 못하는 경우를 드러낼 수 있기 때문입니다.
- Claude 지원 커밋의 적용 범위 비율이 증가하고 있습니다. Claude Code 팀의 문화에서 Claude가 관련된 모든 커밋은 기본적인 정상 작동입니다.
"아마 지난 4개월 정도 동안 Claude의 도움 없이 이루어진 커밋은 본 적이 없는 것 같습니다."
하지만 그녀는 이 지표 섹션에 경고를 명시적으로 추가했습니다. "AI가 생성한 코드의 양"만 보지 말라는 것입니다. 각종 회사 보도자료의 비율은 계속 높아지고 있지만, 처리량 자체가 목표는 아닙니다. 실제로 해결하고 있는 문제가 무엇인지, 제품 품질과 안정성이 여전히 유지되고 있는지 되돌아봐야 합니다.
[11] 아직 해결하지 못한 세 가지#
피오나는 강연 말미에 아직 답을 찾지 못한 세 가지 질문이 있다고 인정했습니다.
첫째, 엔지니어가 플랫폼 간에 작업할 수 있게 된 후, 전통적인 "iOS 팀 + Android 팀" 구분이 여전히 유효한가?
둘째, 자동화된 리뷰를 어느 수준까지 밀어붙여야 하는가? "신뢰하되 검증하라"는 경계는 모델이 개선됨에 따라 다시 바뀔 것입니다. 그녀는 그날 앞서 모델 기능에 대한 강연을 언급하며, Claude에 얼마나 많은 리뷰를 위임할지는 일회성 결정이 아님을 암시했습니다.
셋째, 역할이 모호해진 후, 모든 사람이 동등하게 생산적이라고 느끼게 하려면 어떻게 해야 하는가? 엔지니어가 콘텐츠를 만들고, PM이 코드를 작성하며, 디자이너가 버그를 수정할 수 있게 되면, 결과물에 대한 전통적인 소유권이 모호해집니다. 공정성에 대한 감각을 설계하는 것은 새로운 도전 과제입니다.
청중을 위한 그녀의 마지막 조언은 사실 매우 간단했습니다.
"가장 시끄러운 워크플로우를 골라보세요... 그것이 여전히 진정으로 도움이 되고 있는지, 그 목적이 무엇인지 생각해보세요."
그녀는 자신의 경험을 반례(反例)로 사용했습니다. 과거에 어떤 팀을 이끌 때, 50명이 넘는 사람들이 큰 방에 빽빽이 들어찬 흔들 수 없는 주간 회의가 있었습니다. 하지만 자세히 살펴보니, 피오나는 상태 보고를 하라고 지명된 사람이 보고하는 척하는 것 외에는 다른 모든 사람들이 일제히 키보드를 두드리고 있다는 것을 발견했습니다. 나중에 그녀는 단순히 "우리가 대체 이 빌어먹을 회의를 왜 계속 하는 거야?"라고 물었습니다. 즉시 만장일치로 통과되어 그 자리에서 해산되었습니다.