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

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

고임팩트 기회

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

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

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

• 시간 의존성

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

여유 있게 유지하기

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

아무것도 하지 않기

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

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

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

• 글루 작업 피하기

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

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

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

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

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

결론

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