Image by Keith Johnston from Pixabay.
매니저로서의 역할을 잠시 지우고 다급한 프로젝트의 개발과 테스트에 몰입하는 동안 팀원들이 붕떠 있는 느낌을 받는다. 함께 해야하는 세 개의 프로젝트 중 두 개도 덩달아 붕 떠서 방향을 잃고 있다.
사람이 부족하다고 사람을 더 뽑자고 하는데, 사람이 없어서 일을 못하고 있는게 맞는지 스스로 의문이 든다. 우선 팀을 재정비해야 겠다는 생각이 든다. 무엇을 해야하는지 방향을 잡지 못하는 팀을 위해 스크럼 회의를 시작하기로 한다.
개인적으로 스크럼 회의에 대해 부정적인 경험이 꽤 있다. 나 자신도 팀원으로서 매우 형식적인 스크럼 회의에 진절머리를 친적도 있고, 내가 리딩을 하려 할 때 격하게 저항하는 팀원을 만난적도 있다. 그래서 이런 활동이 꼭 필요하다고 판단될 때도 팀원들이 부담되지 않는 방향을 중요시 해왔다.
최근에 빅테크 기업들을 거쳐 나름 잘나가는 스타트업의 CTO로 있는 분이 회사 엔지니어링 롤에 지원해서 면접을 볼 기회가 있었다. 그에게 좋은 회사들에 다니셨는데 기억에 남고 우리 회사에 오면 적용해 보고 싶은 문화가 있는지 물었다.
그는 코드리뷰 문화와 스크럼 문화를 꼽아서 대답했고, 그와 스크럼 회의에 대한 이야기를 나눌 수 있었다. 나는 팀원들이 부담되지 않게 주의해서 스크럼 회의를 진행하곤 한다고 나누었는데 그의 대답은 전혀 달랐다. 자신은 오히려 어느 정도 부담을 주기 위해 스크럼을 한다고.
적절한 프레셔는 오히려 도움이 된다고 했다. 좋은 회사들에서 많은 경험을 한 그와의 인터뷰는 내게 무척 신선하고 유익했다. 여러 문제들로 그의 입사는 홀딩되어 있지만 업계의 선배를 만나 도리어 내가 상담을 받은 기분이 들었다.
다시 본론으로 돌아가면 요즘 붕떠 있는 팀원들과 프로젝트를 위해 스크럼을 시작했다. 이제는 팀원들에게 약간의 부담을 주는 동시에 지나친 부담은 주지 않기 위해 노력했다. 이 회의 목적은 오직 우리가 같은 목표를 가지고 협력해서 일을 잘 하기 위함이며 보고의 목적은 없음을 강조했다.
나 또한 나의 일을 공유하며 상하관계의 프레임을 제거했고, 그들의 일을 공유할 때 여러가지 질문과 제안을 하며 일종의 디렉션을 했다. 어제 한다고 했던 일을 못했을 때 비난은 없으며 나 또한 그러기도 한다고 자연스럽게 설명했다.
일주일 진행했는데 프로젝트가 점점 제자리를 찾아가는 것 같고, 팀원들도 자기 자리에 랜딩하는 느낌을 받는다. 매니저가 되는 걸 싫어했던 기억이 난다. 난 백발의 개발자가 되고 싶다고 했던 기억이다. 그런데 요즘은 이런 일을 하는 사람이 정말 필요하구나 생각된다.
내가 그런 일을 잘 할 수 있는 사람이라면 내가 해야겠다는 생각도 든다. 여전히 프로그램을 직접 개발하고 테스트 하는 일은 즐겁다. 그래서 완전히 놓고 있지는 않지만. 필요하다면 잠시는 매니징에만 전념할 생각을 하는걸 보니 나도 많이 변했나 보다.
