피드백은 회사의 문화에 따라 명시적으로 피드백 세션을 갖거나 비상구 혹은 옥상에서 갈구는 형태로 진행하기도 한다. 중요한 점은 어떤 기업이든 피드백은 있다는 것이다. 모두가 하는 일이지만 업무 분장에는 적혀있지 않아서 언제 어떻게 해야 하는지 알기 어려운 요소이기도 하다. 그래서 피드백과 평가를 혼용하는 경우도 많은데 두 개는 다르다. 평가는 주로 연말에 구성원에게 너는 N등급이고, 그렇게 평가한 이유에 대해서 설명하는 시간이다. 그래서 충분히 객관적인 평가라면 굳이 구두로 전할 필요도 없다. 반면에 피드백은 중간중간에 회사 기준과 일치하게 일했는지 아닌지에 대해서 설명하고, 더 나아가서는 기준에 맞게 일할 수 있도록 하는 그라운드 룰까지 만드는 것이다. 예를 들면 문제를 직접적으로 말하길 원하는 회사가 있고, 나이스하게 말하길 좋아하는 회사가 있는데 이런 부분을 회사 기준에 맞춰가는 것이다.
피드백은 커뮤니케이션의 일부로 내용, 형식, 타이밍 세 가지가 굉장히 중요하다. 먼저 내용은 반드시 나의 의견과 예시가 들어가야 한다. 회의에 들어오실 때 미리 전달드린 문서를 읽고 들어오셔야 합니다. 회의 시간에서 15분가량을 어젠다 설명에 할당해 버려서 회의를 제시간에 마무리하지 못했어요. 같은 내용이 들어가야 한다. 혹은 주관적인 이야기도 할 수 있는데, 개발 속도가 너무 느립니다. 일반적인 프론트엔드 개발자가 하루면 끝낼 일을 일주일 동안 잡고 계십니다. 업무 속도를 느리게 하는 일이 있으면 공유해 주세요. 같은 말을 할 수도 있다. 형식의 경우엔 상대방이 수긍하고 변할 수 있도록 올바른 매체를 통해 전달해야 하는데, 상대를 칭찬하는 내용이더라도 슬랙의 공개 채널인지 DM에 따라서, 그리고 구두로 전달하는지 등에 따라 받아들이는 감도가 달라진다. 위 내용 모두를 합친 것보다 중요하게 생각하는 것은 타이밍인데 상대방이 받아들이지 못할 내용이라면 전달하지 않는 것이 낫다. 나는 상대방이 받아들일 수 있는 상태가 아니라고 생각해 문제를 1년 넘게 방치한 적도 있다. 많은 일로 힘들어하는 개발자에게 코드 퀄리티를 높이라거나, 리더로서 챕터 구성원을 키우라는 등의 피드백을 드릴 수 없다. 또한 10개의 문제를 가지고 있는 신입한테 10개를 모두 고치라고 하는 것도 안 될 일이다. 하나씩 해결해 나가면서 이전 피드백에 대해 개선되었다는 좋은 피드백도 주고, 이젠 다음 개선점을 해결해 보자는 식으로 이야기해나가야 한다.
마지막으로 하고 싶은 이야기는 항상 팀원이 잘 되길 바라야 한다는 것이다. 피드백에 진심이 없으면 잔소리로 생각할 수도 있고, 결과적으로 우리가 바라는 대로 변화하지 않을 것이다. 그래서 나는 진심을 전달하기 위해 회사 기준 피드백과 내 피드백을 나눠서 주기도 한다. 회사에선 역량을 조금 더 활용하는 쪽으로 평가하고 있습니다. 저는 회사에게 평가를 위임받았기 때문에 회사 기준으로 연말 평가를 할 겁니다. 하지만 제가 볼 때는 역량 자체를 더 키우시는 게 커리어 성장에 도움이 될 것 같습니다. 당장 연봉을 높이는 것도 중요하지만 연봉과 역량이 일치하지 않는 것도 괴롭습니다. 역량을 키워서 다른 회사에서 높은 연봉을 받는 것도 방법이니 이번 분기에는 역량 성장을 위해 시간을 사용하시는 게 어떨까요? 같은 이야기를 나눈다. 경험적으로 진심으로 대한다면 나중에 더 크게 돌아오곤 했다. 물론 대부분의 사람은 변하지 않고, 돌아오지도 않지만 소수의 사람이 나에게 큰 기회를 주곤 했다.