이럴 때

지시가 결정적 해결책 형태로 올 때("정확도를 높여라", "이 결제 수단을 쓰면 된다"). 외부 서비스를 붙일 때. 내 판단이 상대의 제약과 부딪칠 때. 기술 과제로 받아서 바로 성실하게 만들고 싶어질 때가 멈춰야 할 때다.

이렇게

• 지시가 "이렇게 적용하면 된다" 일 때, 정말 그대로 하면 되는지 다시 한번 확인한다.
• 외부 서비스는 API 문서보다 가입 요건을 먼저 봐야한다. 팀이 가입 요건을 충족할까?
• 결제·본인인증·해외 송금은 기술이 아니라 자격에서 막힌다. 팀에 자격이 있는게 맞을까?
• 계획서에는 그 계획의 근거가 어디서 왔는지 확인 후 적는다. 지시를 정말 그대로 수행만 하면 될까?

멈출 신호·예외

"우리가 개발팀이니까" 같은 역할 진술을 근거로 들고 싶어지면 내 판단의 출처부터 의심한다. 성패를 내가 판정할 수 있는 순수 기술 판단이면 되묻지 않아도 된다.

설명

지시는 대개 누군가 이미 고른 해결책이다. 얽힌 문제와 제약은 지시와 함께 오지 않는다. 정확도를 높이라는 요구를 기술 문제로 받아 성실하게 풀었지만, 정확도가 그 제품의 성패를 가르는 변수였는지는 끝내 확인하지 않았다. 쓰라고 받은 결제 수단은 열심히 붙인 뒤에야 우리 팀은 쓸 수 없다는 것이 드러났다.

이 원칙은 내가 내린 결정에도 적용된다. 내 판단이 상대의 제약과 부딪쳤을 때, 기술적으로 더 옳아 보이는 쪽이 내 판단이었지만, 실제로는 조직의 맥락을 아는 쪽이 맞았던 일이 두 번 있었다.

반례

되묻는 것이 항상 옳지는 않다. 도메인 규칙을 깊이 파는 것처럼 성패를 내가 판정할 수 있는 일은 되묻지 않는 것이 맞다.

판별법

"이 결정의 성패를 내가 판정할 수 있는가?"

판정할 수 없다면 묻는다. 무엇을 해결하려는가, 되면 무엇이 달라지나, 우리가 못 갖춘 전제가 있나. 셋 중 마지막이 확인하기 가장 싼데도 가장 자주 빠진다.