내가 알고 있는 가장 최악의 프로그래머

• 한 Big Bank 컨설팅 팀은 개인 생산성을 완료한 스토리/스토리 포인트로 재려 했고, Tim Mackinnon은 그 지표에서 반복적으로 0점을 받았음
• 점수가 0이었던 이유는 일을 안 해서가 아니라, 자기 이름으로 스토리를 잡지 않고 하루 대부분을 페어 프로그래밍에 썼기 때문임
• 경험이 적은 개발자에게는 직접 답을 주기보다 소크라테스식 질문으로 학습을 만들고, 시니어와는 서로 다른 관점으로 더 나은 해법을 함께 찾았음
• 팀은 Tim이 함께할 때 더 효과적이고 생산적이며 정렬된 방식으로 일했고, 관리자는 결국 Tim을 남긴 채 개인 생산성 지표를 조용히 폐기했음
• 개인 기여를 따로 떼어 재는 방식은 Tim 같은 기여를 0으로 만들 수 있으므로, 생산성은 비즈니스 영향과 팀 단위 흐름으로 봐야 함

---

개인 지표가 만든 “0점 프로그래머”

• Big Bank의 한 팀은 개인 성과 평가와 개발 목적을 위해 개인별 성과 지표를 도입함
• 관리자는 코드 라인 수나 버그 수처럼 쉽게 조작될 수 있는 지표를 피하고, 비즈니스 가치를 대표한다는 이유로 완료한 스토리 또는 스토리 포인트를 측정 대상으로 삼음
• Jira와 비슷한 도구에서 각 사람이 스토리에 이름을 올렸기 때문에 개인별 생산성 지표를 만들기 쉬웠음
• Tim Mackinnon의 점수는 낮은 수준이 아니라, 매주와 매 반복마다 문자 그대로 0점이었음
• 관리자는 Tim을 팀에서 빼고 스토리를 실제로 “전달하는” 사람으로 교체해야 한다고 봤지만, 팀 리드는 이를 거부함

Tim이 실제로 전달한 것

• Tim은 자기 이름으로 스토리를 맡지 않았고, 대신 매일 다른 팀원과 페어링하며 일함
• 경험이 적은 개발자와 일할 때는 그들이 직접 운전하게 두고, 해결책으로 가도록 부드럽게 유도함
  • 답을 강요하거나 밀어붙이지 않음
  • “what if”, “how else” 같은 질문과 Socratic questions로 학습 순간을 만듦
• 시니어 개발자와는 공동 창작이나 스파링에 가까운 방식으로 일했고, 서로 다른 세계관을 문제에 적용해 혼자서는 떠올리기 어려운 결과를 만들었음
• Tim은 소프트웨어를 직접 전달하기보다, 소프트웨어를 전달하는 팀을 키움
  • 팀 전체가 더 효과적이고 생산적으로 움직임
  • 더 잘 정렬되고, 더 관용적인 방식으로 일함
  • 함께 일하는 경험도 더 즐거워짐
• 관리자가 팀을 관찰하러 왔을 때 Tim은 항상 다른 사람과 함께 “그 사람의 일”을 하고 있었고, 그 결과물은 품질이 좋아지고 가치 전달 시간도 짧아졌음
• 결국 팀은 Tim을 유지했고, 개인 생산성 지표 대신 팀 책임성을 선택함
  • 고성과 단위로서 조직에 전달한 비즈니스 영향을 추적하고 축하함

생산성은 어디를 봐야 하는가

• 생산성 측정 자체는 필요하며, 책임성을 갖기 위해서는 측정 가능한 비즈니스 영향이 이상적임
  • 절감한 금액
  • 창출한 금액
  • 보호한 금액
