일은 보통 먼저 큰 그림을 잡고 점차 세부 사항으로 진행하게 된다. 서울에서 부산으로 여행을 간다면 여행 계획을 세우고 교통편, 숙박, 할 일 등 세부 사항을 정하고 하나씩 실행하는 식이다.

사람은 중요한 일일수록 꼼꼼히 잘 확인하고 진행한다. 그런데 나는 꼼꼼해야 할 것을 잘못 짚은 경우가 있다. 각 단계는 문제가 없어 보여도 한참 진행하다가 생각지도 못했던 곳에서 상황이 뒤집어진 것이다.

열심히 했는데 다시 하란다

프로젝트에서 일의 방향이 뒤집히는 경우가 종종 있다. 우리 팀은 A 업무 영역과 B 업무 영역을 잘 만들고 이미 테스트도 한참 진행 중이었는데 고객 담당자가 내부 보고회에서 나온 대표님의 말씀을 전했다. “A 영역보다는 B 영역이 더 중요한 업무 아닌가? B 영역을 메인으로 하고 A 영역 일부를 B에 끼워 넣어!”

그나마 이 경우는 메인 화면 하나에 영향이 그쳤지만 다른 프로젝트에서는 임원 한마디에 전체 프로세스가 영향을 받은 적도 있었다. 화면 하나의 기능을 보완하라는 요청인데 그러려면 프로그램 설계, 화면 시안부터 다시 잡고 개발도 추가 작업이 필요한 경우였다.

이런 사례는 누구의 잘못을 따지기보다 문제 원인이 그 전에 있었다. 눈앞의 담당자들과 메뉴, 버튼, 화면 배치를 자세히 협의하면서도 더 중요한 일의 목적이나 고객 편의성, 최종 결정권자 등을 깊게 고려하지 않은 것이다.

비유하자면 돌다리의 돌 하나하나는 열심히 두드렸는데 정작 이 다리가 맞는 다리인지 잘 알아보지 않았다.

열심히 꼼꼼히 일하는 것보다 중요한 것

그래서 나는 깨닫는다. 디테일보다 먼저 확인할 것은 목표라는 것, 목표에 따른 조건들이라는 것.

일을 잘하려다 보면 세부적인 것을 신경 쓰기 마련이지만 일에 영향을 주는 변수는 다양하다. 모든 변수를 다 고려할 수는 없지만 디테일로 빠지기 전에 해야 할 질문들이 있다.

  • 우리가 정말 해결하려는 문제가 이것인가?
  • 지금 이야기하고 있는 사람이 실제 결정권자인가?
  • 원하는 결과물의 형태가 이 일의 목표에서 가장 최선인가?
  • 당연하다고 생각한 전제가 바뀌지는 않을 것인가?

이런 질문은 쉽게 놓치게 된다. 세부 사항은 눈앞에 보이지만 이런 질문의 답은 바로 분명하게 보이지 않기 때문일 것이다.

기획자가 고객과 화면 방향에 대해 얘기할 때 나는 이미 머릿속에서 코딩을 하고 있었다. 디테일에 먼저 빠진 것이다.

가족여행도 마찬가지였다

일이 아니더라도 비슷한 경험이 있다. 어쩌다 여행을 가게 되면 난 아이들이 여행에 대해 잘 모를 테니 내가 먼저 계획을 잘 세우고 얘기해보자고 생각했다.

해외여행인 경우 비행기 시간, 숙소도 알아보고 이동 방법, 관광할 곳, 식당까지 찾아본다. 그리고 아내와 아이들에게 일정을 보여주면서 마음에 드는지, 바꿀 건 없는지 등을 물어본다.

그런데 막상 여행을 가보면 가족들이 내가 기대했던 만큼 여행을 즐기지 못한다.

분명 계획을 세울 때 다 물어보고 확인했는데 왜 그럴까? 생각해보니 질문을 잘못한 것이었다.

이러저런 데 갈 건데 괜찮아?
이런 음식 어때?
언제 일어나서 나가야 되는데 괜찮아?

이렇게 물으면 당연히 계획만 보고 대답한다. “괜찮아요”, “좋아요”, “그렇게 해요”. 여행 자체에 대한 대답이 아닌 것이다.

누군가는 구경 다니는 것보다 편안하게 먹고 쉬는 걸 좋아하고 누군가는 놀이기구 여러 개를 타는 것보다 하루 종일 물놀이하는 걸 좋아한다. 가족들이 정말 원하는 것부터 확인하는 게 아니라 계획 검토만 시킨 것이다.

중요한 건 이런 질문일 것이다.

어떤 여행을 가고 싶어?
여행에서 해보고 싶은 게 있어?
어떤 걸 할 때 제일 즐거울까?

뭣이 중헌디

당장 벌여 놓은 일에 집중하는 것은 일의 성공을 위해 꼭 필요하다. 하지만 이제는 이렇게 자문하려고 한다.

지금 내가 열심히 하는 일이 정말 중요한 게 맞는가, 아니면 혹시 디테일에 매몰된 것은 아닌가?

돌다리도 두들겨 보고 건너야 한다. 그런데 열심히 두들기다가도 한 번 고개를 들어보는 것이 필요하다.

이 다리가 내가 건널 다리가 맞는지 말이다.