비즈니스에서는 Output보다 Outcome을 고민해야 한다.
개발조직의 팀장으로 온지 이제 1년을 채워간다. 생각보다 쉽지 않고, 여전히 가야할 길이 멀다. 그 중에 가장 쉽지 않았던 부분이 바로 Output과 Outcome에 대한 구별과 이에 기반한 업무 진행방식을 이해시키는 것이었다.
내가 오기 전에도 개발팀은 Output과 Outcome을 충분히 잘 만들고 있었다. 차이가 있다면 Output에 대한 이해도를 바탕으로 능동적으로 일을 하는 것은 익숙한데 반해서 Outcome에 대한 이해는 암묵지 수준에서 수동적으로 영향을 끼치고 있다는 것이었다.
보통 개발팀에게 설명할 때 나는 Output과 Outcome도 좋지만, 일반적으로 대부분의 회사 뿐만 아니라 사회에서는 어지간하면 Output보다는 Outcome 방식으로 이해하는게 좋다고 말한다.
Output은 말그대로 Out+Put으로 결과물을 만드는 것에 집중하는데 반해서, Outcome은 결과물을 만드는데 반해서 추가 액션이 파이프라인 형태로 이어지기 때문이다. 회사가 하나의 목표를 위해 다양한 Function이 조직적으로 결합되어 움직인다고 보면 파이프라인이 생기지 않은 결과물은 단독적으로 진행하는 연구성격의 과제라면 모를까, 업무 관련 지속해서 동기부여를 받기 어렵다.
물론 단독으로 하는 연구에도 자신의 결과물을 기반으로 추가연구를 기획하는 것이 가능하지만, 그렇다고 하면 회사에서 있을 이유가 마땅히 없을 수도 있다. 이런 경우 회사가 제공하는 비싼 환경 속에서 하고 싶은 연구만 적당히 하다가 마땅히 해야할 것을 찾지 못하고 이직하는게 최선의 선택인 것마냥 여겨지기 싶다.
이에 반해서, Outcome을 생각해서 회사의 파이프라인에 과제가 연결될 수 있도록 한다면 지속해서 개선과제가 발생하게 되고 일부는 운영과제이겠지만, 일부는 연구형태의 과제 또는 새로운 사업과제로 나타나게 되면서 개개인의 영향력이 올라가게 되고 자연스럽게 회사의 구성원으로서 동기부여를 쉽게 받을 수 있게 된다.
그래서인지 항상 나는 구성원에게 Outcome을 더 중요시 여겨라고 말하는 편이다. 그리고 디테일하게는 두가지 방안을 제시한다. 탁월한 기술로써 유관부서들에게 영향을 줄 수 있는 사람이 되던지, 또는 비즈니스 문제를 해결함으로써 유관부서에게 영향을 주든지, 두 가지 길 중 하나를 선택하라고 말하는 편이다.
나는 후자를 선택하고, 임팩트를 더 키우고, 구성원을 성장시키는 일에 흥미를 느끼기 때문에 매니징의 길을 선택하였지만 개개인의 선택에는 정답이 없기 때문에 각자의 적성에 맞게 선택하면 되는 문제이지만 Outcome과 Outcome은 항상 고민할 필요가 있다.