• 직접적인 비즈니스 영향 측정이 어렵다면 대리 비즈니스 지표도 사용할 수 있음
• 복잡한 적응 시스템에서는 개인 한 명의 기여를 따로 떼어 측정하려는 전제부터 흔들림
• DORA 지표는 개인 피스톤의 기여가 아니라 작업 시스템의 작동 방식을 측정함
  • Westrum 문화 지표로 볼 수 있음
  • 기술 변경이 프로덕션으로 흐르는 방식을 보는 지표로도 볼 수 있음
• 개인 지표는 Tim 같은 사람의 실제 기여를 0으로 만들 수 있고, 팀 단위 성과와 시스템 수준의 흐름을 보는 방식이 더 적합함

[GN⁺]

Hacker News 의견들

• 20년쯤 전 Mac과 Windows용 데스크톱 앱을 팔던 중견 소프트웨어 회사에서 일했는데, 팀은 대부분 Mac 경험만 있고 Windows는 막 배우는 단계라 Windows 버전에 문제가 많았음
  당시 나는 Windows 전문가로 알려져 있어서, 그 버전을 개선하고 팀이 Windows 프로그래밍에 익숙해지도록 돕기 위해 채용됨
  하루의 앞부분은 주로 “왕진”처럼 다른 개발자 방을 돌며 짝 프로그래밍, 버그 조사, Windows API 모범 사례 논의를 했고, 나중에 동료가 “어떻게 그렇게 시간을 넉넉히 쓸 수 있냐”고 물었음
  몇 달 뒤 평가에서 “생산성이 기대만큼은 아니며, 특히 나머지 팀의 생산성이 최근 올라간 점을 고려하면 그렇다”는 평을 받았고, 그게 바로 나를 뽑은 이유라고 생각했었음

  • 이미 늦었겠지만, 이런 개발자가 우리 직업을 진짜 장인적 기술로 만들어 줌
    지식 공유는 다른 개발자에게 줄 수 있는 가장 큰 이익인데, 그 길을 택한 사람들은 보상을 너무 적게 받음
    이런 개발자가 없었다면 지금의 소프트웨어 세계에 가까이 오지도 못했을 것이고, 직접 감사받지 못해도 분명히 가치가 있음
  • 대학 시절 인턴으로 휴대용·차량 장착형 러기드 단말기와 802.11 이전의 RF 네트워크 컨트롤러 같은 기지국을 수리했음
    모든 수리 작업의 우선순위는 같았지만 난이도는 달랐고, 한 달 동안 배우기도 하고 아무도 안 하기도 해서 기지국 수리를 맡았더니 시간이 더 걸렸지만 운영에는 훨씬 중요했음
    월말 회의에서 활용률 파이 차트가 나왔고, 나는 숙련된 선임들보다 훨씬 나쁘게 보였음
    그때 선임들이 빠르고 쉬운 일만 골라 잡는 이유와 사내 정치의 존재를 배웠고, 형편없는 상사를 커리어 초기에 겪은 건 오히려 다행이었음
  • 지금의 스태프 엔지니어에 해당하던 시절 비슷한 일을 겪었음
    새 상사는 첫 평가에서 원래 성과 개선 계획을 써뒀지만, 오픈 오피스로 옮긴 뒤 도움을 받으러 내게 줄 서는 사람들과 아무도 돌려보내지 않는 모습을 보고 버렸다고 인정함
    칸막이 자리를 잃은 건 좀 짜증났지만, 그 일 덕분에 오픈 오피스를 긍정적으로 보게 됨
    물론 이제는 어떤 사무실에서도 일하지 않고, 재택이 아닌 일은 다시 받지 않을 생각임
  • 회사가 무엇을 가치 있게 보는지 찾아내고 거기에 맞춰 최적화하는 게 중요함
    평판이 먼저 만들어진 뒤에야 무언가를 바꿀 수 있고, 그 전에는 어려움
    너무 많은 사람이 “팀”을 위해 최적화하다가 윗선의 부정적 인식 때문에 해고되거나 승진에서 밀렸고, 반대로 회사가 현재 중시하는 기준에서 좋은 평판을 얻은 사람은 꽤 오래 나쁜 행동도 용인받곤 함
  • 그 평범한 평가 뒤에 어떻게 됐는지가 궁금함
    바로 더 나은 곳으로 떠났는지, 회사의 성과 지표에 맞춰 시간을 덜 나눠주기 시작했는지, 아니면 조직도상 충분히 높은 사람에게 실제로 그런 역할로 채용된 것임을 설득했는지 궁금함

