뭔가를 바꿔보고 싶거나 개선하고 싶을 때, 무작정 찾아가 요청하면 100% 거절당한다.
개인적인 요청이나 불만으로 들릴 수 있고, 회사 입장에서는 개인적인 일을 우선순위로 해결해줘야 할 이유가 없다.
처음엔 개발팀에 찾아가서 요청했다.
"이 업무 너무 비효율적인데, 자동화할 수 없을까요?"
지금 진행중인 작업만 해도 벅찬데, 개인적으로 '보이는' 업무 요청을 개발팀에서 해줄리가 없다.
"지금 너무 바빠서 안 돼요"
그래서 상사에게 찾아갔다.
"이거 자동화하면 예산 아끼고 시간도 절약될 것 같습니다."
돌아오는 대답은 당연히 거절.
"그거 시스템 개발하려면 몇 억은 들걸. 안돼"
나는 전략을 바꿔보기로 했다.
내가 설계한 전략은 다음과 같다.
1. 내가 직접 자동화해보기 → 레퍼런스 만들기
2. 팀 전체가 원하게 만들기 → 개인적 요청이 아닌, 공동의 과제
3. 상사의 성과로 만들기 → 결정권자 움직이게 만들기
1. 내가 직접 자동화해보기
개인 PC에서 혼자 자동화를 시작했다. 개발 실력 없던 시절이었지만, 템플릿도 써보고, 주말마다 시간 쪼개서 하나하나 직접 해봤다. 완벽하지는 않아도, 정확히 내가 의도한 기능을 수행했고 실제 내 시간을 절감하는 결과로 만들어냈다. 증명할 수 있는 레퍼런스가 만들어졌다.
2. 팀 전체가 원하게 만들기
상사에게 보고하기 전에 먼저 팀 전체의 공감을 이끌어내는 단계를 설계했다.
공청회를 열었다.
"이 업무 너무 비효율적인데, 같이 아이디어 나눠보면 좋지 않을까요?"
팀 전체에 메일을 보내고, 화상회의를 잡았다.
내가 자동화한 그 업무는 사실 나 뿐만 아니라 모두를 고생시키고 있던 업무였다. 모두가 비효율적이라고 느끼고 있었지만, 딱히 어떻게 바꿔야 할지 몰라서 그대로 방치하고 있던 상태였다.
나는 내가 만든 간단한 자동화 사례를 보여주었다.
레퍼런스를 보여주니, 팀원들도 '이건 진짜 자동화되야 한다.', '정말 됐으면 좋겠다' 와 같은 반응을 보였다.
단순히 문제로 인식하는 걸 넘어서 바뀔 수 있다는 희망과 기대를 품게 된 거다.
3. 상사의 성과로 만들기
공청회 끝나고 보고서를 만들고 상사를 찾아갔다.
"상사님, 제가 이 업무를 자동화했는데요. 저 혼자만 이 업무를 하는 게 아니라, 우리 실에 스무 명이 똑같은 작업을 합니다. 야간에 컴퓨터를 돌려 유휴 자원 활용도 높이고, 오류율도 낮아지고, 긴급 대응도 빨라집니다. 공청회도 열었습니다. 저만의 아이디어가 아니라 팀 모두가 이 문제에 공감했고, 구성원들이 직접 효과를 체감한 개선안입니다. 저희 모두 여기에 몰빵할 준비가 됐습니다. 이 보고서를 상사님께서 발표해주십쇼."
상사 입장에서는 Why not이었다.
명분도 자료도 기대효과도 전부 다 준비되어있는 상태에서 상사는 yes or no 결정만 하면 되는거니까.
그 보고서는 상사의 이름으로 올라갔고, IT 팀에서는 거절할 명분이 사라졌다.
이게 내가 팀 내에서 자동화를 퍼뜨린 전략이다.
정리하면,
혼자 레퍼런스를 만든다.
팀 공감대를 만든다.
상사의 성과로 설계한다.
중요한 건, '나 혼자 고생하고 있다'는 태도로는 바뀌지 않는다는 것이다. 같이 움직이게 설계해야 한다.
상사를 설득하는 대신 상사 자신에게도 이득을 보는 구조로 만들고, 팀원들을 단순한 협력자가 아닌 함께 문제를 해결하고 싶은 사람들로 바꿨다.
나의 경우는 자동화였지만, 다른 분야도 다르지 않다고 생각한다.
결국은 사람과 구조의 문제다.
변화를 가져오고 싶다면,
그 '의지'는 언제나 '전략'과 함께해야 한다.