해당 글은 벨로그 저자 city7310 님의 글 5개를 참조하였습니다.
상업적 목적은 전혀 없고 너무 좋은 글이라 참조합니다.

안녕하세요
저번에는 리더쉽 관련 세미나를 했었는데 이번에는 "실무자" 버전으로 한 번 가져와봤습니다!

이전 회사에서 저는 실무적인 개발업무를 하기도 했고 개발자를 채용하는 포지션이이기도 했는데요.
그러면 적지 않은 개발자 이력서를 보았습니다. 자기 자신을 표현하는 첫 줄에는 높은 확률로
"저는 함께 일하고 싶은 개발자" 입니다 이거나 혹은 "함께 일하고 싶은 개발자"가 되고싶다 였습니다.

그렇다면 "함께 일하고 싶은 개발자", 비단 개발자 뿐만이 아니라
"함께 일하고 싶은 사람" 은 어떤 사람일까요?

조직마다 자신들의 가치관을 다루는 core value나 Leadership principle 을 장착하고 있습니다
Tesla의 The Anti-Handbook, Netflix의 Culture나 The Rare Responsible Person, Amazon의 Leadership Principles 같은 것처럼 말입니다.

전에 다니던 회사는 완전한 core value 나 leadership principle 이 없었습니다.
회사 문화와 복지, 인재상을 정리해둔 것 노션 페이지를 제가 만들었긴 했지만 조금 추상적이였습니다.

"좋은 동료가 최고의 복지" 라고 많이들 이야기합니다. 그렇다면 좋은 동료는 어떤 사람일까요??

이거 궁금하셨죠?

커뮤니케이션을 잘 해야 한다는 이야기가 많지만, 조금 답답한 주제입니다.
도대체 무엇이 "좋은 커뮤니케이션"을 결정하는 것일까요?

기본적으로 회사 동료는 서로 남이라는 것을 인지해야 합니다.
그러니까 회사 동료를 대할 때 나에게 대하는 것 처럼 하면 안된다는 것이죠.
자신의 상태를 공유하는 것은 협업의 기본입니다. 일이 잘 진행되고 있는지, 장애물이나 위험 신호는 없는지와 같은 것 말이에요.

여기에 더해, 누군가 물어보기 전에 먼저 답을 제출하는 사람이 있습니다. ‘이거 궁금하셨죠?’ 라고 하는 것 처럼요. 이러한 선제적 대응은 커뮤니케이션을 비롯한 대부분의 협업 과정에서 긍정적인 효과를 줍니다.

• ‘작업 어떻게 돼가요?’, ‘앞으로의 계획이 무엇인가요?’ 같은 질문을 받기 전에, 먼저 상황을 공유하는 것

• 피드백이 있을 법한 부분에 본인의 의사결정 흐름을 미리 첨언하는 것

• 확인 여부를 최소한 ✅ 와 같은 이모지로 응답하는 것

• 요청을 언제까지 처리할지, 또는 언제까지 상황을 공유해줄지 ETA를 알려주는 것

• 질문에 대한 시급도를 명시하는 것

옳은 일을 위해 누구와도 대화할 수 있는 사람

예전에 회계팀에서 정장입고 일할 때 막연하게 ‘높은 사람’들을 막연하게 무서워했던 것 같습니다.
회사에 대한 나쁜 환상이 있었던 건지, 나이 차이가 많아서 였는지..
뭔가 문제를 제기하면 혼날 것 같아 자신있게 말하지 못했던 기억이 납니다.
사실 자신있게 말하고 많이 혼났던 기억이 나네요 ㅎㅎ

회사에 있는 사람들은 모두 mission을 달성하기 위해 모인 사람들입니다. 특히 스타트업은 더욱 더 그렇습니다.
눈치보지 않는 것을 넘어서, 회사 전체의 이익을 위해 누구와도 대화할 수 있는 그런 사람이 좋습니다.
옳은 일이 일어나도록 하기 위해 CEO와도 대화할 준비가 되어있는 사람과 함께 일하고 싶습니다.

이 부분은 Tesla의 The Anti-Handbook에 포함된 Communication 항목과도 닿아 있는 것 같습니다.

근거 있는 대화