• Bell Labs 일화가 떠오름
  누군가 특허 수 같은 기준으로 가장 생산적인 직원을 계산했더니, 그들 다수가 같은 사람과 점심을 먹는다는 사실을 발견함
  그 사람 자체는 개인 생산성이 높지 않았지만, 늘 깊이 있고 설득력 있는 질문을 던져 동료들을 측정 가능하게 더 생산적으로 만들었음

  • Jon Gertner의 훌륭한 책 The Idea Factory 135쪽에 나오는 내용일 수 있음
    Bell Labs 특허 부서의 변호사들이 왜 어떤 사람이 더 생산적인지 설명할 조직 원리를 찾으려 했고, 공통점은 특허가 많은 직원들이 전기공학자 Harry Nyquist와 점심이나 아침을 자주 함께했다는 것뿐이었음
    Nyquist가 구체적 아이디어를 준 건 아니고, 사람들을 끌어내 생각하게 만들었으며, 무엇보다 좋은 질문을 던졌음
  • 이런 사람은 Peopleware에서도 어느 정도 다뤄졌던 것 같음
    사람들의 집단은 섬세한 구조라서, 좋은 팀 분위기와 좋은 질문은 보이지 않게 상황을 개선할 수 있음
  • 이런 유형의 사람은 회사를 차려야 함
    그렇지 않으면 공정한 임금을 받기 어려움
  • 많은 사람이 Scrum Master와 Agile Coach를 비판하지만, 좋은 사람들은 원래 이런 역할의 일부를 해야 함
  • 이런 일이 정식으로 잡힌 Zoom 1:1 일정으로 재현된다고 정말 믿는지 모르겠음
    나는 아니라고 봄

• 몇 년 동안 다닌 회사에서는 주당 10포인트를 만들지 못하면 성과 개선 대상이 됐고, 주니어든 시니어든 상관없었음
  여러 팀을 거쳤는데, 팀이 포인트를 어떻게 측정하는지는 개발자들의 스트레스 수준만 봐도 바로 알 수 있었음
  선의로 포인트를 재려던 팀은 스트레스를 받고 대부분 번아웃 징후가 있었으며 주 60시간씩 일했음
  반대로 시스템을 게임처럼 다루며 불가능한 과제임을 이해한 팀은 티켓에 가능한 한 높은 포인트를 주거나 작은 티켓으로 쪼개 계속 점수를 쌓았고, 스트레스 없이 행복했음
  그런 환경에서 규칙대로 하는 건 호구 전략이었고, 내가 결국 그만두자 회사의 시니어 엔지니어 7명이 4개월 안에 모두 따라 나갔음

  • 작은 티켓으로 쪼개 계속 포인트를 더한 건 사실 스크럼의 취지 일부이기도 함
    큰 불확실성과 위험이 있는 이야기보다, 꾸준히 스트레스 없이 달성 가능한 이야기로 나누는 것이 목표임
    그 직장이 좋아 보인다는 뜻은 아니지만, 시스템을 게임했다고 본 개발자들은 대체로 스크럼이 장려하려는 방식대로 움직인 것처럼 보임
    다만 주당 최소 포인트를 강제해 포인트 부풀리기를 유도하는 건 끔찍한 관리임
  • 단기적으로는 회사가 이득을 봤을 수 있음
    압박을 걸지 않았을 때보다 같은 사람들에게서 더 많은 일을 뽑아냈기 때문임
    예전 상사는 프로젝트를 끝내기 위해 “사람을 뽑아 태워버린다”고 노골적으로 말했고, 6개월만 쓸모 있게 일하면 된다고 계획했음
    스트레스와 낮은 보상을 견디고 남아 있다면 회사 입장에서는 덤이라는 식이었고, 나도 오래 버티지 않았음
  • 예전 회사에서는 그걸 Scrumflation이라고 불렀음
    그 주에 다 못 끝냈으면 티켓은 완료 처리하고, 남은 작업은 버그로 새로 여는 식이었음
  • Goodhart의 법칙 그대로임
    “측정값이 목표가 되는 순간, 그 측정값은 좋은 측정값이 아니게 된다”
  • 아이러니하게도 그 결과가 경영진이 원한 것과 정확히 맞았을 수도 있음
    어떤 곳에서는 목표를 향한 순수 생산성보다, 관리자가 무엇을 기대할 수 있는지 아는 것이 더 중요했음
    선의로 추정한 사람들은 경영진도 선의로 행동한다고 생각했을지 모르지만, 많은 프로젝트는 희망 사항으로 만들어지거나 사람들을 “동기부여”하려고 인위적으로 짧은 마감일을 둠
    그 스트레스는 관리자의 감정적 만족 외에는 별 가치를 만들지 않았을 수도 있음

