다섯 줄로 보는 변화 제안
한 관리자가 두 지역 팀이 일상적인 구매를 직접 승인하도록 하자고 제안하고, 동료는 가장 분명한 위험을 지적합니다. 답변은 우려를 인정하고 통제 장치를 하나 더합니다.
듣고 답해 보세요. 시범 운영은 얼마 동안, 몇 개 지역에서 하며, 확대 전에 무엇을 비교하나요? (두 지역에서 6주, 그리고 속도, 번복된 결정, 감사 품질입니다.)
Maya Today I’ll explain why we propose a six-week autonomy pilot in two regions.
Owen I understand the delay problem, but how will local teams interpret risk consistently?
Maya That concern is valid. We’ll standardize evidence fields and audit ten decisions each week.
Owen The pilot might reduce delay, but it could expose training gaps.
Maya Exactly. By the end, we will have compared speed, reversals and audit quality before deciding whether to expand.
책임 있는 예측: 확신의 정도와 미래 표현
변화가 어떻게 전개될지는 아직 아무도 모르므로, 모든 예측에 확신의 정도를 표시하세요. “might”와 “could”는 열린 가능성을 나타내고, “be likely to”, “be certain to”, “be bound to”로 갈수록 확신이 커집니다. “probably”와 “almost certainly”는 “will” 뒤, “won’t” 앞에 옵니다.
한국어의 “-ㄹ 것이다”는 “will”과 “going to”를 모두 나타내지만, “going to”는 눈에 보이는 근거에서 나온 예측입니다. 완료형은 시범 운영을 날짜에 묶어 줍니다.
- “The pilot will probably improve speed but almost certainly won’t remove every error.” – 시범 운영은 아마 속도를 높이겠지만, 모든 오류를 없애지는 못할 것이 거의 확실합니다.
- “Experienced teams are likely to adopt first; removing support is bound to increase risk.” – 숙련된 팀이 먼저 도입할 가능성이 높고, 지원을 없애면 위험은 반드시 커집니다.
- “The missing fields show the team is going to need coaching.” – 빠진 항목을 보면 그 팀에는 코칭이 필요할 것입니다. (눈에 보이는 근거)
- “By mid-June, the pilot will have processed six hundred requests.” – 6월 중순까지 시범 운영에서 600건의 요청을 처리하게 됩니다. (기한까지의 완료)
- “By mid-June, both regions will have been testing delegation for six weeks.” – 6월 중순이면 두 지역 모두 권한 위임을 6주째 시험하고 있게 됩니다. (그 시점까지의 지속)
속도와 성공을 구분하기: 근거의 언어
승인에 36시간이 걸리는데 검토자가 파일 하나에 쓰는 시간이 9분이라면, 지연은 검토 작업이 아니라 대기 시간입니다. 권한 위임은 대기열을 줄일 수 있지만, 그렇다고 결정의 질이 유지된다는 증거가 되지는 않습니다. “hard data”는 수치에서, “soft data”는 의견에서 나오며, 탄탄한(“robust”) 근거는 둘을 교차 확인합니다. 한국어의 효과적과 효율적처럼 “effective”와 “efficient”도 구분해야 합니다.
- “Approval times provide hard data; reviewer interviews provide soft data.” – 승인 시간은 정량 데이터를, 검토자 인터뷰는 정성 데이터를 제공합니다.
- “The control is effective; the nine-minute review is efficient.” – 이 통제 장치는 효과적이고(올바른 결과), 9분짜리 검토는 효율적입니다(시간 낭비가 적음).
- “The plan transforms the workflow and transfers low-risk authority.” – 이 계획은 업무 흐름을 완전히 바꾸고, 위험이 낮은 결정 권한을 넘겨줍니다.
조언하기 전에 우려를 인정하기
먼저 상대의 논리를 이해한다는 것을 보여 주세요. 이해한다는 말이 동의한다는 뜻은 아닙니다. 그다음 상황에 맞는 해결책을 조심스럽게 제안하고, 근거가 뒷받침한다면 입장을 지키세요.
- “I can see where you’re coming from; speed alone is not enough.” – 왜 그렇게 생각하시는지 압니다. 속도만으로는 충분하지 않죠.
- “It might be worth agreeing one definition before Friday.” – 금요일 전에 정의를 하나로 합의해 두면 좋을 것 같습니다.
- “Have you tried pairing each new reviewer with a central auditor?” – 새 검토자마다 본사 감사 담당자를 한 명씩 짝지어 보셨나요?
- “I still think you should cross-check five files from each region.” – 그래도 지역별로 파일 다섯 개씩 교차 확인하셔야 한다고 생각합니다.
발표하고 문서로 쓰기: 여섯 단계, 170–200단어
회의에서는 용어를 정의하고 핵심을 짚어 주세요: “By delegated approval, I mean local decisions below two thousand euros.” “And this is my key point: expansion depends on completeness, not speed alone.” 그다음 문서로 정리해 공유합니다.
- 요청: “This proposal requests approval for a six-week pilot of local purchasing decisions below €2,000.”
- 문제: 대기 시간과 검토 작업량의 차이를 수치로 보여 주기.
- 예측: 가능성이 높은 이점 하나, 불확실한 영향 하나.
- 통제 장치와 담당자, 시작 날짜.
- 한계: “The sample may not represent newer teams.”
- 확대 조건과 회신 방법: “We will decide on expansion only when audited completeness meets the threshold. Please comment by Friday.”
자주 하는 실수
제안서를 지나치게 단정적이거나 모호하게 만드는 실수입니다.
- “The pilot will reduce delay.”를 확실한 약속처럼 쓰기. “is likely to reduce”로 정도를 조절하세요.
- “The pilot won’t probably remove every error.” “probably won’t”가 맞습니다.
- “By June, we will process six hundred requests.” 기한까지의 완료는 “will have processed”로 씁니다.
- 더 빠르다는 뜻으로 “more effective”라고 쓰기. 빠른 것은 “efficient”입니다.
- “Approval time fell, so we should expand.” 지표 하나가 곧 성공은 아닙니다.
하루 15분 연습
직장에서 실제로 바꾸고 싶은 일을 하나 골라 연습하세요.
- 3분: 그 변화에 대해 “might”, “likely to”, “will have”로 예측 세 개를 말하세요.
- 7분: 여섯 단계로 170–200단어 제안서 초안을 쓰세요.
- 3분: 소리 내어 논증하세요. 관리자가 적은 수평적 조직은 직원에게 더 좋은가요, 아니면 회사에 더 저렴할 뿐인가요? “I can see where you’re coming from, but …”으로 시작하세요.
- 2분: 대화를 한 줄씩 따라 말하세요.
다음 단계
다음은 this, that, it이 하나의 대상을 분명히 가리키는 사고 기록, 그리고 팀 간의 의견 차이를 누구도 탓하지 않고 강조 구문으로 기록하는 방법입니다.

