사람들은 사용법을 스스로 알아낼 수 없는 웹사이트는 사용하지 않는다.

사용성이 좋은 서비스 (초창기 인스타그램이나 핀터레스트처럼)는 사용법을 적어둘 필요가 전혀 없다. 일단 사용자들은 공부해가면서 앱을 쓰고 싶어하지 않는다.

몇 번은 예상이 틀려도 문제가 없지만 반복되면 인내심을 잃게된다.

헨델과 그레텔의 빵 부스러기(breas scrumb)처럼 길을 찾아올 수 있는 힌트를 계속해서 쉽고 직관적으로 찾을 수 있도록 해야 한다.

팀원들은 ‘팀장님이 문제를 해결해 주실 거야.’라고 생각하고 팀장은 ‘팀장인 내가 팀원 간 문제를 해결해야지.’라고 생각하지만 반은 맞고 반은 틀리다. 좋은 원칙이 있고 정보가 잘 흐른다면 누구나 좋은 의사결정을 할 수 있어야 한다.

예를 들면 담당자끼리 이야기하다가 풀리지 않으면 상위 담당자끼리 이야기해서 문제를 해결하는 시도는 자칫 편리해 보이지만 다음과 같은 문제를 야기한다   

 1. 팀 자체적인 문제해결 능력이 약해진다 : 가장 전문성을 갖춘 개개인이 스스로 문제해결을 하고 실패 속에서 배우는 시스템이 구축되지 않는다.
 2. 의사결정 속도가 느려진다. 언제든 상위 의사결정자를 부를 수 있다는 것은 결국 실무자 둘이 이야기할 것을 상위 의사결정자가 결정한다는 뜻. 의존성을 만들면 당연히 의사결정 속도가 느려진다.
 3. 상위 리더십이 더 중요한 결정에 시간을 쓸 수 없다. 팀장들이 매사 ‘불 끄러’ 다닌다고 더 중요한 전략적 의사결정과 로드맵 수립 같은 일에 투자할 수 없다. 이는 모호한 전략과 애매한 실행으로 이어져 성과가 안 좋아지고, 성과가 안 좋아지면 조직 간 갈등이 증가하는 악순환이 시작된다.

IT기업은 대부분 역할 조직의 형태를 따르고 있다. 역할 조직에서는 각자 ‘일당백’을 하므로 ‘나 없으면 돌아가지 않는 조직’이 되는 것이 일 잘하는 것이라 생각할 수 있지만 정반대다.  역할 조직에서는 누군가 없어져도 언제든 대체할 수 있다. 

내가 없어도 잘 돌아가고, 내가 있으면 더 잘 돌아가야 한다. 내가 없어져서 조직이 멈춰버리거나 급격히 성능이 저하된다면 조직 엔지니어링에 실패한 것이다. 팀장이 빠져도 팀원이 70~80% 수준의 의사 결정과 결과물을 낼 수 있어야 한다.

문제는 ‘리더가 의사결정을 마음대로 해서’가 아니다. 의사결정은 리더의 고유 권한이고 주요한 업무 중 하나라는 것을 구성원도 모두 이해하고 있다.  불만은 리더가 의사 결정해서가 아니라 의사결정에 필요한 정보와 과정을 구성원이 알 수 없기 때문에 불만이 생긴다.  리더가 해야 할 일 중에 가장 중요한 일은 ‘팀원들이 나와 비슷한 수준으로 의사결정할 수 있도록 정보가 흐르게 하는 것이다.

역할 조직에서 정보가 제대로 흐르지 않고 정치가 심화되면 각자의 정보 독점이 일어나면서 각자 성과보다는 ‘지위 관리’에 집중하게 된다. 각자의 지위와 권력을 유지하기 위해 역할을 나누고, 쪼개고, 허락을 구하고 결재받는 시간이 길어지며 의사결정과 업무 속도가 느려진다. 회의 아젠다로 ‘역할 나누기’가, ‘000팀, 검토해 주세요.’라는 요청이 업무에 자주 등장하게 된다

의사결정을 위해 무슨 팀을 찾아갈지 찾는 일이 일상다반사가 된다. 정보의 독점으로 인해 각자의 정보 의존성을 이겨내지 못하면 업무 자체가 진행되지 않기 때문이다. 속도가 곧 경쟁력임을 표방하는 스타트업에서는 이보다 큰 위기신호가 없다.