• 소프트웨어 엔지니어의 성과를 비기술자가 평가하면 극적인 결과가 나올 수 있음
  내 친구 “Tommy”는 네트워크 실력이 뛰어난 IT 담당자였고, 정부 소유 에너지 회사로 옮긴 지 몇 주 만에 본사 모든 건물까지 포함해 네트워크를 현대 장비로 전면 재구축해야 했음
  회사는 외부 업체에 맡기려 했지만, 재무 부서가 책정한 비용을 보고 Tommy는 놀랐고, 라우터·스위치·케이블 같은 물리 장비와 배선 담당 2명만 있으면 직접 할 수 있다고 말함
  그는 몇 주 만에 초기 예산의 10분의 1도 안 되는 비용으로 일을 끝냈지만, 받은 건 상사의 구두 “고맙다, 잘했다”뿐이었음
  상사들이 구식이라 진짜 가치를 이해하지 못하는 시대의 IT 기술자는 참 씁쓸함

  • 친구가 회사를 만들어 입찰하게 했어야 함
    나중에 Tommy가 계약자로 들어가 추가 보수를 받을 수 있었을 것임
  • Tommy가 속상해했는지가 궁금함

• 함께 일했던 정말 뛰어난 개발자는 훌륭한 코드도 쓰고, 당장 갈아엎어야 하는 끔찍한 코드도 썼는데, 둘 다 함께 일하기 좋게 만드는 요소였음
  좋은 코드의 가치는 설명할 필요가 없고, 지금도 그의 코드를 쓰고 있을 가능성이 있음
  하지만 그는 긴급 상황에서도 탁월했음
  고객이 완전히 멈췄고 우리 잘못일 수 있는 상황에서, 곧바로 나타나 문제를 빠르게 파악하고 고객을 다시 움직이게 할 지저분한 스파게티 코드를 빠르게 작성해 설치했음
  체크인할 수도 리팩터링할 수도 없는 눈 아픈 코드였지만, 누군가 나중에 제대로 고쳐야 하는 동안 당장의 위기는 피했음
  나는 오히려 이 후자의 능력에 더 감탄했는데, 무엇보다 드문 기술이었고 그는 그냥 좋은 사람이어서 모두가 좋아했음

  • 나는 이런 소방수형 개발자인데, 코드가 훌륭하거나 미래 지향적이지 않아서 다른 개발자들과 마찰이 있음
    그래도 일을 빠르게 끝내고, 내 별난 코드가 긴급 상황을 해결하거나 입찰을 따내며 여러 번 하루를 구했음
    “완벽 지향” 개발자들과는 소통이 어렵고, 그들에게는 코드가 충분히 설계되지 않았다면 속도가 필요하다는 점을 이해해도 가치가 없게 보임
    물론 그들도 나에 대해 반대로 생각할 것임
    지금은 매주 회의를 만들어 문제를 완화하고 있고 꽤 잘 작동함
    가장 어려운 건 긴급 상황은 아니지만 일정이 빡빡하고 명세가 불명확할 때 어떤 유형의 접근이 맞는지 정하는 일이며, 적어도 공동으로 결정하게 됨
  • 권장할 일은 아니지만, 즉석에서 문제에 맞는 코드를 만들어야 하는 경쟁 프로그래밍 경험이 있는 사람처럼 들림
    스스로 배울 수 없는 건 아니지만, 흔한 문제와 해법을 기계적으로 타이핑할 수 있을 정도로 암기하는 방식은 나에게는 정말 괴로운 일임

