일을 맡기고 위임하게 되었을때 혹은 일을 전달하게 되었을 때 내가 원하는 방향과 다르게 나오거나 결과가 다르게 진행되는 경우들이 있다. 그런 케이스를 반추해보면 작업자들에게 문제가 있는 경우도 있었지만 거의 대부분은 나의 디렉션에 문제가 있는 경우들이 많았다.

명확한 디렉션을 주어야 한다.

명확한 디렉션을 주어야 하는것은 나도 느끼고 있었다. 그런데 어려운 점이 2가지가 있었다.

1. 명확한의 경계가 어디까지인가?
   • 자칫 마이크로매니징을 하는 느낌으로 될 수 있어서 스스로 명확한의 경계를 정해야한다고 생각을 했다.
2. 구두로 애기할 때의 문제
   • 대면/구두로 이야기할때 그 명확한 부분의 경계가 말과 표정안에서 뭉게질때가 있다. 예를 들어 어떤 명확한 디렉션을 전달할 때, 예예예, 혹은 알겠다는 듯이 고객을 끄덕이거나 하는 경우가 있다. 물론 잘 되는 경우도 있지만 서로 알겠다는 포인트가 달라서 바라보는 지점이 다른 경우들이 있었다.

첫번째 명확한의 경계에 대해서는 스스로 가이드라인을 세웠다. 작업에 대해서 애기할 때, 컨텍스트, 협업, 산출물, 데드라인 이 4가지를 반드시 넣으려고 하고 있다. 예를 들면

AS-IS : grpc 조사해서 주세요.

TO-BE : 마이크로서비스에서는 서버간 latency를 신경써야 하는데요. grpc 에 대해서 XXX 분이랑 같이 조사해서, 노션문서로, n일에 전달해주세요.

확실히 좀 더 명확해진다. 일을 관리하는 입장에서 모든 일은 어떤식으로든 종결되어야 한다. 결과가 항상 좋아야 한다는게 아니라 중단하더라도 그것도 결과의 일부다. 물론 저것이 끝이 아니다. 작업을 받는 입장에서 어떤 포인트로 조사를 진행해야하는데 더 애기를 하면서 맞춰 나갈수 있고, 더 먼저는 어떤 포인트까지 조사를 해달라는 식으로 명확하게 전달을 하는게 중요하다.

명확한이 중요한 이유는 협업을 같이 많이 했던 분들은 일을 전달할 때 약간의 컨텍스트를 알고 있기 때문에 대충 일을 전달해도 잘 되는 경우들이 있다. 그렇지만 타 팀이나 합류한지 얼마 되지 않은 분들과의 일을 함에 있어서는 이슈가 생기는 경우들이 상대적으로 많았다. 이런 이슈들을 일정 레벨로 낮추려면 늘 처음 일하는 것처럼 명확하게 디렉션을 하는것이 좋다고 생각한다.

추가적인 팀으로 데드라인이 안지켜지는 경우들이 있는데, 그 뒤에 어떤 일정을 잡아서 데드라인이 미뤄지는 것을 막아야 한다. 개발적으로 본다면 프론트엔드 전달일정, QA 시작시점 같은것이 그런것에 해당 할 수 있을것 같다. 단순 조사나 정책에 대한 결정의 경우, 데드라인 시점에 회의를 잡아서 그 산출물을 가지고 논의를 하자고 캘린더에 일정을 만들고 초대를 보내고 있다. 그러면 대체적으로 일정이 지켜지거나 혹은 작업자가 먼저 일정 조정 요청을 한다. 즉, 아무말 없이 당일에 안됐는데요. 라는 말이 나오는 상황은 없어진다.

두번째는 대면에서의 어려움인데, 2가지 전략을 사용하고 있다. 하나는 대면에서도 동일하게 명확한 디렉션을 주는것. 다른 하나는 대면에서는 나중에 다시 알려주겠다고 하고 슬랙이나, 문서를 통해서 디렉션을 주는 것이다. 대면에서의 상황은 굉장히 다양하다. 예를 들면, 화장실에서 마주칠 수도 있고, 면접 참여 전에 사내 까페테리아에서 애기를 하게 될 수도 있다. 이런 경우 굉장히 급박하게 이야기하게 되고 원래 애기해야하는 부분을 놓칠 수가 있다. 그리고 말 보다는 글로 전달할때, 좀더 쓰면서 생각하게 되고, 정돈이 된다. 그래서 이런 경우 일단 나중에 전략을 쓰고 슬랙이나 문서를 통해서 전달한다.

--

디렉션에 대한 이슈를 마주하면서 느낀점은 작업자들은 두루뭉실한 디렉션보다는 명확한 디렉션을 선호한다는 것이다. 그렇지만 겉으로는 명확한 디렉션은 이거이거이거 해야한다 라는 약간의 마이크로매니징적으로 느낄 수 있기 때문에 그 자리에서는 불편한 기색을 보이는 경우도 있다. 하지만 최종 작업 결과물을 서로 마주했을 때 불편하지 않으려면 명확하게 디렉션을 해야하고, 그것이 우리가 일을 하는데 서로 일을 잘 하기 위함이라는 것을 상기시켜야 한다.