얼마 전, 다른 팀과 함께 진행하는 큰 프로젝트의 협업 미팅에서 이런 이야기가 나왔습니다.

“이 부분의 설계는 거의 끝난 것 같네요. 이제 구현할 사람만 찾으면 될 것 같습니다.”

당장 투입할 수 있는 일손이 부족했던 건너편 팀은 저희 매니저에게 개발자를 구해줄 수 있겠냐고 물었습니다.

저희 매니저는 뜻밖의 대답을 했습니다.

“그렇다면 설계는 여기서 잠시 멈춰주실 수 있을까요?”

“이 프로젝트를 맡을 사람에게도 중요한 결정을 함께 내릴 여지가 있어야 합니다. 설계가 모두 끝난 뒤 구현과 출시만 부탁하면 오히려 사람을 찾기 어려울 거예요. 지금 정도로 열어두는 게 좋겠습니다.”

당시에는 의아했습니다. 어려운 문제를 미리 풀고 해야 할 일을 명확하게 정리해두는 것이 다음 사람을 돕는 일이라고 생각했기 때문입니다.

최근 다른 팀과 함께하던 프로젝트가 잘 진행되지 않는 이유를 고민하다가, 그때 저희 매니저가 했던 말이 다시 떠올랐습니다.

협업을 진행하며 저는 열정적으로 기술적인 문제를 정리하고, 좋은 해결책을 만들고, 제 설계가 왜 옳은지 설명하는 데 집중했습니다. 해결책과 해야 할 일을 명확하게 보여주면 상대 팀도 쉽게 참여할 수 있을 것이라 생각했습니다. 하지만 기대만큼 반응이 돌아오지 않아 풀이 죽어 있던 참이었습니다.

돌이켜보니 저는 함께 풀 문제를 나누는 대신, 이미 정해진 답과 해야 할 일을 전달하고 있었습니다.

상대 팀에게 이 프로젝트가 왜 중요한지, 그들이 무엇을 직접 결정하고 이끌 수 있는지는 생각하지 않았습니다.

그래서 접근을 바꿨습니다.

열정적으로 준비한 설계를 검토해달라고 요청하는 대신, 우리가 만들고 싶은 변화와 아직 풀리지 않은 문제를 공유했습니다. 제가 생각한 방향은 초안으로 남겨두고, 그 영역을 더 잘 아는 상대 팀의 기술 리드에게 함께 설계해달라고 부탁했습니다.

그러자 프로젝트가 조금씩 진행되기 시작했습니다. 제가 풀고 싶었던 문제가 그 팀도 풀고 싶은 문제가 되었기 때문입니다.

상대 팀은 제가 알지 못했던 선택지를 제안했습니다. 불가능하다고 생각했던 방향이 사실은 몇 주의 작업이면 가능하다는 것도 알게 되었습니다. 결과적으로 혼자 준비했던 것보다 더 나은 설계가 나왔습니다.

저는 성공적인 협업을 위해 세밀한 해결책을 제시하고, 해야 할 일을 명확하게 나누어야 한다고 생각했습니다. 하지만 좋은 해결책만으로는 함께하고 싶은 이유까지 만들 수 없었습니다.

협업이 잘 풀리지 않을 때는 해결책을 더 다듬기 전에 돌아보려고 합니다. 우리가 만들고 싶은 변화를 충분히 나누었는지, 상대가 함께 결정할 자리를 남겨두었는지.