똑같은 의견이라도 ‘아마 그럴 것 같아요’같은 추정은 근거가 될 수 없습니다.
데이터를 가져와 근거를 보충하고, 우리의 상황에 맞는 실험 결과를 덧붙이는 식으로 의견을 견고하게 만들어야 합니다. 이야기보다 사실을 전달해야 합니다.

그렇게 습관이 만들어지고 나면 옆자리 동료와 대화할 때도 충분한 검증을 거친 주장을 할 수 있게 됩니다. 대화가 붕 떠버려 아무 결론도 안 나는 것보다, 건설적인 토론이 항상 좋습니다.

이런 사람들은 참 소중합니다. 잠깐만 대화를 나눴는데도 혼자 삽질하던 문제가 해결되고, 우리 시스템을 개선할 수 있는 아이디어가 나오곤 합니다.

독성 말투가 없는

비난하지 말라는 이야기가 아닙니다.
개선하려는 시도조차 없이 뒷담을 하거나,
나이를 알고 반말하는 사람들, 말 끊는 사람들, 감정을 드러내는 사람들, …
이렇게 어른스럽지 못한 사람들과는 함께하는 건 좋지 않은 것 같아요.

요지는 커뮤니케이션에 배려를 담자는 이야기입니다.
배려 없는 대화의 핑계로 ‘효율적인 커뮤니케이션을 한다’, ‘나는 컴퓨터랑 대화하는 사람이다’ 같은 말을 들을 때가 있습니다. 그 있잖아요, 드라마나 영화에 차갑고 4가지 없는데 일 잘하는 캐릭터
솔직히 그냥 쏘시오패스거나 무책임한 사람처럼 보입니다.
사회성 문제로 병원을 다닐 정도가 아니라면, 동료와 팀에게 말로 피해를 끼치는 것은 금기시되어야 합니다.

독성 말투는 은연중에 조직에 해를 주게 됩니다. 말 하나에 팀워크가 깨지고, 팀 전체의 사기를 저하시키기도 합니다. ‘말’에 대한 속담이 많은 이유가 있는 것 같습니다.

사실 이것은 독성 말투가 무엇인지를 인지하는 것에서 반은 먹고 들어가는 것 같습니다. 독성 말투라는 게 생각보다 허들이 높기 때문입니다. 다음은 독성 말투의 목록을 정리한 것입니다. 듣는 입장에서 어떻게 들리는지, 그리고 개선된 말투는 무엇인지 이어붙였습니다.

“왜 이렇게 하셨나요?”

듣는 입장 : “도대체 왜 이렇게까지밖에 못 했나요? 이것보다 나은 옵션이 얼마나 많은데?”
개선된 말투 : “이렇게 판단한 이유가 있을까요? 의사결정 과정이 궁금합니다.”

“이해가 안 되시나요?”

듣는 입장 : “제가 이렇게까지 설명했는데도 이해가 안 되는 게 저도 이해가 안 되네요.
얼마나 더 쉽게 설명해드려야 하나요?”
개선된 말투 : “어떤 부분이 어려운지 알려주실 수 있나요? 그 부분부터 좀 더 설명해드릴게요”

“이거 아직도 안 되고 있나요?”

듣는 입장 : “일을 하고는 있는건가요? 혹시 놀고 있는 건 아니죠?”
개선된 말투 : “이 작업이 진행되지 못하고 있는 원인이 있을까요? 어떤 지원이 필요한가요?”

너무나도 직선적인 성격이라 어렵다면, 그냥 말 앞에 ‘혹시’만 붙여줘도 문장이 훨씬 부드러워집니다. “혹시 왜 이렇게 하셨나요?”, “혹시 이해가 안 되시나요?” 처럼 말입니다.

기본적으로 내가 잘못했을 가능성을 기저에 깔아놓고 대화해야 한다고 생각합니다. 과거에 "왜 기계 데이터 프로토콜 협업회사 개발팀에게 전달 안했냐" 라는 말을 들었던 적이 있습니다. 그러나 저는 어떠한 이메일도 받은 적이 없었고, 알고 보니 기획팀이 저에게 CC 를 안 걸어서 전송되지 않았던 것이었습니다.

신경질은 낼 수 있다고 봅니다. 오늘따라 일이 참 안 풀리는데, 오늘따라 다들 나를 찾으면 힘들긴 합니다.
그런데 그게 기본값인 사람들은 당연히 좋지 않습니다.
감정을 숨기고 이성으로 배려를 담아 대화하는 것, 적어도 그러려고 노력하는 사람이 좋습니다.

