"주도적으로 일해 달라"는 말에는 무엇이 빠져 있을까
작은 회사를 운영하며 주도성을 요구할 때마다 되돌아오는 질문이 있다. 나는 무엇을 맡겼고, 어디까지 결정하게 했고, 기준을 처음부터 설명했는가. 주도적으로 일할 수 있는 조건 네 가지와 리더가 먼저 해야 할 일을 정리했다.
작은 회사를 운영하면서 자주 생각하는 단어가 주도성이다. 할 일을 기다리지 않고 필요한 문제를 발견하는 사람, 맡은 일을 끝까지 연결하는 사람과 일하고 싶다. 팀이 커져도 모든 판단이 대표를 거쳐야 한다면 할 수 있는 일에는 금방 한계가 생긴다.
근데 주도성을 기대할수록 대표에게 되돌아오는 질문이 있다. 나는 무엇을 맡겼고, 어디까지 결정할 수 있게 했는가. 결과가 기대와 달랐을 때 적용한 기준을 처음부터 설명했는가. "주도적으로 일해 달라"는 문장에는 이 앞부분이 자주 빠져 있다.
"이 페이지를 개선해 주세요"는 왜 충분한 요청이 아닌가?
같은 요청이 두 개의 다른 결과물을 만들 수 있기 때문이다. "이 페이지를 개선해 주세요"는 디자인을 더 깔끔하게 하라는 뜻일 수도 있고, 사용자가 승인할 대상을 더 빨리 찾게 하라는 뜻일 수도 있다. 두 목표는 다른 화면을 만든다. 요청한 사람의 머릿속에는 두 번째가 있었는데 첫 번째 결과가 나왔다면, 그 차이를 전부 담당자의 이해력으로 설명하기는 어렵다.
이 장면을 겪고 나서 제품 화면을 정리할 때 순서를 바꿨다. 페이지마다 사용자가 들어오는 이유, 그 화면에서 가장 중요한 질문, 기대하는 행동을 먼저 적는다. "이 화면을 잘 만들어 주세요"보다 "사용자가 이번 배포의 준비 상태를 확인하고 승인 여부를 결정할 수 있어야 합니다"가 판단의 기준을 훨씬 많이 준다. 화면을 만드는 사람은 이 문장 하나로 무엇을 크게 보여주고 무엇을 접어둘지 스스로 정할 수 있다.
주도적으로 일할 수 있는 조건은 무엇인가?
네 가지가 공유되어야 한다. 풀어야 할 문제, 선택할 수 있는 범위, 결과를 확인할 기준, 막혔을 때 도움을 요청할 경로다. 이 정도가 있어야 담당자가 스스로 선택하고, 그 선택을 다른 사람에게 설명할 수 있다.
넷 중 가장 자주 빠지는 건 두 번째다. 선택의 범위.
구조와 문구는 바꿀 수 있지만 권한 정책은 함께 검토해야 하는지. 일정과 구현 범위 중 무엇을 조정할 수 있는지. 사소해 보이는 경계가 모호하면 사람은 결정을 미루거나, 결정했다가 되돌리는 일을 겪는다. 경계를 말로 정해두는 데는 5분이 걸리고, 경계가 없어서 생기는 재작업은 며칠이 걸린다.
우선순위가 바뀔 때 리더는 무엇을 설명해야 하나?
무엇이 달라졌고, 이전 판단의 어떤 전제가 바뀌었는지다. 고객에게 새 정보를 얻어 우선순위를 조정하는 일은 작은 회사에서 필요하고 자연스럽다. 문제는 조정 자체가 아니라 설명이 생략되는 것이다. 새로운 정보 때문에 바뀐 기준을 처음부터 당연했던 것처럼 적용하면, 담당자는 다음에도 숨은 기준이 있을 거라고 예상하게 된다. 그 순간부터 사람은 판단하는 대신 눈치를 보기 시작한다.
그래서 문서도 길이보다 판단에 필요한 내용이 중요하다고 본다. 지금 해결하는 문제, 이번 범위, 완료 기준, 아직 결정되지 않은 질문. 모든 것을 미리 확정하려는 목적이 아니다. 담당자가 이미 정해진 부분을 추측하느라 시간을 쓰지 않고, 자신이 판단할 부분에 집중하게 하는 것이다.
자율성에는 어떤 책임이 따르는가?
결과에 대한 설명까지다. 목표를 설명하고 권한을 줬다고 모든 문제가 풀리지는 않는다. 담당자에게는 진행 상황을 공유하고, 약속한 결과를 검증하고, 위험을 일찍 알릴 책임이 있다. 필요한 역량을 갖추거나 배우는 일도 그 안에 들어간다. 자율성은 마음대로 하는 것이 아니라, 판단의 근거를 남기며 일하는 것이다.
이때 리더가 만들고 싶은 습관도 분명해야 한다. 문제가 커진 뒤 완성된 답을 가져오는 사람만 인정하면, 불확실성을 일찍 드러내는 일이 손해가 된다. 아직 답을 몰라도 영향과 선택지를 정리해 가져오면 함께 판단할 수 있다는 경험을 팀에 만들어야 한다. 그래야 주도성과 협업이 같은 방향으로 움직인다.
제품의 여러 부분을 동시에 보는 사람은 머릿속 맥락을 충분히 전달하지 않은 채 결과를 기대하기 쉽다. 그래서 팀에 주도성을 요구하는 문장을 먼저 나에게 돌려본다. 이 사람이 판단할 수 있도록 내가 제공해야 할 것은 무엇인가. 문제, 범위, 기준, 경로. 이 넷이 적혀 있는지 확인한 뒤에 요청을 보낸다.
내가 만들고 싶은 조직에서는 담당자가 대표의 취향을 맞히는 데 능숙해질 필요가 없다. 고객 문제를 이해하고, 공유된 기준 안에서 판단하고, 결과를 함께 검토하는 경험을 쌓으면 된다. 주도적으로 일해 달라는 말은 그 조건을 만드는 일과 함께 갈 때만 온전한 문장이 된다.
비슷한 글
구글을 나온 뒤, "일을 잘한다"는 기준이 달라졌다
세일즈포스와 구글에서 소프트웨어 엔지니어로 일하다 2024년 7월 창업했다. 코드를 잘 짜는 기준은 그대로인데, 그 앞에 놓인 질문이 내 책임이 됐다. 어떤 고객의 문제를 왜 지금 푸는가. 엔지니어에서 창업자로 넘어오며 바뀐 "좋은 일"의 기준을 적었다.
백재민
시니어를 더 뽑으면, 팀은 정말 빨라질까
경력 많은 엔지니어를 채용하면 팀이 빨라질 거라는 기대는 자연스럽다. 근데 채용 전에 확인할 것이 있다. 일이 느린 이유를 어떤 장면으로 설명할 수 있는가. 작업 시간과 경과 시간의 구분, 기대하는 결과를 적는 법, 시니어의 성과를 보는 기준을 정리했다.
백재민
한국에는 PC방이 있었다. 개발자에게는 어떤 환경이 필요할까
유학 시절 스타크래프트에서 한국인이라는 말 한마디가 만들던 기대에서 시작한 질문이다. 실력은 어디에서 만들어지는가. PC방이 보여준 연습과 피드백의 반복을 개발자의 하루로 옮기면, 변경 뒤에 무엇이 일어나는지 보이는 환경이 된다.
백재민