팀장의 말은 Problem Making?
팀장님 가라사대
이번 단원에서는 팀장의 말이 ‘문제 해결’이 아니라 ‘문제 확장’으로 바뀌는 순간을 다룬다
앞 단원들에서 말의 경로(어디로 흘러가는가),
변환 단계(어떻게 손실되는가), 방해 요인(DOOTA)을 다뤘다면,
이번 단원은 한 단계 더 현실 쪽으로 내려온다.
팀장이 말을 “정확히” 했는데도 일이 복잡해지는 이유가
단순 오해가 아니라 ‘문제의 생성’으로 이어지는 경우가 있기 때문이다.
말이 전달되는 과정에서 단지 의미가 어긋나는 수준이 아니라, 조직이 그 말을 ‘쟁점’, ‘범위’, ‘책임’, ‘기준’, ‘리스크’의 형태로 재구성하면서 새로운 문제가 만들어진다.
여기서 Problem Making은 당연히 팀장이 의도적으로 문제를 만든다는 뜻이 아니다.
팀장의 말이 조직 안에서 갖는 ‘신호성’이 강해지면서,
특정 유형의 문장이 자동으로 문제를 촉발하는 현상을 말한다.
즉 말이 “의도”가 아니라 “조직의 게임 규칙”으로 읽히기 시작할 때, 팀장의 한 마디가 업무를 정렬하는 대신 업무를 복잡하게 만드는 트리거가 될 수도 있다는 점이다.
이 단원은 팀장이 어떤 문장을 조심해야 한다는 도덕적 조언을 하지 않는다.
대신 현장에서 가장 자주 발생하는 “문제 발생 메커니즘”을 구분하고,
그 메커니즘을 줄이는 방향을 제시한다.
말의 품질이 아니라, 말이 문제로 바뀌는 조건을 낮추는 운영의 관점이다.
팀장의 말은 ‘의견’이 아니라 ‘사건’으로 접수된다
팀장의 말은 자주 ‘사건’이 된다. 팀장은 “생각해보자”라고 했는데 팀은 이미 일정과 자원을 재배치한다.
팀장은 “우려가 있다”라고 했는데 다른 부서는 “반대”로 접수한다.
팀장은 “최대한”이라고 했는데 팀은 완료 기준을 스스로 확장한다.
왜 이렇게 될까? 팀장의 말이 사건으로 바뀌는 이유는
조직이 팀장에게 기대하는 기능이 동시에 켜지기 때문이다.
같은 문장에 다음 기능이 겹친다.
의미 부여 기능이다. 이 일이 왜 중요한지의 의미 신호로 읽힌다.
기준 설정 기능이다. 잘한 것과 못한 것을 가르는 잣대로 읽힌다.
책임 배치 기능이다. 누가 어디까지 책임지는지의 방향으로 읽힌다.
리스크 선언 기능이다. 안전 모드로 전환해야 한다는 경고로 읽힌다.
우선순위 조정 기능이다. 지금 무엇을 밀고 무엇을 미룰지의 신호로 읽힌다.
이 기능이 겹친 상태에서 말이 던져지면,
팀장 본인은 단순히 “한 마디”을 말했을 뿐인데
조직은 “여러 결정을 포함한 신호”로 받아들인다.
그리고 그 신호가 명확히 설정되지 않으면, 조직은 각자 방식으로 이해하려 한다.
그 순간부터 말은 오해를 넘어 문제를 키우게된다.
Problem Making의 다섯 가지 대표 메커니즘
문제는 말의 내용보다 ‘일이 만들게 되는 후속 행동’에서 커진다. Problem Making은 주로 다섯 가지 형태로 나타난다. 각각은 서로 다른 종류의 문제를 만든다.
(1) 쟁점화 메커니즘
팀장의 점검·우려·질문이 ‘반대’나 ‘논쟁 선언’으로 읽히는 경우이다. 팀장은 리스크를 줄이려고 한 마디를 던졌는데, 상대 부서나 팀원은 “그럼 못 하게 한다”로 받아들인다. 이때부터 대화는 실행 설계가 아니라 설득과 방어로 이동한다.
쟁점화의 특징은 간단하다. 말이 ‘해야 할 일’이 아니라 ‘이겨야 할 주장’으로 변한다. 회의는 길어지고, 문서는 늘어나고, “누가 맞냐”의 게임이 시작된다. 결과적으로 실행은 늦어지고, 관계 비용이 커진다.
쟁점화는 대개 이럴 때 터진다.
팀장이 “이 부분이 위험하다”라고 말했는데, 위험의 범위와 판단 기준이 없을 때이다.
팀장이 질문을 던졌는데, 질문이 학습 질문인지 반대 질문인지 구분되지 않을 때이다.
팀장이 “이건 다시 보자”라고 했는데, 논의인지 중단인지 확정 문장이 없을 때이다.
팀장이 던진 말이 ‘검토’인지 ‘반대’인지가 조직 안에서 분리되지 않으면,
조직은 대개 안전을 위해 “반대”로 해석한다. 반대로 해석해야 책임이 줄기 때문이다.
(2) 범위 팽창 메커니즘
“제대로”, “완성도 있게”, “최대한”, “깔끔하게”, “빈틈없이” 같은 품질 언어가 완료 기준 없이 던져질 때 발생한다. 팀장은 좋은 결과를 원해서 한 말인데, 조직은 그 말을 “끝이 없는 요구”로 받아들인다.
오히려 더욱 순종적인 사람일수록 더 팽창한다. 더 보완하고, 더 확인하고, 더 안전하게 가려 한다. 그러면 일정이 늦고, 팀장은 다시 말이 많아진다. “왜 이렇게 오래 걸려?”라는 질문이 나오고, 팀은 방어적으로 더 많은 설명을 한다. 이 루프가 시작되면 말은 계속 늘어난다.
범위 팽창이 터지는 현장 신호는 이런 형태이다.
산출물이 계속 개선되는데도 ‘끝’이 없다.
초안이 계속 늦고, “조금만 더”가 반복된다.
담당자가 스스로 일을 키우고, 다른 일은 밀린다.
“이 정도면 되지 않나”가 “아직 부족하다”로 되돌아온다.
이 메커니즘을 줄이려면 “품질”을 말하지 말아야 하는 게 아니다.
도리어 품질을 ‘조건’으로 명확히 설정해야 한다.
결과의 미학이 아니라 의사결정에 필요한 최소 조건을 규정해야 한다.
(3) 책임 혼선 메커니즘
책임의 혼선은 팀장이 역할을 배정했는데 권한, 승인선, 책임선이 같이 다루지 않을 때 발생한다.
“네가 리드해”는 일을 주는 말 같지만, 권한이 없으면 책임만 떠넘긴 말로 읽힌다.
그러면 팀원은 안전을 위해 확인을 늘린다. 팀장은 확인에 답하느라 더 말이 많아진다.
이게 가장 전형적인 ‘팀장 병목’의 시동이다.
책임 혼선은 흔히 이런 모습으로 나타난다.
팀원이 계속 “이건 제가 결정해도 되나요?”를 묻는다.
팀장이 매번 승인자가 되고, 팀은 팀장 대기 상태가 된다.
일이 진행되다가도 “이건 우리 범위가 아니다”가 나오면 멈춘다.
문제가 생겼을 때 서로 책임을 미룬다.
팀장이 책임 혼선을 줄이는 방식은 의외로 단순하다.
권한을 주기 전에, 책임선을 ‘문장’으로 명확히 하는 것이 좋다.
“최종 결정은 내가, 실행 품질은 네가” 같은 문장이 정리돼 있으면 확인 질문이 줄고, 팀장의 말도 줄어든다.
(4) 기준 공백 메커니즘
팀장이 배려나 공정의 의도로 결정을 미루거나, “다 같이 합의하자”를 반복할 때 발생한다.
합의 자체는 좋은데, 기준이 없는 합의는 ‘기준 공백’을 만든다.
기준이 비어 있으면 구성원은 각자 기준을 만든다.
각자 기준이 늘면 실행력이 분산되고,
결과는 뒤늦게 충돌한다.
그때 팀장은 다시 말이 많아진다.
“내가 그런 뜻이 아니었는데”가 반복된다.
기준 공백은 보통 이렇게 드러난다.
회의는 많이 했는데 “확정”이 없다.
결정이 나도 문서나 메시지에 남지 않는다.
다음 회의에서 같은 논의가 다시 열린다.
사람마다 “나는 이렇게 이해했다”가 나온다.
기준 공백은 관계 문제가 아니라 운영 문제이다.
팀장이 해야 할 일은 다 같이 친해지는 것을 넘어, 확정 기준을 남기는 것이다.
이게 앞에서 말한 ‘접점 설계’가 실제로 작동하는 부분이다.
(5) 리스크 은폐 메커니즘
팀장이 추진력을 위해 “일단 진행”을 반복할 때, 리스크 발화 자체가 위축되는 현상이다.
사람들은 “리스크를 말하면 분위기를 깬다”라고 생각한다.
그러면 리스크는 사전에 올라오지 않고, 사후에 터진다.
그 사후는 대부분 방어와 책임의 언어로 변한다.
공유는 사후 보고가 되고, 회의는 변명 자리가 된다.
실행은 해결이 아니라 방어를 위한 실행이 된다.
리스크 은폐의 현장 신호는 다음과 같다.
문제는 커졌는데 “왜 아무도 말 안 했지?”가 나온다.
이슈는 늦게 공유되고, 공유 메세지도 길어진다.
책임 논쟁이 먼저 생기고 해결 논의가 뒤로 밀린다.
사람들은 더 안전한 말만 한다.
여기서 팀장의 포인트는 리스크를 “더 많이 찾자”가 아니다.
리스크가 쉽게 올라오도록 말의 안전장치를 만들어야 한다.
즉 리스크 발화를 “저항”이나 “핑계”로 읽지 않겠다는 운영 신호가 있어야 한다.
Problem Making을 줄이는 팀장 운영의 핵심
Problem Making을 줄이는 해법을 한 마디로 말하면 이렇다.
팀장의 말이 ‘문제’가 되기 전에, 말이 완성되는 구조를 만든다.
여기서 본 도서의 핵심 메세지인 SSM은 기능이 아니라 순서이다.
Sense(의미)는 해석을 명확히 한다.
Structure(구조)는 기준과 책임을 구체화한다.
Momentum(실행)은 다음 행동으로 연결한다.
이 순서가 깨질 때, 문제가 발생한다.
의미가 없으면 질문은 저항으로 읽히고 쟁점화가 된다
구조가 없으면 품질 언어는 범위 팽창이 된다
추진만 있으면 리스크는 은폐되고 사후 책임으로 돌아온다
즉 팀장은 “더 설득력 있게 말하기”보다 “문제 발생이 잦은 구간을 먼저 낮추기”를 해야 한다.
이 관점으로 보면, 팀장의 말은 자연스럽게 짧아지고, 팀의 실행은 빨라진다.
결론
팀장의 말은 일을 풀기도 하지만, 문제를 만들기도 한다.
쟁점화, 범위 팽창, 책임 혼선, 기준 공백, 리스크 은폐는 대부분 팀장이 “더 잘해보자”는 의도로 던진 문장이 조직의 신호로 읽히면서 생긴다.
그래서 해법은 화술이 아니라 운영이다.
의미를 한 마디로 설정하고, 기준과 책임을 구체화하며, 다음 행동을 한 줄로 연결하면 말은 문제를 만드는 장치가 아니라 실행을 만드는 장치로 바뀐다.
팀장이 줄여야 하는 것은 말이 아니라, 말이 문제로 변환되는 조건이다.
단원 요약 및 예고
이 단원은 팀장의 말이 오해를 넘어 ‘문제 발생’으로 바뀌는 다섯 메커니즘을 정리했다.
점검이 쟁점이 되고,
품질 언어가 범위를 키우고,
역할 배정이 책임 혼선을 만들고,
합의가 기준 공백을 만들고,
추진이 리스크를 숨기는 순간
말은 일을 돕지 못한다.
핵심 해법은 SSM 순서로 말이 완성되게 운영하는 것이다.
다음 단원에서는 이렇게 생성된 문제들이 왜 팀장에게 ‘책임’으로 수렴하는지, 말과 책임이 연결되는 조직의 구조를 더 구체적으로 다룬다.
#팀장의말 #리더십 #조직소통 #조직운영 #ProblemMaking #문제생성 #업무트리거 #쟁점화 #범위팽창 #책임혼선 #기준공백 #리스크은폐 #화술이아닌운영 #SSM #Sense_Structure_Momentum #조건설정 #접점설계