안 되는 이유보다, 되게 하려면 필요한 리소스를 제시

안 된다는 말은 가장 마지막에 나와야 합니다.
새로운 아이디어를 어떻게 만들어낼 수 있을 지 고민하는 것이 당연히 먼저입니다.
본능적으로 안 되는 이유부터 생각하는 사람들은, 일 하기 싫어 핑계대는 사람으로 보입니다.

‘안 되면 되게 하라’는 말이 있습니다. 가혹하게 들릴 지 모르겠지만, 안 되는 걸 열심히 비틀어서 어떻게든 되게 만드는 사람은 영웅과도 같습니다.
또한, 일을 되게 만들기 위해 팀원 모두 도와줄 준비가 되어 있어야 합니다.

기획자가 원하는 아이디어를 그대로 만들어내는 것은 당연히 어렵습니다.
구현 난이도가 높거나 우선순위 문제로 일정을 못 맞출수도 있고, 기술적인 문제로 기획자가 원하는 퀄리티가 나오지 못 할수도 있습니다.

이런 문제는 대화를 통해 원만하게 해결되곤 합니다. 기획자는 기술적인 세부 사항에 대해 완벽히 알지 못하므로, 구현 난이도를 측정하기 어렵기 때문입니다. “이래저래 해서 어려워요” 하면, “아 정말요?! 그렇게 구현이 어려운 기능인지 몰랐어요. 이건 그냥 spec-out 해도 돼요” 같은 답변을 받았던 기억이 많습니다.

일이 되게 만들기 위해 어떤 리소스나 변화가 필요한지를 제시하고 얻어내는 사람이 좋습니다.
때로는 설득도 필요하고, 토론도 필요합니다.
그런 과정을 거쳐 어떻게든 결과물을 만들어낼 수 있게 준비하는 모습은 정말 프로정신이 강한 사람으로 느껴집니다.

꽤나 강조하고 싶은 역량입니다. 작업이 시작되기 전부터 머리를 핑핑 돌리며 견적을 내서 대략적인 일정을 내놓고, 설득을 위한 커뮤니케이션이 되는 사람이면, 세세한 코칭 없이 일하게 해도 되겠다는 생각이 들기 때문입니다. 신뢰하는 만큼 자유를 부여하게 되는데, 이런 사람들은 자유를 얻기도 쉽습니다.

문제를 해결하고 나면, 원인을 파악하고 재발방지

“이 코드 누가 짰어!”

무서운 말입니다. 범인을 찾으려는 행동입니다.

문제가 발생했을 때 개인의 실수를 비난하지 않고, 실수가 발생하지 않는 시스템을 만드는 데에 집중하는 포스트모텀(postmortem) 문화가 필요합니다. 포스트모텀에 대해서는
"사고를 쳐도 혼나지 않는 회사라는 글"을 읽어보면 좋을 것 같습니다.(링크있습니다)

소프트웨어 개발은 모든 행동에 리스크가 있는, 위험이 도사리는 분야입니다. 마음가짐이나 규칙같은 것으로 문제를 방어하려는 것은 정말 위험한 행동입니다. 문제가 발생하는 것은 사람의 역량 문제라기보단 시스템의 문제라고 봐야 합니다.
‘실수한 게 당당하고 자랑이냐’고 하면 물론 아닙니다.
조심해야 하는 건 맞지만, 소프트웨어 시스템은 겨우 조심하는 정도로 방지가 되는 복잡성이 아니라서 그렇습니다.
범인을 찾고 사람을 타박하는 분위기에서는 팀이 100%의 역량을 발휘하기 어렵습니다.

“죄송합니다”는 사람의 기분을 풀어주기 위한 말입니다. 아무리 사과해도 소프트웨어는 바뀌지 않습니다. 중요한 건 재발 방지입니다. 실수를 했다는 것은 개인적으로 아쉽고 분한 일입니다. 하지만, 나중에 동료가 똑같은 실수를 하지 않게 만드는 것이 이상적인 모습입니다.

‘앞으로 안 그래야지’하고 마음먹기만 하는 사람보다, 재발 방지를 위해 노력해본 사람과 함께 일하고 싶습니다.

