책임감은 어디에서 오는가?

책임감은 어디에 있나?

책임감이란 “스스로 맡은 일에 대해서 끝까지 완수하려는 의지” 이다.
여기서 중요한 점은 “스스로” 라는 말이다.
자신이 하는 일에 대해서 아무런 권한이 없다면 책임감이 생길까?
누가 시켜서 하는 일이고 자신은 아무런 선택을 할수 없는 입장에서 주어진 일만 해서는 절대 그런 “내면의 상태”에 이르지 못한다.
이런 식이면 “책임감”이라는 단어를 듣는 순간 기분이 나빠지는 것은 어쩔 수 없다.

“어떤 일을 언제까지 완료 해” 라고 명령식으로 이야기하면 그냥 아무렇게라도 하면 그만이다.
그 일의 결과에 대해서 어차피 나중에 또 꾸중을 들어도 할 수 없다고 체념하고 만다.
정말 중요한 것은 하려고 하는 “의지”이며 그것은 명령이나 협박으로 만들어 지는 것이 결코 아니다.
그렇다고 모든 것을 담당자가 알아서 하라고 내버려 두는 것도 문제는 있다.
그 사람과 같이 일해본 경험이 없다면 서로간의 “신뢰”도 부족할 것이다.

이럴 때 사용하는 방법이 일의 완료 조건에 대한 명확한 정의이다.
물론 이때도 서로간에 동의할 수 있는 내용이 포함되어야 한다.
그렇지 않고 “일을 이렇게 해” 라고 이야기 한다면 서로가 서로에 대해 눈치만 보는 상황이 생긴다.
협력이란 그런 눈치보기 게임이 아니다.

“협의”를 하기 위해서는 “말”을 충분히 나눌 수 있는 분위기가 이미 조성이 되어 있어야 한다.
“간담회” 라고 불러 모아 주기적으로 하는 “행사”에서 섣불리 마음 깊은 곳의 말을 꺼내는 사람은 없다.
사람과 사람 사이에서 가장 기본이 되는 것이 “믿음과 신뢰”이다. 그것을 구축하는 것이 책임을 묻는 것보다 항상 앞서야 한다.

• 하지만 믿음과 신뢰는 그 사람의 책임감에서 나온다고도 볼 수 있다.
• 보통은 한걸음 물러나서 내가 먼저 보여주는 방식이 유리하다고 생각한다.

노예는 시키는 일만 할 뿐이다. 주인이 시키지 않는 일들을 할 이유가 없다.
노예처럼 사람을 다룬다면 시키지 않으면 움직이지 않을 것이고 책임감을 강조 할수록 책임이 필요하지 않는 일만 골라서 할 것이다.

---

실패에 대한 책임을 묻기 위해서는 시킨 사람이 일을 제대로 지시했는지와 일을 성공 시킬수 있도록 지원해 주었는지도 조사해야 한다.

“그것도 못해?”, “왜 그것 밖에 안돼?”, “그게 최선이니?”, “책임감을 가져” 등의 이야기를 하더라도 노예는 고개만 숙이면 그만이다.

책임감은 자유의지에 의해 행동하는 사람에게만 물을 수 있다.

어쩌만 정말 자신의 일에 자부심을 느끼는 사람만의 특전일 지도 모른다.

스스로 만든 결과물에 자부심이 없다면 누군가 외치는 “책임감을 가져라” 라는 말은 공허한 듣기 불편한 소음일 뿐이다.

---

책임감에 대한 이야기를 했으니 이제 개발자에게 어떻게 해야 책임감을 가지게 할수 있을까? 이야기 해보자.

• 개발자가 생각하는 좋은 PM 나쁜 PM [ 김영한, 우아한형제들 기술이사, 17분, 2022/07/07 ]

인터넷을 무조건적으로 신뢰하는 것은 좋은건 아니지만 위 영상에 나온 방법은 유용하다고 판단해 소개한다.

개발자에게 책임감을 느끼게 하는 효과적인 방법은

• 동기 유발
• 정책에 대한 이해
• 대강의 개발 시스템을 이해

( 본 글에서는 동기 유발에 대한 이야기만 한다. )

누군가 기획해서 단순히 시키는 업무를 나의 일로 받아들이기는 쉽지 않다.

내 마음을 쓰는 진짜 나의 일이 되어야 재미가 있다.

이는 어떤일을 더 많이 신경 쓰고 고민할 때 더욱 나의 일이 된다.

1. 문제와 이를 해결하기 위한 포인트로 이야기한다.

• 컴퓨터 사이언스는 문제를 해결하기 위해서 생겨났다.
  • 개발자는 문제에 대해서 해결하기를 좋아하도록 발전한다.
  • 컴공은 4년동안 문제를 해결하는 방법에 대해서 공부, 연구한다.
    • 스스로를 문제 해결사로 인식한다.

1. 동기 유발을 위해서 이 일을 왜 해야 하는지를 정말 집요하게 설명한다.

• 그냥 이야기 하는 것은 단순히 업무를 지시하는 것과 별반 다를게 없다.
  • 우리가 마주한 문제가 무엇인지
    • 데이터 기반으로
    • 고객 관점으로
    • 회사의 가치 측면에서 이야기 하자.
      • 듣는이가 공감이 되는 내용이여야 한다….
      • 듣는이가 공감을 못한다면 프로젝트에 정말 필요한 인원인지를 고민하면 어떨까?

1. 개발자로 하여금 자신이 이 프로젝트에 직접적으로 참여하고 있다는 느낌을 준다.

• 내 일을 우리의 일로 만드는 것이 중요하다.
• 내가 의견을 내고 개선할 수 있다는 느낌을 주는 것이 중요하다.
  • 어쩌면 정말 현실은 느낌 수준에서 끝나는 것이 아닐까 느꼈다.

1. 인간적인 유대

• 이런 유대가 있어야 상호 커뮤니케이션을 하는 벽이 줄어든다.
  • 개발자로 하여금 더 많은 피드백이 생기고 본인의 일로 받아들여지게 된다.