• 회사를 소유하지 않는 한, 항상 겉으로 보이는 가치로 평가받음
  고용주가 시각적으로 당신의 가치를 보지 못하면 그곳에서 버틸 가능성은 낮음
  완전한 능력주의 성과 시스템이 이상적이긴 하지만, 고용이나 평가를 다른 사람이 쥐고 있다면 성공은 100% 그 사람이 당신을 어떻게 보느냐에 달려 있음
  그 인식은 회사에 실제로 가치가 있든 없든 겉으로 보이는 모습에서 생김
  여기서 말하는 건 프로그래밍 실력이나 실제 가치가 아니라 고용과 평가이며, 생산성이 높으면서도 평판 관리를 잘하는 사람도 많음

  • 회사를 소유해도 고객에게는 여전히 겉모습으로 평가받음

• 개인적으로 팀의 시니어들은 정말 어려운 일을 실제로 해내길 원함
  주니어가 일을 하도록 돕는 것도 좋지만, 지식·경험·대인 기술이 부족한 주니어가 할 수 없는 어렵고 복잡한 일에는 여전히 숙련자가 필요함
  어떤 짝 프로그래밍도 그걸 완전히 대체할 수 없음
  낮은 가치의 기능은 매우 잘 구현됐지만, 가장 경험 많은 사람들이 덜 숙련된 사람들에게 단위 테스트 작성법 같은 걸 도와주느라 고영향·고우선순위 작업이 끝나지 않는 상황은 피해야 함

  • 시니어 엔지니어가 주니어에게 배정된 어려운 문제를 함께 풀면, 잘 구현된 어려운 기능과 덜 주니어다운 엔지니어가 동시에 생김
    주니어가 맡았다고 해서 기본적으로 쉬운 문제라는 뜻은 아니며, 그렇지 않으면 엔지니어를 어떻게 성장시킬 수 있겠음
  • 글에서 얻어야 할 교훈은 모든, 혹은 대부분의 시니어 개발자가 이렇게 해야 한다는 게 아님
    모든 시니어가 주니어 멘토링과 협업에 시간을 쓰면 안 되지만, 팀에 몇 명 이런 사람이 있으면 힘을 배가시키는 역할을 하며 전체 팀에 이득이 됨
    채용 당시에는 몰랐더라도, 그가 유용한 틈새 역할을 찾았다면 회사는 이를 공식 역할로 바꿨어야 함
  • Tim이 실제로 가치를 전달하는 코드를 전혀 쓰지 않았다면 프로그래머 일을 한 건 아님
    그는 코치였고, 그런 역할로 뽑았다면 괜찮지만 아마 코치를 원했다면 따로 고용했을 것임
    어려운 기능은 무한한 시간을 줘도 주니어가 못 끝내는 경우가 있는데, 아직 기술이 없고 그 기술은 몇 년이 걸려야 생기기 때문임
    가끔 시니어의 도움은 필요하지만 그 때문에 시니어가 아무것도 만들지 못한다면 회사 입장에서는 의미가 약함
    어려운 기능은 충분히 시니어인 사람에게 주고, 주니어를 키우고 싶다면 그 작업의 쉬운 부분을 함께 나누고 시니어가 무엇을 하는지 설명하게 하면 됨
    모두를 돕는 Tim의 태도는 훌륭하지만, 다른 프로그래머들이 그렇게 많은 도움을 필요로해서 Tim이 자기 산출물을 낼 시간이 전혀 없다는 것도 이상함
    문제는 Tim이 아니라, 전문가가 늘 도움을 필요로 하는 상태와 자원봉사자 같은 Tim이 언제든 도와주는 구조를 괜찮다고 여긴 관리에 있음
  • 또는 코드베이스를 리팩터링해서 어떤 작업도 그렇게 “어렵고 복잡”하지 않게 만들어야 한다고 볼 수도 있음
    애초에 시니어 중 한 명이 제대로 만들었다면 주니어도 수정할 수 있었어야 함
    만약 그 시니어가 만들었는데도 구조 때문에 어렵고 복잡하다면, 왜 그를 시니어라고 부르는지 의문임
  • 글의 핵심 중 하나는 그 사람이 주니어뿐 아니라 시니어들도 더 잘 일하게 도왔다는 것임
    그래도 모든 시니어의 일이 주니어를 돕는 것만 될 수는 없음