동료의 피드백으로 자신을 평가하는 사람

Co-worker, 동료 로서의 잘잘못은 ‘남이 보는 나’를 통해 평가하는 것이 좋습니다. 속히 말해 눈 가리고 귀 막는 사람들은 받아들이기 어려운 것 같습니다.

주변에서 ‘잘 했다’고 해도, 그렇게 생각하지 않고 자기 자신을 채찍질하는 사람이 있습니다. 최고 점수를 받아도 그동안의 성과 때문이라고 생각하질 않습니다. 자신이 기대를 받고 있는 것으로 받아들이고, 앞으로 더 잘하라는 격려로 받아들이곤 합니다.
이건 그래도 괜찮습니다. 제 주변에도 이런 동료들이 있는데, 달려나가는 걸 가로막을 수는 없으니 지치지 말라고만 응원해주고 싶습니다.

반대로, 주변에서 ‘못 했다’고 해도 그것을 자신에 대한 공격으로 받아들이고 꽁꽁 숨어버리는 사람이 있습니다. 당연히 부정적인 피드백은 아픕니다. 앞으로의 업무에 있어서 멘탈 관리를 위해 잠깐 방어적으로 생각하는 것은 괜찮지만, 결국은 발전을 위해 납득해야 하는 소중한 의견들입니다.
아무리 남이라고 해도, 동료에게 부정적인 피드백을 전달하는 것은 쉽지 않은 일이기 때문입니다.
피드백은 누군가의 의욕을 저하시키기 위함이 아니라, 다 같이 잘 하기 위함이라는 것을 인지해야 합니다.

Strong View, Weakly Held, Followership

We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress!
우리는 가능한 한 빨리 틀렸음을 증명하려고 노력합니다. 그래야만 발전을 찾을 수 있기 때문입니다.

노벨 물리학상을 수상한 리처드 파인만의 명언입니다. 대부분의 조직은 가장 나은 방법을 찾고자 토론을 합니다. 여기서 토론이 올바른 방향을 찾아가기보다, 자신의 의견이 채택되는 것을 더 중요하게 여기는 사람이 있습니다.

자신이 낸 의견이 채택되지 못하면 아쉽습니다.
덜 기여한 것 같고, 도움되지 않는다는 생각이 들기도 합니다.
자신의 의견이 완벽하다고 굳게 믿고 있었다면 조직에 대한 신뢰를 의심하게 되기도 합니다.
‘이렇게 좋은 의견을 받아들이지 못 하다니’ 하며 조직의 수준에 의문을 갖습니다.
합당한 이유가 있어서 반려된 것인데도 말입니다.

하지만 협업에 있어서는, 이렇게 방어기제가 발동하는 것은 좋지 않습니다.
내 의견이 좋아보이는 것은 확증편향과 관련되어 있습니다.
자기 생각과 일치하는 정보만 받아들이고, 다른 생각은 배척하는 심리입니다.
의견이 신념이 되어버리기 전에, Weakly Held할 수 있도록 태도를 바꿔야 합니다.

좋은 동료들은 의견을 최초로 제시하기까지 오랜 시간을 갖습니다.
그리고 의견을 제시한 뒤에는 근거를 더 뒷받침하려고 하지 않습니다.
대신 다른 의견, 되도록이면 자신의 것과 상반되는 의견의 근거를 찾아보는 과정을 거칩니다.
그렇게 학습하고 나면 생각을 고수할지, 생각을 바꿀지 결정합니다.

무조건 양보하라는 것은 아닙니다.
자신의 의견에 자신감을 갖고 주장하는 것은 당연히 좋고, 자신감이 생길 만큼 충분한 논거를 쌓는 것은 의무라고 생각합니다(Strong View).
그러나 토론에서는 내 의견과 남의 의견을 나누어 생각하는 것보다, 주어를 빼고 모든 의견이 단순한 선택지라고 생각하는 모습이 필요합니다.
자기 의견의 근거를 찾아보는 만큼, 다른 의견의 근거를 찾아봐야 더 객관적일 수 있습니다(Weakly Held).

