choasin blog

우리는 누군가와 함께 일을 합니다. 혼자서 일하는 경우란 애초부터 존재하지 않습니다. 1인 기업도, 1인 NGO도, 프리랜서도 사실 혼자서 일하지 않습니다. 좁게 보면 갑과 을의 관계도 있고, 파트너도 있습니다. 그리고 넓게 보면 혼자서 일할 수 있는 조건을 만들어준 수많은 지식과 정보가 있습니다. 그 지식과 정보는 누군가로부터 나온 것이기 때문에 우리는 매 순간을 누군가와 함께 일을 합니다.

그런데… 참 함께 일한다는 것은 어려운 일입니다. 보다 효과적으로 일을 하기 위해서, 공유하는 가치를 배가시키기 위해서 ‘함께’ 일을 하지만 사실 ‘함께’ 일하다 보면 비효과적일 경우가 훨씬 많고, 공유할 가치가 무엇인지 잊어버리게 되는게 태반입니다. 우리가 겪게 되는 대부분의 조직 문제는 사실 ‘함께’ 제대로 일하지 못함으로 인해서 발생합니다. 따라서 우리가 흔히 단정짓는 사람과의 관계 때문에 문제가 발생한다는 말은 결국 함께 일하는 문화를 만들지 못한다는 말과 같은 말입니다. 이 문제에 대해 최근에 생각해볼 기회가 있었습니다.

(출처 : Flickr CCL : http://www.flickr.com/photos/eliotstyle/2447340919/)

#
조직에서 여러 사람들과 함께 일을 하지만 개인에게 부여된 역할은 서로 다릅니다. 때로는 상하관계로, 같은 팀의 관계로, 일시적인 프로젝트 단위로 묶여서 일을 하지만 역할은 상이합니다. 그러나 서로 다른 역할이 교집합이 전혀 없는 것은 아닙니다. 상당 부분은 함께 고민을 하고, 함께 기획하고, 함께 설계하는 과정이 필요합니다.

그리고 역할은 유동적입니다. 같이 일하는 사람들이 어떤 생각을 가지고 있고, 어떤 일 문화를 만들려고 하느냐에 따라 개인의 능력은 부여된 역할을 넘어 창의력과 상상력이 첨부되어 극대화되기도 합니다. 반대로 능력과 별개로 조직의 일문화 때문에 역할을 축소되고, 능력을 발휘할 기회를 잃는 경우도 있습니다. 당연히 우리는 전자의 문화를 기대합니다. 그러나 그게 참 어려운 일입니다.

일을 하다보면 아쉬움이 많이 남습니다. 생각하는 바를 일종의 문화로서 뿌리내리게 하기 위해서는 단지 말만 해서는 안되고, 그러한 근무환경을 만들어주는 것이 중요한데 근무환경에 대한 결정은 팀단위의 의사결정 너머에 있는 경우가 많습니다. 약 12년 정도의 조직 생활의 경험을 통해서 얻은 교훈은 “단지 일에 대한 의사결정권 뿐만 아니라 그 일을 추진하기 위한 근무환경에 관한 결정권도 해당 팀/부서에 부여해주는게 훨씬 효과적이다”는 것입니다. 물론 객관적으로 증명되지 않은 경험적 판단일 뿐입니다.

#
몇번 흥미로운 경험을 한 적이 있습니다. 전 웹서비스 개발이라고 하는 것은 구체적으로 모릅니다. 단지 검색을 통해 배우고, 어깨 너머로 배워서 약간의 HTML코드를 이해하고 있을 뿐입니다. 제가 서비스 기획자나 개발자는 아니지만 아주 간단한 코드 수정 등은 직접 해보려고 합니다. 직접 해봐야 직접 하기 두려워하고, 어려움을 겪고 있는 사람들에게 도움을 줄 수 있기 때문입니다.

당연히 전문적인 식견이 없기 때문에 이것저것 살펴보다가 어려움에 봉착하면 개발자에게 질문을 합니다. “이런이런 문제점을 해결하려고 코드를 살펴보고 수정해보려고 하는데 잘 안된다. 내가 생각하기에 이렇게 하면 될 것 같은데 뭐가 문제일까?….” 같은 모니터를 두고 내가 묻고 싶은 것을 직접 마우스로 가리키면서 질문을 합니다.

그런데.. 한두번이 아니고 정말 여러차례 경험한 것인데 질문을 하면서 저 스스로 해결책을 깨우칠 때가 있습니다. 참 이상합니다. 혼자서 머리 속으로 생각할 때는 잘 몰랐던 것을 질문을 던지는 과정에서, 상대방이 해결책을 알려주지도 않았는데 해결이 됩니다. 이걸 참 이상한 경험이다라고만 생각하고 있었는데 이런 현상이 일반적인가 봅니다. 어디에선가 봤는데 이런 현상을 저만 겪는게 아닌가 봅니다. 그리고 이런 현상을 일컫는 용어도 있었던 것 같습니다. (기억이 안나네요)

이와 같은 경험을 통해서 저는 “문제를 해결하기 위해서는 처음부터 함께 대화를 나누는 것이 중요하다”라는 것을 뒤늦게 깨달았습니다. 사실 이건 너무나도 당연한 이치인데 현실은 그렇지 않은 경우가 많습니다.

기획안을 혼자서 쓰고, 그걸 상사에게 검토받고, 다시 수정을 하고, 다시 검토를 받습니다. 물론 이런 단계를 거칠수록 생각이 깊어질 수도 있고, 보다 좋은 기획이 나올 수도 있겠죠. 그런데 옆의 만화(출처 : 김국현의 낭만 IT : http://www.goodhyun.com/ )처럼 내부 동료나 상사에게 검토받기 위해서 만드는 기획안/보고서 때문에 혹시 시간낭비하고 있지는 않은가요?

아예 처음부터 충분히 대화를 나누면서 기획안/보고서의 모든 내용을 있는 자리에서 검토하고, 서로의 이견을 충분히 확인하고, 어떻게 기획안을 정리해보자고 한 후에 마지막에 정리하는 차원에서 만들어내는 보고서가 훨씬 생산적이고, 효과적이지 않을까 생각해봅니다.

#
앞서 명확하게 역할을 규정하는 것이 오히려 일하는 사람의 창의력과 상상력을 제한할 수 있다는 이야기를 드렸습니다. 이런게 아닐까 싶습니다. 기업체에서 일해본 적이 없어서 그쪽은 잘 모르겠지만 비영리단체에서 일하면서 혹은 비영리단체에 계신 분들과 일하면서 종종 경험하게 되는 현상입니다. 특히 인터넷 관련해서는 그런 경우가 비일비재합니다.

우선 제가 몇몇 단체들의 홈페이지나 블로그의 기획이나 실제 구축을 도와드린 적이 있는데요. 제일 일하기 싫을 때가 단체에서 기획한 내용을 그대로 해줄 것을 요청하는 경우입니다. 왜냐면 그 기획한 내용대로 하면 분명 실패하거나 잘 안되는게 뻔히 보이고, 요구하는 바를 구현하는 방법이 잘못되었는데 그 고집을 꺾지 않기 때문입니다.

이럴 때는 잠시 고민을 하고 결정을 합니다. 도와드리는 입장에서 갑자기 하기 싫다고 할 수는 없기 때문에 몇차례 설득을 하다가 안되면 그냥 그대로 해줍니다. 하지만 거기에는 ‘성심성의’가 빠집니다. 그냥 빨리 이 상황에서 벗어나고 싶어서일 뿐입니다.

예를 들어 이런 경우입니다. 모 단체가 기부자들의 이름을 메인페이지에 노출시켜주고 싶다고 합니다. 단체를 도와주시는 분들을 좀더 돋보이게 하려는 취지는 충분히 이해를 합니다. 그런데 노출의 방식까지 정해서 알려줍니다. (약간 플래시적인 요소가 가미된 전환효과도 있는 그런 방식입니다.) 그 방식은 제가 보기에 단체 사람들이 보기에 멋져보일지는 모르지만 전혀 효과적이지 않은 방식입니다. 그래서 그 방식은 좀더 생각을 해볼 필요가 있다고 이야기를 합니다. 하지만 받아들여지지 않습니다. 참 괴롭습니다.

단체 내부에서 일하면서도 이런 경우가 분명 있을겁니다. 단체에서 IT,미디어,인터넷 등을 담당하시는 분들의 고충이랄까 그런게 있을겁니다. 서비스나 개발에 대한 이해가 없는 분들이 How의 영역까지 침범하는 경우 혹은 IT,미디어,인터넷 담당자의 역할은 뭔가를 사람들이 이야기한 것을 기술적으로 구현해내고, 서비스를 관리하는 것으로 한정하는 경우 말입니다. 여기서 얻은 교훈은 이런겁니다. “기획한 사업을 어떻게 구현해낼 것인가, 즉 최소한 HOW 영역은 되도록이면 나보다 더 잘 아는 사람(혹은 더 잘 알아야 하는 사람)에게 권한을 충분히 위임하자.” 그렇지 않으면 종종 서비스 개발자나 디자이너는 HOW에 대해 생각하지 않고 그냥 정리해준 일을 그대로 만들어내는 일에만 열중하게 됩니다.

이 이야기는 인터넷 서비스 기획에만 한정된 이야기는 아닙니다. 모든 일에 다 해당되는 것 같습니다. 조직 내에서 모든 것을 하나부터 열까지 다 챙기는 사람이 있다면 장기적으로 그 외의 사람들은 그 일을 챙기지 않기 시작하는 경향이 있습니다. 때로는 비워두는 것이 더 좋을 때도 있습니다.

(출처 : Flickr CCL : http://www.flickr.com/photos/eliotstyle/3249693629/)

#
혼자 일하는 것은 쉽지 않을 뿐더러 외로운 일이기도 합니다. 앞에서 한 이야기는 최근에 몇사람들과 함께 Writer’s Workshop라는 책을 가지고 세미나를 하면서 많이 생각해본 주제이기도 합니다. 뒤늦게 깨달은 탓도 있고, 생각이 행동으로 옮겨지지 않는 경우도 있어서 많은 아쉬움이 남습니다. 즉, 저 또한 함께 일하는 것을 잘하지 못해왔던 것 같습니다. 앞으론 잘 해야겠지요…