• 요즘 그런 사람이 되기는 힘듦
  모든 게 겉으로 보이는 성과 중심이라 그런 사람은 정리 대상이 되기 쉽고, 직접 겪어봤음
  팀 플레이어, 멘토, 소프트웨어 아키텍트는 점점 밀려나고, 많은 코드를 쏟아내는 코더가 자리를 차지함
  기술 부채 때문에 기능 전달과 유지보수 능력이 시간이 갈수록 떨어져도, 관리자는 실제 출시 기능이나 버그 수와 상관없이 주당 5000줄 넘게 꾸준히 쓰는 개발자를 좋아함
  팀 리드이자 복잡한 프로젝트를 관리해 본 엔지니어로서, 주당 2000줄 넘는 코드를 쓰는 사람은 무섭게 느껴짐
  1년에 10만 줄이 넘는 코드이고, 불필요한 복잡성을 생각해야 함
  같은 기능을 1만 줄로, 버그도 적고 절반의 시간에 구현할 가능성이 높지만 그러면 주당 380줄밖에 안 되어 관리자가 좋아하지 않을 것임
  수천 줄을 뽑아내는 개발자는 프로젝트의 장기 방향을 충분히 깊이 생각하지 않는다고 보는 편이고, 그 코드 대부분은 버려질 코드에 가깝다고 느껴짐

  • 회사와 관리에 따라 다름
    Google은 어느 정도 Tech Lead 역할로 이를 제도화했고, 이 엔지니어는 개인 기여자보다 힘을 배가시키는 사람과 멘토로 행동하길 기대받음
    설계대로 늘 작동하진 않고, 어쩌면 드물게만 작동하며, TL이 사람 조율·계획·사소한 논쟁에 빠져 엔지니어로 일하지 못할 수도 있음
    그래도 역할의 취지는 괜찮음
  • “Negative 2000 Lines of Code”
    https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
  • 그런 사람이 되기 힘들었던 건 예전에도 마찬가지였음
    모든 것을 측정하고 얻을 수 있는 숫자로 행동하려는 발상은 19세기부터 있었음
    관리자들은 그때부터 같은 관행을 반복했고, 결과도 같은 방식으로 꽤 안정적으로 나왔음
  • 가장 슬픈 건 어떤 상사들은 진짜로 버려질 코드를 원한다는 점임
    잠깐 다닌 회사의 오너는 최신 웹 프레임워크와 유행을 따르기 위해 웹 서비스를 6개월마다 처음부터 다시 쓰길 원했음
    주당 5000줄 영웅이라면 그 자리에서 채용했을 것임
  • 커리어의 어떤 시점에는 1년에 수십만 줄도 써봤지만, 오직 새 프로젝트를 할 때였음
    유지보수 프로젝트에서는 혼자 한 줄도 안 쓰고 한 주를 보내기도 하고, 오히려 한 주 내내 코드 줄 수를 줄이는 일을 하기도 함