근거가 바뀌면 의견도 바꾸는 유연한 모습이 있어야 합니다.
생각이 자주 바뀌는 것을 나쁘게 생각할 필요는 없다고 봅니다.
가설로 채워야 하는 부분이 있기에, 의견이 갈리는 것은 당연합니다.
때문에 처음부터 100점짜리 정답을 찾아낼 수는 없습니다.
‘이런이런 근거 때문에 내가 생각을 바꿨다’로 마무리되는 토론이 바람직하다고 생각합니다.

토론이 끝나면 그 결과에 관계 없이, followership을 가지고 일이 잘 될 수 있도록 지원하는 사람이 좋습니다. 팀 플레이어로서 꼭 필요한 역량입니다.
선심쓰듯 양보하는 것 처럼 한다거나,
자기 의견대로 안 됐다고 토라져 아무 도움도 안 주다가,
그 방법이 틀렸다는 것이 드러나면 ‘거 봐라’ 하는 모습은 정말 보기 안 좋습니다.

‘내가 틀리진 않았을까’ 생각하며, 자기 자신과의 토론을 해왔던 사람이 이런 부분에서 좋은 모습을 보여주는 것 같습니다. 애초에 양질의, 정답에 가까운 의견을 내기도 하고 말입니다.

선의의 경쟁

회사가 성장하는 속도와 개인이 성장하는 속도는 확연하게 다릅니다.
당연히 회사가 성장하는 속도가 더 빠릅니다. 우리들이 으쌰으쌰해서 회사가 엄청 성장하고
돈을 더 벌면 회사는 그 돈으로 지금 우리보다 더 높은 값어치의 인원들을 고용합니다.

팀의 평균 수준을 상회하는 동료가 들어올 때마다, ‘저 사람이 금방 나를 대체할 수 있겠다’ 같은 생각이 들 수도 있습니다.

이때 새로운 동료와 경쟁하려 하지 마세요.
퍼포먼스를 내지 못 하게 상대방을 견재하는 태도는 전혀 프로답지 못합니다.
동료에게 과하게 높은 챌린지를 주문하거나, 아이디어를 실행한 공을 독차지하려 욕심부리거나, 조력자의 도움을 감사하게 여기지 않고 혼자 빛나려는 사람들처럼 말입니다.
다른 사람을 빛을 밟아 자신의 빛만 빛나도록
자존감을 채우는 사람과는 함께하고 싶지 않습니다.

물론 어려운 일입니다. 내가 3년 혹은 5년동안 열심히 키운 내 프로젝트인데, 새로 들어온 능력좋고
탁월한 동료가 왈가왈부하면 머리로는 이해해도 마음으로는 힘들 수 있습니다.
그래도 받아드려야 합니다.

아무리 경쟁심리 없는 사람이라도, 남들보다 뒤처져있는 걸 편하게 느낄 사람은 없습니다. 잘 하는 사람이 주변에 널려 있으면 자존감이 많이 내려갑니다.

재능의 차이를 빠르게 인정하고, 자신의 capacity 안에서 할 수 있는 최선을 하다 보면 나아지는 것 같습니다.
과도하게 열심히 할 것도 없고, ‘매일 1%씩 나아진다’ 같은 말처럼 습관화된 의식적 연습이 성장을 불러왔던 기억이 납니다.

우수한 사람이라면, 혼자 고고하게 잘나려고 하기보다 모두가 잘할 수 있도록 만들어주는 사람이 좋습니다.
팀워크를 위해, 그리고 서로가 자존심 싸움이 아닌 성장을 위한 진짜 경쟁을 할 수 있게 말입니다.

거짓말하지 않는 사람

다들 회사에서 어떻게 거짓말을 하나 싶으시죠?
하지만 거짓말은 빈번하게 일어납니다.
어려운데 이해했다 하고,
어렵다고 말하지 못 하는 것,
나쁜 소식을 전달하지 않고 숨기는 것
모두 거짓말입니다.
자신의 상태를 숨김 없이 정확히 이야기하는 것은 협업에 정말 중요합니다.

소프트웨어도 그렇듯, 모든 수정과 교정은 나중에 일어날 수록 비용이 높습니다. 설명해준 지 한 달이 지나 “사실 잘 모르겠어요” 하면, 답변자 입장에서도 당시의 내용을 꾸역꾸역 찾아내 머리로 다시 떠올려야합니다. 서로 불편한 상황이 발생하는 것입니다.

참조: