직장에서 아무것도 하지 않기

 (seangoedecke.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 소프트웨어 엔지니어의 성과는 더 많은 시간·코드보다 적절한 시점의 고임팩트 작업에 좌우되며, 평소에는 하루 업무의 약 20%를 컴퓨터에서 떨어져 보내는 80% 활용이 유효함
  • 대형 엔지니어링 조직에서는 큰 계약 지원, 사고 완화, 주요 기능 출시처럼 시간 의존적 기회가 큰 가치를 만들 수 있으며, 이미 바쁘면 이런 기회를 놓치기 쉬움
  • 낮은 우선순위 티켓을 계속 처리하면 다른 팀의 상황, 팀 업데이트, 진행 중인 사고를 보지 못하고, 매니저도 여유 있는 사람으로 판단하기 어려움
  • 아무것도 하지 않는 시간은 스트레스 회복, 사고 대응 중 침착함, 새 아이디어, 중요한 작업에 대한 집중력을 가능하게 함
  • 평소에는 의도적으로 여력을 남기고, 보상이 매우 큰 시기에만 100% 강도로 몰입하는 방식이 고성과 엔지니어가 되기 더 쉬운 조건을 만듦

고임팩트 기회

  • 많은 엔지니어는 더 적게 일해야 하며, 이는 코드나 변경량을 줄이라는 뜻이 아니라 하루 중 실제로 일하는 시간을 줄이고 일할 때도 더 느린 속도로 일하라는 뜻임
  • 기본 상태에서는 80% 활용률을 목표로 하며, 고압 프로젝트가 없을 때는 업무 시간의 20%를 컴퓨터에서 떨어져 보냄
  • 기술 회사의 성과는 이례적 사건에 크게 좌우되며, 가장 큰 영향을 만든 변경 중 다수는 놀라울 만큼 적은 작업량으로 이루어질 수 있음
  • 소프트웨어 개발에는 노력 자체에 점수가 없고, 중요한 것은 적절한 문제를 적절한 시점에 해결하는 것임

  • 대형 조직에서 가능한 세 가지 사례

    • 큰 엔터프라이즈 계약을 체결하려는 순간에 기능이나 버그 수정을 지원하면 계약 성사에 도움이 될 수 있음
    • 기능이 반드시 훌륭할 필요는 없으며, 구체적 변경을 만들 의지와 능력을 보여주는 것만으로 충분한 경우가 있음
    • 사고를 초기에 예방하거나 완화하면 사고 중 즉각적인 매출 손실과 이후 고객 이탈 또는 계약 거부로 인한 매출 손실을 줄일 수 있음
    • 올바른 기능 플래그를 꺼야 한다는 사실을 아는 것만으로도 큰 금액을 아낄 수 있음
    • 회사가 중요한 기능을 출시하려 할 때 성공과 실패는 사소하지만 찾기 어려운 변경에 달릴 수 있음
    • 사용자 설정에 새 필드를 빠르게 추가하거나, 몇 년 동안 손대지 않은 낡은 엔터프라이즈 데이터 내보내기 기능을 고치는 일이 예시임
    • 시스템 친숙도는 몇 시간이 걸릴 변경과 일주일이 걸릴 변경의 차이를 만들 수 있음

  • 시간 의존성

    • 이런 기회는 모두 시간 의존적이며, 아침에 로그인한 뒤 임의로 큰 계약을 풀거나 사고를 완화하거나 주요 기능을 빠르게 만들 수 없음
    • 적절한 장소와 시점에 있는 것만으로는 충분하지 않고, 이미 바쁘지 않은 상태여야 함

여유 있게 유지하기

  • 낮은 우선순위 작업을 계속 처리하며 100% 활용 상태를 유지하면 고임팩트 작업 기회를 두 가지 방식으로 놓치게 됨
  • 첫째, 너무 바쁘면 기회 자체를 알아차리지 못함
    • 다른 일을 하는 사람들과 대화하거나, 팀 업데이트를 읽거나, 진행 중인 사고를 살펴볼 시간이 줄어듦
    • 고임팩트 작업에 참여하는 가장 좋은 방법은 자신의 전문성을 자원하는 것임
  • 둘째, 항상 바빠 보이면 매니저가 대신 참여시켜 주기 어려움
    • 매니저나 제품 매니저가 “여기 도울 여유가 있다”고 판단해 연결해 주는 방식이 두 번째로 좋은 참여 경로임
    • 매니저와 제품 매니저는 엔지니어가 참석하지 않는 회의에 들어가기 때문에 어떤 고임팩트 작업이 진행 중인지 더 잘 파악하는 경우가 많음

아무것도 하지 않기

  • 고임팩트 작업을 위해 시간을 비워야 하고 티켓 처리만 계속하면 안 된다면, 분 단위로는 실제로 아무것도 하지 않아도 됨
  • 소프트웨어 엔지니어링은 스트레스가 큰 직업일 수 있지만, 보통 지속적으로 스트레스가 큰 직업은 아님
    • 스트레스는 가끔 발생하는 사고, 긴급한 고압 작업, 최근의 해고 같은 상황에서 발생함
  • 상대적으로 압박이 낮은 업무 구간까지 긴급한 강도로 접근하면, 고압 상황을 처리해야 할 때 이미 지치고 예민한 상태가 됨
  • 고압 업무 구간에서도 아무것도 하지 않는 태도는 도움이 될 수 있음
    • 온콜에 익숙하지 않은 엔지니어는 서두르지 말고, 통화에 들어가기 전이나 말하기 전에 몇 번 숨을 고르는 편이 좋음
    • 사고 대응에서는 전반적으로 “느린 동작으로 생각하기”가 필요함
  • 대부분의 사고는 저절로 해결되며, 사고 중 급하게 넣는 “도움이 될지도 모르는” 변경은 상황을 좋게 만들기보다 나쁘게 만드는 경우가 많음
  • 일반적으로 패닉을 피하기만 해도 사고 대응에서는 대부분의 엔지니어보다 더 잘하고 있는 상태가 됨
  • 아무것도 하지 않는 시간은 일이 일어날 수 있는 공간이 됨
    • 뇌가 쉴 기회를 얻으면 새 아이디어가 떠오를 가능성이 커짐
    • 중요한 작업을 받았을 때 뒤에서 진행 중인 세 가지 일을 동시에 처리하지 않고 온전히 집중할 수 있음
    • 바쁘지 않을 때는 그냥 사물을 보고 새 데이터를 받아들일 시간이 생김

특정 일을 의도적으로 하지 않기

  • 많은 엔지니어는 해야 할 일이 보이는데도 하지 않는 상황을 불편해함
  • 이런 성향은 많은 소프트웨어 엔지니어가 공유하는 심리적 특징이며, 어느 정도까지는 이 직무에 잘 맞게 만드는 요소임
  • 아무것도 하지 않는 시간을 만들려면 때로는 일부러 끼어들지 않도록 스스로를 강제해야 함

  • 글루 작업 피하기

    • 엔지니어는 일반적으로 글루 작업을 피해야 함
    • 글루 작업은 사람들이 서로 대화하게 만들기, 자신이 리드하지 않는 작업의 문서 업데이트, 기술 부채 해결 자원 등을 가리킴
    • 대부분의 글루 작업은 조직이 그 일을 명시적으로 우선순위에 두지 않았다는 사실을 반영함
    • 조직이 우선순위로 두고 있다면 개인이 자원할 필요가 없음
    • 조직이 우선순위에 두지 않은 것이 괜찮은 일이라면, 그 일을 맡는 것은 시간 낭비이며 매니저를 성가시게 할 수 있음
    • 조직이 우선순위에 두지 않은 것이 큰 실수라 해도, 개인이 대신 처리하면 회사가 자기 실수의 결과를 겪지 않게 되고 개인의 커리어와 정신적 안녕이 비용을 치르게 됨
    • 이는 개인에게도 나쁜 거래이고, 주니어 동료에게도 나쁜 예가 되며, 번아웃 이후 다른 누군가가 같은 위치에 들어가는 나쁜 선례가 됨
    • 결과가 정말 심각하다면 조직이 고통을 느끼고 정책을 바꿀 수 있도록 결과가 발생하게 두어야 함

  • 과도한 도움은 취약성을 만듦

    • 너무 도움이 되려는 태도는 무보상 노동을 끌어내려는 사람들에게 취약하게 만듦
    • 기술 회사에는 소프트웨어 엔지니어에게 보상되지 않는 일을 뽑아내려는 사람들이 많음
    • 정상 경로로 들어오고 승진, 보너스, 일반 급여로 보상되는 업무와는 다름
    • 문제 되는 업무는 비공식 경로로 들어오며, 그 일을 공식적으로 본인 이름 아래 기록할 능력이나 의지가 없는 사람에게서 옴
    • 다른 조직의 제품 매니저가 데이터 질의를 잘한다며 특정 통계를 뽑아 달라고 요청하는 경우가 예시임
    • 다른 팀 엔지니어가 페어 작업을 요청하지만 실제로는 모든 코드를 작성하게 만들고 변경은 자기 이름으로 제출하는 경우가 예시임
    • 이런 종류의 일을 어느 정도 하는 것은 괜찮으며, 가능할 때 사람을 도와도 됨
    • 다만 거절하거나 몇 시간 또는 며칠 늦게 답하는 방식으로 역압력을 걸 수 있어야 함

  • 사라질 가능성이 큰 일에 과투자하지 않기

    • 사라질 가능성이 큰 일에는 너무 많이 투자하지 않는 편이 좋음
    • 제품 디자이너가 원하는 것을 실시간으로 정리하는 상황에서는 매시간 페이지를 완전히 다시 쓰면 안 됨
    • 오전 9시에 페이지 헤더를 한 방식으로 원하고, 10시에 수정하고, 11시에 다시 바꾸는 흐름이 예시임
    • 이런 경우 산책을 가는 등 아무것도 하지 않다가, 오후에 가장 최신 디자인을 기준으로 한 번 다시 쓰는 편이 나음
    • 정치적 추진력이 부족한 매니저의 큰 아이디어도 흔한 사례임
    • 프로젝트가 취소될 때까지 시간을 흘려보낼 수 있는 경우가 많음
    • 다만 프로젝트의 정치적 지지 수준을 잘못 판단하면 게으른 사람처럼 보이고 급하게 결과를 내야 하는 상황이 될 수 있음

결론

  • 소프트웨어 엔지니어링 조언과 도구는 동시에 더 많은 일을 하고, 더 큰 범위의 프로젝트를 맡고, 더 많은 코드를 쓰도록 기술적 노력을 확장하는 능력에 맞춰져 있는 경우가 많음
  • 소프트웨어 엔지니어링 성공은 그런 요소들로 결정되지 않음
  • 성공은 올바른 일을 올바른 시점에 하는 능력으로 결정되며, 이를 위해서는 일상 업무에서 의도적으로 일부 노력을 남겨두어야 함
  • 80% 노력으로도 고성과 엔지니어가 되는 것은 가능하며, 오히려 스트레스에서 오는 어리석은 실수를 줄이고 큰 수익을 만드는 고임팩트 작업에 뛰어들기 쉬워짐
  • 100% 노력으로 몰입해야 하는 시기도 있으며, 1년에 두세 번 정도는 긴 시간, 강한 집중, 하루 종일 문제를 생각하는 방식으로 일할 수 있음
  • 이런 업무 방식은 보상이 정말 클 때를 위해 남겨두고, 나머지 기간에는 비교적 여유 있게 일하는 편이 좋음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 좋은 글이지만, 결국 또 인센티브가 문제로 드러남
    사고를 일찍 막거나 완화하면 큰돈을 아낄 수 있다는 말은 맞지만, 여러 회사에서 반복해서 본 건 문제 예방은 인정받지 못하고, 불쏘시개를 잔뜩 쌓아놓은 뒤 필연적인 화재를 끄면 두 번 인정받는다는 점임. “좋은” 조직에서도 그랬음
    의도적으로 쓰레기 코드를 빨리 내보내고 그 공을 챙기는 게임 이론식 정치에는 끝내 몰입하지 못했음. 내 작업에 자부심이 너무 컸기 때문임
    지난 제품 버전을 괴롭히던 문제군을 없애기 위한 프레임워크를 5년 넘게 관리하고 키웠지만, 쓰레기 코드를 배포해 장애를 만들고 고친 파트너 팀은 공개적으로 칭찬받고, 우리 팀은 그런 장애가 없었다는 이유로 아무 공도 못 받았음. 측정할 수 없는 예방이기 때문임

    • 게임 이론상으로는 반복적으로 문제를 일으켜 고객을 잃는 팀이 그에 맞게 처벌받아야 함. 그렇지 않다면 빠른 배포로 생기는 문제가 생각만큼 고객 유지율에 영향을 주지 않는 것일 수도 있음
    • 여기저기 Thread.sleep(100000)을 넣어두고 깨질 때까지 기다리면 됨. 그러면 릴리스 후 금요일 자정까지 길고 용감하게 화재 진압을 한 사람이 됨
      왜 보상받는지는 묻지 말아야 하고, 물론 가끔은 조직이 보상 기준을 다른 것으로 바꾸기도 함
    • “그런 장애가 없었다는 공은 측정할 수 없어서 못 받는다”는 말에 대해, 철학적으로는 무의 무게도 측정할 수 있다고 봄
    • 안타깝게도 완전히 맞는 말이지만, 유일한 방법은 아님
      정직한 접근으로는 복잡하지만 필수적인 도구를 몇 개 만들어서 다른 엔지니어들이 계속 나를 찾아오게 만드는 방법이 있음. 특정 도구의 오용을 잘 찾아내게 되고, 남의 코드 버그를 몇 초 만에 짚어내면 실제보다 훨씬 똑똑해 보임
      이상적으로는 도구가 신뢰 가능하고 유용하지만 복잡해야 함. 다른 개발자들이 도구를 쓰다 버그를 만나면 계속 찾아오고, 나는 그들의 실수를 짚어줄 수 있음. 이 전략이 작동하려면 실수는 거의 항상 상대 쪽에 있어야 하고, 내 코드는 견고해야 함
      내 코드에서 진짜 버그, 가능하면 작은 경계 사례가 발견되면 매우 겸손하고 미안해해야 하며, 팀 회의에서 그 복잡한 버그를 찾아낸 개발자를 칭찬해야 함
      자기 버그 코드를 고쳐서 공을 얻는 방식보다 낫다. 그건 관리자나 주니어에게는 통할 수 있지만 다른 시니어 엔지니어들은 싫어하게 됨
      복잡하지만 안정적인 도구를 만드는 방식은 반복해서, 종종 두 번보다 훨씬 많이 인정받게 해주고, 다른 개발자들의 인정은 결국 관리자 귀에도 들어감. 똑똑한 리더는 화려한 데모보다 이 신호가 더 낫다는 걸 앎
      특정 개발자가 빠르게 프로토타입을 만든다는 이유만으로 칭찬을 퍼주는 리더들은 결국 실수를 배우게 됨. 젊은 창업자들은 피상적인 것을 칭찬하는 이 단계를 자주 거치는 듯함
    • 그렇게 대립 구도를 잡는다면 동의하지만, 약간의 뉘앙스는 필요함
      제품이나 기능 묶음을 만드는 일의 일부는 훌륭한 엔지니어링보다 탐색에 가까움. 때로는 단단한 기능 하나를 만드는 것보다, 사용자에게 가치 있는 것이 무엇인지 알아내기 위해 충분히 괜찮은 기능 두 개를 만드는 편이 나음
      나는 늘 “일단 해보고 알아보자” 쪽이었음. 다만 나와 다른 태도의 누군가가 git을 만들어준 건 고맙게 생각함
      여기에는 균형이 있고, 지금 다루는 문제가 얼마나 탐색 문제인지에 따라 달라짐. 여기서 “단단함”은 순수 엔지니어링 관점의 가용성, 유지보수성, 사용자의 민감한 사진 유출 가능성 같은 뜻임

  • “보상 없는 일을 뽑아먹으려는 사람들”에 대한 부분은 액자에 넣어둘 만함
    특히 다른 조직의 제품 관리자가 “데이터 쿼리를 잘하시니 X에 대한 통계 좀 뽑아주실 수 있나요?”라고 하거나, 다른 팀 엔지니어가 “페어”를 요청해놓고 결국 내가 코드를 다 쓰고 자기 이름으로 조용히 변경을 제출하는 상황 같은 것임

    • 내가 일하는 곳에서 Principal Engineer는 모두가 원하고 보상도 좋지만 드물게 도달하는 직함임. 함께 일해본 사람들은 모두 매우 유능하고 인간적으로도 좋았는데, 그중 한 명에게 이전 회사에서 어떻게 그 직함을 얻었는지 물어본 적이 있음
      그의 전략은 사람들을 돕고 공을 적극적으로 넘겨주는 것이었음. 1:1이나 여러 단계의 관리자가 있는 회의에서 팀원들의 작업 가치를 꾸준히 강조했고, 그 덕분에 팀의 호감을 얻었음
      몇 년 뒤 큰돈이 걸린 프로젝트가 일정에서 밀리고 핵심 엔지니어 여럿이 퇴사했을 때, 그는 야근을 해가며 프로젝트를 성공으로 이끌었고 다음 평가에서 직함과 연봉 인상을 받았음
      그 프로젝트가 마지막 밀어붙임이 되긴 했지만, 야근한 엔지니어가 그 혼자였던 건 아님. 그는 자신의 승진을 재직 기간 동안 타인에게 공을 돌리며 쌓은 호의 덕분으로 봄
    • 이건 상사가 얼마나 관여하는지에 따라 다르다고 봄. 같이 일하고 싶지 않은 유형 중 하나가 “그건 제 일이 아닌데요” 하는 사람임
      직무 기술서에 있든 없든 문제를 보고 해결책을 제안하는 사람들과 일하고 싶음
      내 일이 인정받지 못한다면 그건 리더십 문제임. 일을 딱 잘라 거절하는 방식은 굳어버린 느린 조직 문화로 가는 길처럼 느껴짐
    • 액자에 넣어둘 말은 “티켓으로 만들어주세요”임
    • 맞는 말이지만 그렇게 흑백으로만 보이지는 않음. 내 보상을 직접 챙기는 것 이상으로, 회사 자체가 성공하도록 돕는 데도 인센티브가 있으니, 퍼레이드까지는 못 받아도 작은 요청을 도와주는 게 합리적일 수 있음
      마찬가지로 언젠가 나도 동료에게 뭔가 필요할 수 있고, 그때 “정식 채널로 오세요”라며 쫓겨나는 것보다 적극적으로 도와주면 고마울 것임. 정식 채널은 훨씬 오래 걸릴 수도 있음
    • 좋은 회사에는 문화가 있고, 사람들은 서로 돕는다
      점심자리 대화가 사람들이 무언가를 이해하는 데 도움을 주는 식임
      다만 누군가를 위해 몇 시간짜리 일을 해주는 건 또 다른 문제일 수 있음

  • 비꼬려는 건 아니고 관찰에 가깝지만, 충분히 크거나 관료적인 조직에서는 사고를 미리 막아도 공이나 가시성을 얻기 어렵다. 그런 성과는 “원래 해야 하는 일”로 들어감
    그래서 회사 정치에 능한 사람들은 차라리 사고가 나게 두고, 후속 조치 항목에서 요란하게 움직이는 쪽을 택함. 요령은 사고를 재앙으로 키우지 않는 것이고, 꽤 섬세한 작업임

    • 보수적인 조직에서 일찍 배웠음. 예방은 위험함. 일이 잘못됐을 때 쓸 해결책을 준비해두는 편이 낫고, 그때가 되어야 승인을 받을 수 있음
    • 큰 영향을 준다는 예시들이 전부 인정받기 어려운 일처럼 보임
      영업 계약을 살리면 박수는 영업팀이 받고, 수수료도 그들이 받음. 나는 그 일부도 받지 못함
    • 재난은 상부에 조직에 문제가 있다는 좋은 신호가 되기도 함. 모든 불을 영웅적으로 꺼버리면 상사는 알 수도 있지만, 상사의 상사의 상사는 조직이 아주 잘 돌아가고 모두 녹색 상태라고 봄
      몇 가지가 타버리게 두면 상사의 상사의 상사가 그 불을 보게 되고, 개선될 수도 있음. 어쩌면 그들과 소통하는 가장 쉬운 방법임
    • 사람들이 알아차리는지가 핵심임. 지방정부에서는 인기 있는 프로그램을 잘라서 반발을 유도한 뒤, 다시 복원한 공을 가져가기도 한다고 들었음. 그 사이 필요하지만 인기 없는 다른 조치를 끼워 넣을 수도 있음
    • 영웅놀이로 경력이 만들어지고 보너스가 지급되는 경우가 많음

  • 예전부터 이 방향의 글을 반쯤 써둔 적이 있는데, 판타지 RPG 비유를 썼음. 이런 게임에서 마나를 쓰는 캐릭터를 하면, 사소한 전투마다 마나를 다 써버리고 빈 상태로 돌아다니다가 진짜 필요할 때 아무것도 남지 않는다는 걸 금방 배우게 됨
    일에서 쓰는 정신적 에너지도 크게 다르지 않음. 탱크에 조금 남겨두면 예상치 못한 일이 생겼을 때 건강, 즉 번아웃을 위험에 빠뜨리지 않고 전략적으로 쓸 수 있음
    이런 게임에서 마나 관리를 못 하는 플레이어와 파티를 맺어보면, 그 사람이 그다지 좋은 팀원이 아니라는 것도 알게 됨

    • 한동안 충분히 도전받지 못하면 다음 도전을 넘어서기가 극도로 어려워질 수 있다는 걸 느꼈음
      어떤 분야든 내 능력이 정점이던 때는 앞에 충분한 일이 있어서 기계처럼 꾸준히 처리할 수 있고, 목표를 향해 방해받지 않고 일할 만큼 신뢰받아 계속 설명하느라 멈추지 않아도 됐을 때였음. 기술은 들불처럼 늘고 작업은 예상보다 빨리 끝났음
      안타깝게도 그런 구조를 활용하는 직장은 아주 드묾. 실제 깊은 작업에 들어가지 못하게 하는 차단 요소와 방해가 너무 많음
    • 나 같은 경우라면 RPG를 끝낼 때 에테르 29개가 남아 있고, 초반에 썼다면 훨씬 덜 노가다였을 것임

  • 시스템을 무너뜨리고 싶다면 기준 운용을 100% 로 돌리면 됨. 여유가 없고 새 수요를 받아낼 용량도 없으니, 시스템에 작은 교란만 생겨도 상시 실패 모드로 돌아가는 셈임

    • 효율성은 회복탄력성의 적임
    • 다만 붕괴는 일어나지 않음. 엔지니어들이 번아웃되거나 나이가 들면 그냥 새 인력을 뽑고, 사이클은 반복됨
      이런 글이나 Peopleware / Slack 같은 책의 문제는, 회계 담당자들이 다른 접근을 시도해볼 만큼 설득력 있는 실제 지표를 제시하지 않는다는 데 있음

  • 관점을 바꿔준 비유는 “The Power of Full Engagement”에서 나온 말이었음. 대략 “너는 비시즌이 없는 세계 정상급 지구력 선수처럼 행동하고 있다. 그만둬라”라는 내용임

  • 여기에 많은 지혜가 있음. 진짜 가치가 큰 일이 왔을 때를 위해 일부 용량을 남겨두는 것에 더해, 소프트웨어 엔지니어링은 계속 바쁘기만 해서는 잘할 수 있는 일이 아니라고 봄
    최대한 빨리 코드를 쓰려 하면 좋은 설계가 나오는 경우가 드묾. 이 글은 또 다른 중요한 측면, 즉 관리자에게 혼나지 않고 80% 용량으로 일하는 방법은 다루지 않음
    여기에는 커뮤니케이션과 작업 추정에 약간의 주의가 필요함. 첫 진짜 프로그래밍 직장에서 나이 많은 숙련 개발자들에게 들은 좋은 조언 중 하나가 지금까지 남아 있음. 어떤 일이 얼마나 걸릴지 추정한 뒤, 관리자나 사용자에게 말하기 전에는 두 배로 늘리라는 것임
    경험이 쌓이면 그 비율은 2배가 아니라 1.5배쯤으로 내려올 수 있지만, 원칙은 여전히 적용됨

    • Kent Beck이 Good News Factory였는지 강연이었는지에서, 자기 팀은 할 수 있다고 생각하는 양의 절반 이상은 절대 약속하지 않았다고 했음. 지속 가능성에 좋은 방식임
      최적화하고 선례로 삼아야 할 것은 장기적으로 꾸준히, 지속 가능한 속도로 전달한다는 점임. 긴 게임이고, 과도한 약속은 신뢰를 깎아먹을 뿐임. 그 신뢰야말로 개발자가 필요한 공간을 얻는 가장 큰 수단임
      적게 약속하고, 말한 것은 해낸다는 신뢰를 만들고, 번아웃되지 않을 공간을 얻어야 함
      시니어가 될수록, 특히 리드가 될수록 경계 설정과 주의력 보존, 번아웃 방지가 일이 됨. 스스로를 망가뜨리는 방법이 너무 많기 때문임
    • “걸릴 시간 추정치에 두 배를 더해 관리자나 사용자에게 말하라”는 말은 맞지만, 호프스태터의 법칙은 고려했는지 궁금함
      호프스태터의 법칙을 고려하더라도, 일은 항상 예상보다 오래 걸림
      https://en.wikipedia.org/wiki/Hofstadter%27s_law

  • 고객 접점 업무를 많이 해본 입장에서, 여러 번 마주친 최악의 함정은 돈을 내는 고객과 친해지는 일이었음. 전문가로 고용되어 도와주는 입장에서, 고객이 정말 괜찮은 사람일 때는 거절이 미친 듯이 어려워짐
    더 나쁜 건 그 사람이 의사결정자가 아니라, 나에게 무언가를 밀어붙이도록 강요받는 입장일 때임. 신뢰받는 전문가로서 고객 본인이 나쁜 아이디어를 낼 때는 거절하기 쉽지만, 한 번도 직접 상대하지 않는 그들의 상사가 지시를 내리면 나는 쓸모없는 비용처럼 보이거나, 괴물을 남기고 가는 예스맨이 되는 위치에 놓임
    주로 내부 업무를 해온 사람들이 가끔 부러움. 적어도 위쪽 어딘가의 누군가를 설득해볼 수는 있었을 테니까

  • 글루 작업에 대한 부분이 흥미로운데, 대기업에서 일할 때 이것은 연간 성과 평가의 명시적 일부였음. Google은 이를 “citizenship”이라고 불렀고, 본질을 잘 잡은 표현이라고 봄. 즉 “회사 나머지 사람들을 위해 무엇을 더 낫게 만들었는가”였음
    한편으로는 좀 이상하긴 했음. 내 직무 기술서에 없었으니 기술적으로는 무보수 작업이었지만, 동시에 공식 기대사항의 일부였음. 다른 한편으로는 모두가 시간과 노력을 조금씩 써서 모두를 위해 환경을 개선하는 곳에서 일하는 게 좋았음
    모두에게 명시적 요구사항으로 만들면 “나는 록스타 엔지니어라 중요한 일을 하느라 바쁘니 글루 작업은 다른 사람이 하라”는 독성 문화를 우회하려는 시도도 됨. 게다가 그 “다른 사람”은 보통 여성이었고, 거의 확실히 그 록스타 엔지니어보다 적게 받고 있었음
    원글은 회사가 글루 작업을 할 사람을 정식으로 고용해야 한다는 함의를 주지만, 실제로는 너무 다양한 조각으로 이루어져 있어서 한 사람을 뽑아 맡기기 거의 불가능함. 예를 들어 “문서 작성, 소프트웨어 엔지니어 면접, 팀 오프사이트 행사 조직”을 모두 포괄하는 직함이 무엇이겠음
    하지만 그런 작업은 모두 필요했고, citizenship 요구사항은 부담을 더 공정하게 나눌 수 있게 해줬음
    더 나은 표현은 “글루 작업을 하지 말라”가 아니라 “보상 없는 글루 작업을 하는 유일한 호구가 되지 말라”라고 봄. 즉 모두가 일부를 맡고, 그것이 공식적으로 일로 인정되는 문화를 밀어야 함

  • 80% 활용률로 운영하는 건 좋은 습관이고, 매일 하루 종일 100%를 요구하는 감독관식 관리자가 없을 때 도움이 됨. 그런 사람들은 소프트웨어 엔지니어가 조용하고 편안하게 생각하는 모습을 게으른 무위로 오해함
    그래서 원격근무는 일부 활용률을 예비로 남기고 정신 건강을 지키는 데 가장 좋은 방식임
    약간의 글루 작업은 모두의 업무 생활을 훨씬 낫게 만들고 아무도 그 방법을 모른다면, 팀에서 나를 필수 인력이나 영웅으로 만들어줄 수 있음

    • 80%도 높다고 봄. 그리고 개발자마다 다름
      내가 배우고 생각하고 시작하는 데 애를 먹는 방식을 감안하면, 내 80%는 기술적으로 더 강한 동료의 80%와 전혀 같지 않음
      신경다양성 성향까지 조금이라도 고려하면, 한 사람의 80은 다른 사람의 120일 수 있음
답변달기