이를 해결하기 위해서는 다음과 같은 실행이 뒤따라야 한다.

1. 의사결정자, 담당자, 커뮤니케이션 채널을 명확하게 지정한다.

리더는 프로젝트 시작 전에 책임자를 분명하게 정해야 한다. 개인 실무자가 조직의 역학관계를 파악하는 것은 불가능하다. 정리된 내용은 관련 담당자 모두가 볼 수 있는 채널에 공유되어야 하며, 프로젝트 중 담당자 변경이 있다면 같은 채널에 이를 알려야 한다.

2. 프로젝트 관련된 정보가 공유되고 원칙이 세워진다.

프로젝트 관련된 정보가 투명하게 공유되어야 한다. 각 담당자는 프로젝트에 관련된 정보를 ‘파악하는 것’뿐 아니라 적절한 대상에게 공유하여 모두가 접근할 수 있도록 해야 한다.프로젝트의 ‘전략적 원칙’이 수립되어야 하는데, 여기서 말하는 전략적 원칙이란 프로젝트 목표를 달성하기 위해 ‘무엇을 얻고 무엇을 포기할지’ 명확하게 선언된 것을 말한다. 명확한 프로젝트 원칙은 리더 없이도 구성원이 좋은 결정을 내릴 수 있도록 돕는다.

3. 정보가 적시에 전달된다.

정보는 필요한 사람이 찾아보기 전에 의사결정을 내린 사람이 책임지고 전달해야 한다. 이는 리더나 실무자 모두에게 해당되며 프로젝트 진행 중 개개인 구성원이 노력이 필요하다. 시점은 의사결정된 즉시가 가장 좋다. 위에서 정리된 의사결정자, 담당자, 커뮤니케이션 채널을 참고해서 담당자에게 전달한다.

https://brunch.co.kr/@kgbtomas/291

리더가 없어도 결정은 내려진다.

비즈니스 전략 분석가 (Biz Dev)

전하민

버킷플레이스 DevOps Engineer

오재건

버킷플레이스 md

조규태

오늘의집 인턴

문이현

버킷플레이스 퍼포먼스 마케팅 인턴

김수빈

버킷플레이스 데이터엔지니어

민규

버킷플레이스 Lastmile Service Quality Manager

정민강

버킷플레이스

자영

버킷플레이스 crm마케팅

김정원

유통/기획

전영선

버킷플레이스 user researcher

김현정

버킷플레이스 프로덕트 디자이너

서미나

버킷플레이스 CEO Staff

선우연주

버킷플레이스 백엔드 디벨로퍼

이재황

버킷플레이스 PO

은민

오늘의집 Marketing Lead

김고운

마케팅

주봉

콘텐츠 마케팅 인턴

정유현

버킷플레이스 커뮤니티매니저

김세은

버킷플레이스 커머스 리드

김도연

버킷플레이스 SCM매니저

정용권

원종운

버킷플레이스 인턴

오레오네나

버킷플레이스 프론트엔드 개발자

이유리

버킷플레이스 소프트웨어 엔지니어

조희연

버킷플레이스 백엔드 개발자

김명준

은택

승현

버킷플레이스 디지털 마케팅

정재은

버킷플레이스 프론트엔드 개발자 

김경훈

버킷플레이스 전략팀

장혜원

홍은평

버킷플레이스 UX/UI 디자이너

지선

나트

버킷플레이스 시니어 데이터 엔지니어

김민수

버킷플레이스 UXwriter

김은진

CRM마케터

브랜드마케터

버킷

오늘의집 콘텐츠 매니저

최세희

피오

오늘의집 operation manager

Pyoroy

오늘의집 백엔드 개발자

승희

지윤

오늘의집 데이터 분석

Wilson

andy

프로덕트 디자이너

윤소현

UX Researcher

김성배

오늘의집 팀장

devhiker

언어

프론트엔드

백엔드

데이터베이스

데브옵스

Kotlin

Ruby

python

Scala

React

swift

SpringBoot

apache kafka

AWS S3

MySQL

Elasticsearch

Redis

mongodb

CassandraDB

Docker

Kubernetes

Github Actions

Jenkins

Terraform

Helm

Argo CD

Gradle

Datadog

기술 스택

언어