문제 : 회사의 목표가 지속적으로 변할 때 팀을 지휘하는 것은 어렵습니다.
저는 한창 성장 중인 스타트업의 관리자입니다. 매년 같은 일이 발생합니다: 임원진은 연말에 큰 계획을 세웁니다. 임원진들은 계획을 발표하고, 우리는 팀을 구성해서 그 계획에 착수합니다. 하지만 7~8월 경에 큰 변화가 생기고, 일부 팀은 그 변화가 새로운 제품 제안이건 비즈니스의 규모에 대한 문제이건 간에, 이를 대응하기 위해 이동합니다. 문제는 제가 팀에 확실성을 부여 할 수 없다는 느낌이 들고, 연초에 하겠다고 한 일의 절반도 구현하지 못한다는 것입니다. 우리 팀은 우리가 거의 완성하지 못하는 이런 기술적 향상에 대해 이런 생각을 가지고 있으며, 뭔가 바뀌기 전에는 우리는 어떤 흐름에도 따라갈 수 없다는 느낌이 듭니다. 이 문제를 어떻게 해야 할까요?
해법 : 도전을 받아들이고 유연하게 대처하세요.
특히 스타트업에서 변화는 피할 수 없습니다. 사실, 우리가 처음 스타트업에서 일하게 만든 것이 바로 그 변화입니다! 우리는 필요에 따라 좀 더 빠르게 움직이거나, 방향을 바꾸고 싶습니다. 그렇다면, 왜 우리가 변화가 일어났을 때 왜 그것에 맞서 싸워야 하나요?
제품 및 비즈니스 로드맵을 변경하는 문제는 모든 수준의 관리자가 직면하는 매우 일반적인 문제입니다. 특히 작은 회사에서는 일이 마무리되기 한 달 전의 약속을 지키기도 어렵습니다. 1년 또는 그 이상의 계획은 말할 것도 없습니다. 상황이 너무 빨리 변합니다. 대기업이라 할지라도 시장의 변화가 갑작스런 전략 변화로 이어져 프로젝트가 버려지고 계획된 작업이 취소 될 수 있습니다. 경기 침체기에 대기업에서 일해 본 적이 있다면 변화가 거의 일어나지 않는 회사에게도 큰 변화가 있을 수 있다는 놀라운 경험을 했을 것입니다.
이런 상황은 엔지니어링 관리자들에게 힘든 상황이죠. “중간 관리자”의 입장에서 전략적 변경이라는 말을 듣는 것은 결코 유쾌한 상황이 아닐 겁니다. 상위 조직으로부터 내려오는 전략적 변화를 되돌릴 힘은 거의 없고, 팀에게 어떤 프로젝트가 진행될 것이라고 말했어도 예상치 못한 변화 때문에 그 약속을 지키지 못할 때도 있을 겁니다. 이런 상황은 팀을 불행하게 만들고, 팀원들은 당신에게 불만을 토로하게 될 겁니다. 이런 상황을 처리할 능력이 없기 때문에, 당신은 당신의 무력함이 드러난다고 느낄 수 있고, 팀원들은 회사가 자신들을 사람이 아닌 기계의 부품으로 여긴다고 생각할 수 있습니다.
여기에서 나오는 두번째 과제 : 업무들의 우선 순위를 정하는 명확한 프로세스가 없어보이는 이런 상황에서, “기술 부채(technical debt)”나 다른 엔지니어링 중심적인 프로세스들을 처리하기 위한 시간을 확보하려면 어떻게 해야 할까요? 결국 기술적인 문제를 처리하는 데 시간을 투자하지 않으면, 제품의 기능을 개발하는데 속도가 느려지게 될 겁니다. 하지만 제품 팀의 로드맵에는 “기술 부채”가 없으므로, 계획 프로세스에는 이런 문제를 해결하기 위한 시간을 고려하지 않을 것입니다.
실질적인 조언 : 회사의 목표를 달성할 수 있도록 업무를 조절하고 기술 부채를 줄일 수 있는 계획을 세우세요.
이런 변화와 불확실성은 어떻게 다루어야 할까요?
당신이 일하는 회사의 규모와 상황을 고려해 계획이 바뀔 가능성에 대해 현실적으로 생각하십시오. 매년 여름 상반기의 비즈니스 결과를 고려해 여름마다 계획을 변경한 적이 있는 스타트업에서 일하고 있으므로, 여름에는 변화를 대비하고 그 이후에도 계속 유지되어야 하는 약속은 가급적 하지 않도록 주의하세요.
대규모 프로젝트를 일련의 작은 결과물로 나누어 전체를 다 완수하지 못하더라도 결과를 얻을 수 있는 방법을 고민해 보십시오. 기술적인 일들을 작게 나누는 일은 제품이나 비즈니스 매니저들과 더 긴밀히 협력하면서 세부적인 업무들의 우선 순위가 어떤지 알아내야 가능합니다. 모든 일들이 빠르게 바뀌기 때문에, 바로 지금 무엇이 가장 중요한가를 파악하는 안목으로, 모든 것들을 주기적으로 다시 검토해야 합니다.
기술 프로젝트의 미래에 대해 과도하게 약속하지 마십시오. 미래의 제품 로드맵이 아직 나오지 않았으므로, 미래의 기술 프로젝트에 대해 미리 약속하지 마십시오. 이런 생각은 희망을 불러 일으켰다가 다시 실망하게 만듭니다. 프로젝트가 중요하다면, 바로 지금 수행하도록 하십시오. 아니면 최대한 빠른 시일 내에 수행하도록 하세요. 만약 프로젝트가 시급히 중요하지 않다면, 그것을 업무 리스트에 넣어 놓을 수 있을 겁니다. 하지만 한번 나중으로 미루기 시작하면, 다른 비즈니스에서 온 일들과 함께 우선 순위를 정해야 하는 아주 긴 리스트가 만들어질 수 있다는 점에 대해서도 현실적으로 고민해봐야 할 겁니다. 이 일의 가치를 제대로 평가할 시간을 갖지 못한다면, 명백하게 중요해 보이는 다른 프로젝트에 의해 우선 순위가 밀리게 될 겁니다.
팀의 일정 중 20%는 “유지 업무”에 할당하십시오. 이는 리팩토링, 버그 수정, 엔지니어링 프로세스 개선, 정리 작업, 그리고 지속적인 지원 업무 등을 의미합니다. 이는 계획 세션에서 늘 고려되어야 합니다. 불행하게도 20%는 대규모 프로젝트를 수행하기에는 충분하지 않으므로, 중요한 기술의 재구성이나 큰 기술적 개선을 얻기 위해서는 추가적인 계획이 필요합니다. 하지만 이 20%의 시간이 없다면 놓쳐버린 목표나 계획되지 않았던 불쾌한 정리 작업 따위로 인해 좋지 않은 결과가 발생할 수도 있습니다.
다양한 엔지니어링 프로젝트들이 실제로 얼마나 중요한지 이해하십시오. 제품이나 비즈니스 프로젝트는 보통 스스로를 정당화하는 가치 제안을 가지고 있습니다. 하지만 기술 프로젝트에 있어서도 그와 동일한 엄격함이 적용되는 것은 아닙니다. 엔지니어가 자신이 수행하고 싶은 프로젝트를 당신에게 가지고 왔을 때, 다음의 질문들에 답하면서 프로젝트의 프레임을 고려해 보십시오:
이러한 질문의 가치는, 당신이 대규모 기술 프로젝트를 제품 제안과 동일한 방법으로 다루기 시작했다는 것입니다. 이런 프로젝트들은 옹호자와 목표를 가지고 있으며, 일정이 있고, 다른 대규모의 제안들과 비슷하게 관리됩니다. 때로는 당신이 뭔가가 중요하다는 것은 “알지만”, 비즈니스에 가치를 매기듯이 그 가치를 측정할 수 없는 경우도 있기 때문에, 이 과정은 두렵기도 합니다. 기술적인 프로젝트의 복잡한 특성과 엔지니어링 효율성 측정과 같은 어려움 때문에, 당신이 어디로, 왜 가고 있는지 완전히 이해하지는 못하는 비기술자인 파트너에게 기술적인 세부 사항을 설명하기 어려울 때가 있습니다. 제가 드릴 수 있는 조언은, 당신의 주장을 지지할 수 있는 데이터를 모으는데 최선을 다하고, 일이 완료되었을 때 무엇이 가능한지 설명하라는 겁니다. 당신이 기술 프로젝트를 검토해봤을 때, 거의 변화도 없고 기술이나 비즈니스에 핵심적인 개선도 없이 해야 할 업무만 많다면, 그만한 가치가 없는 일일 겁니다. 유감스럽게도, 당신의 팀이 하고 싶은 모든 탐색 엔지니어링, 레거시 코드 정리, 그리고 기술적 품질 개선을 수행할 시간은 없습니다. 그리고 이 프로세스가 당신이 수행할 업무를 선태하는데 도움을 줄 겁니다.
자, 당신의 불확실한 로드맵으로 돌아가봅시다. 프로젝트가 변경되었습니다. 당신이 이해하거나 동의하지 못하는 방법으로 팀이 해체되거나 이동할 수도 있습니다. 관리자로서 할 수 있는 최선의 일은, 사람들이 업무를 잘 마무리하고 현재 진행 중인 프로젝트에 잘 안착해 새로운 업무를 잘 수행할 수 있도록 도와주는 것입니다. 이것이 당신이 물러설 수 있는 곳입니다. 팀이 현재 작업을 마무리 할 수 있는 충분한 시간을 확보했는지 확인하십시오. 게다가, 새로운 업무의 초기 계획에 엔지니어링 참여를 유도하여 사람들이 이동한 새로운 업무에 흥미를 가질 수 있도록 만들 수 있습니다. 시간을 들여 이동의 이유에 대해 이해하고, 당신이 완전히 동의하지 못하더라도 이 이유들을 팀에 알리고 팀이 새로운 목표를 이해하도록 당신의 역할을 수행하세요. 이런 변화를 마주했을 때, 침착할 수록 새로운 방향에 대한 열정을 (가짜로라도) 보여줄 수 있고, 당신 팀의 전환도 더 쉽게 이루어질 것입니다.
파도를 만났을 때, 파도가 당신을 끌어내리게 할 수도 있고, 당신이 파도를 타는 법을 배울 수도 있습니다. 살아남으시기를.
이전 글 : 레이저로 자른 170개 조각으로 만든 거인의 손
다음 글 : 브레드보드 팁 5가지
최신 콘텐츠