• 훌륭함
  조정에는 seat racing이라는 훈련이 있어서, 여덟 자리의 여러 조합에 사람을 넣고 빼며 가장 빠른 조합을 찾음
  개인의 힘도 지표가 되지만, 경기용 배에 누가 타는지는 팀 속도가 결정함
  결국 가장 빠른 조합에는 가장 강한 여덟 명이 그대로 들어가는 일이 드물고, 종종 서류상 더 뛰어나 보이지 않아도 어떤 배에 넣어도 더 빠르게 만드는 “마법 같은” 사람이 한두 명 있음
  그들은 다른 사람들의 균형, 리듬, 힘을 미묘하게 개선함
  일부 코치는 이를 기꺼이 받아들이지 않고 저항하며, 결과적으로 승수가 줄어듦
  소프트웨어 팀과도 매우 비슷하고, 결국 중요한 것은 조합과 결과임

• “기술 리더십”을 코칭해 달라는 요청을 받으면 항상 촉진자형 직원을 주의 깊게 보라고 말함
  이들의 도움은 다른 직원을 더 생산적이고 효과적으로 만들며, 어떤 사람들은 놀라운 일을 직접 해내고 모든 공을 가져가는 것보다 남이 훌륭히 해내도록 돕는 데서 더 큰 직업 만족을 얻음
  이런 사람들은 종종 점수가 낮게 나오지만, 잃으면 팀 생산성은 순감소함
  그래서 실제로 생산적이지 않은 사람과, 다른 사람의 성공 속에서 생산성이 드러나는 사람을 구분할 도구를 주려고 함
  하나의 지표만 측정하고 거기에 맞춰 관리하는 건 절대 좋지 않음
  지표를 게임하는 사람이 “승리”하고 그런 행동이 승진으로 이어지기 때문임
  Google 리더십에게도 이 점을 말했지만, Laszlo는 “이게 우리가 가진 시스템이고 완벽하진 않지만 이걸로 갈 것이다. 그 안에서 일하든 말든 선택은 당신 몫이다”라고 했음
  그 회의만으로도 고위 리더십이 더 나은 엔지니어링 환경을 만들려는지 아닌지 충분히 알 수 있었음
  많은 새 관리자, 특히 예전 개인 기여 엔지니어였던 사람들은 “최고” 구성원은 남기고 “나쁜” 구성원은 내보내면 팀 사기와 산출이 모두 좋아질 거라고 생각함
  하지만 그들이 이해한 “최고”는 사람을 관리한 기준이 아니라 예전 자기 일을 잘 해낸 기준에 기반함
  그래서 자기와 비슷한 기술과 습관을 가진 사람을 선호하고, 다른 기술과 습관을 가진 사람을 낮게 보게 됨
  이걸 깨닫게 했을 때 눈이 커지는 순간은 늘 흥미로움

  • 서비스 지향적인 직원만 가득하고 실제로 하는 사람이 없는 조직을 본 적이 있는지 궁금함
    제로 금리 정책은 Jira 보드 관리와 작업 목록을 다루는 시니어 디렉터 같은 역할을 늘리고, 실제 일을 할 수 있는 사람은 부족하게 만들었음
    다른 사람의 생산성을 촉진하는 사람이 있을 수 있다는 생각에 반대하진 않지만, 결국 무언가가 끝나려면 그 “다른 사람들”이 필요함
    그렇지 않으면 조직은 괴사함