소통의 문화 이해하기
관리자가 아닌 파트너 되기
회사에서 어려움을 겪고 있는 직원과 높은 성과를 내는 직원이 있을 때 누구에게 관심을 가져야 할까? 일반적인 관리자는 어려움을 겪고 있는 직원에게 더욱 관심을 가질 것이다. 하지만 냉정하게 생각하면 높은 성과를 내는 직원에게 관심을 주는 게 회사 전체 성과를 향상하는 데 도움이 된다. 우수한 직원에게 주는 관심과 격려는 더욱 좋은 성과를 끌어낼 수 있다. 우리가 뽑은 개발자들이 새로운 서비스 구축을 완료했거나 우수한 성과물을 내었다면 어떻게 해주면 좋을까? 이들은 회사를 위해 많은 노력을 했으므로 격려와 칭찬, 그리고 보상까지 해주는 것이 좋다. 만일 곤란을 겪는 직원들을 보살피느라 우수한 성과를 낸 직원을 소홀히 한다면 어떻게 될까? 높은 성과를 낸 직원으로서는 회사에 상당한 기여를 했음에도 홀대받는다고 생각할 것이다. 혹은 역차별이라고 생각할 수도 있다. 반면 사소한 부분을 일일이 간섭하고 통제하여 모두를 피곤하게 한다면 어떤 결과를 가져올까? 너무 많은 간섭과 억압은 역효과를 불러올 수밖에 없다. 우리가 소중하게 뽑은 개발자들에게 지나친 간섭 또는 무관심을 보여주어서는 안 된다. 적절한 관심과 배려를 통해 동반자가 되는 것이 좋다. 특히, 우수한 성과를 낸 개발자에게는 적극적인 보상과 격려를 잊지 말아야 한다.
우수한 직원은 모두 좋은 평가를 받을 수 있게 하라
성과평가는 기업 입장에서 반드시 필요하다. 일반적인 기업에서는 성과평가 시 상대평가를 활용한다. 하지만 많은 직원은 이러한 성과평가 체계가 잘못되었다고 생각할 수 있다. 특정 부서나 집단이 유리하도록 성과평가가 설계될 수 있기 때문이다. 한 설문 조사에 따르면 미국 직원 중 71%는 성과평가의 공정성에 문제가 있다고 생각했다. 이렇듯 누구나 만족할 수 있는 성과평가 제도를 만들기란 정말 어려운 일이다. 그렇다면 개발자를 평가할 때는 어떤 방식을 활용하는 것이 좋을까? 개발자 평가를 객관적으로 하기 위해서는 성과를 정량화해야 하는데 이것이 어려운 경우가 많다. 과거에는 얼마나 회사에 오래 앉아있는지, 야근은 얼마나 했는지 등으로 직원을 평가하던 시절도 있었다. 하지만 시대가 바뀌었고 요즘 이렇게 했다가는 난리가 날 것이다. 가장 객관적으로 평가하기 위해서 평가 기준을 마련해야 하나 모두가 인정할 수 있는 기준을 만들기가 쉽지 않으므로 다음과 같은 방법을 추천한다. 팀 전체가 열심히 하여 성과를 올린 경우 팀, 혹은 직원 모두에게 높은 점수를 부여하는 것이 좋다. 줄 세우기 식 평가가 아닌 절대평가 방법을 활용하는 것이다. 마이크로소프트에서는 직원 개개인에 대한 평가보다는 협력을 통한 성과 창출에 중점을 둔다. 혼자 하는 업무보다 협력을 통한 업무가 더욱 큰 효과를 낼 수 있기 때문이다. 이러한 점수 평가가 보상으로 이어지면 더욱 효과적일 것이다. 팀 위주의 공평한 평가 제도를 통해 개발자들은 순위에 연연하지 않고 본인의 동기를 기반으로 각자의 자리에서 최선을 다할 것이다. 이것이 협력으로 연결되고 우리 회사의 성과로 이어지는 것은 당연하다.
개발자의 전문성을 인정하고 활용하라
개발자들이 가진 전문성이 많이 발휘될수록 좋은 서비스가 나올 확률이 높아진다. 이들이 가진 전문성을 충분히 이해하고 격려하는 것이 좋다. 특정 부서에서 개발 업무를 담당하는 시니어 급의 개발자가 있다면 이들의 전문성을 충분히 발휘할 기회를 제공해야 한다. 회사의 중요한 의사결정에 참여시킬 수도 있고, 교육 부서에서 다른 개발자들에게 지식을 전수할 수도 있다. 사실 전문가는 다른 사람에게 본인의 지식을 전달할 때 가장 빛난다. 따라서 직원 교육을 위해 엉뚱한 직원을 뽑아 회사를 망치는 것보다는 내부에서 오랜 경력을 가진 개발자의 전문성을 활용하는 것이 바람직하다.
개발자들을 존중하라
개발자들이 가치 있다고 느끼는 방향으로 개발 및 업무를 수행할 수 있도록 해주자. 앞서 언급한 바와 같이 개발자가 본인이 하는 일에서 의미를 찾을 수 있도록 도와주어야 한다. 또한, 개발자들은 일반 직원들과는 다른 성향을 갖고 있다는 것을 이해해야 한다. 이들이 과거의 경험을 기반으로 의사결정을 할 때도 존중해주는 것이 필요하다. 경력직으로 입사한 개발자는 이전 회사에서 다양한 업무를 경험했기 때문에 효율적인 업무 방법을 잘 알 수 있다. 이들이 효율성 향상을 위해 제시하는 의견들을 적극적으로 수용하고 업무에 반영하는 것이 좋다. 이들은 회사에서 인정 및 존경받는 개발자가 된 듯한 느낌을 받을 수 있을 것이다. 이는 결국 각자 분야에서 오랫동안 근무할 수 있는 환경을 조성해주는 방법이다.
지속적인 도전 기회를 주어라
개발자들은 학습에 대한 욕구가 매우 강하다. 이들이 끊임없이 배울 수 있도록 도움을 주어야 한다. 이 학습은 업무와 직접적인 관련이 있을 수도 있고, 그렇지 않을 수도 있다. 이들이 기술 습득을 위해 도서 구입을 원하거나 강의, 세미나에 참가하고 싶다고 하면 언제든 아낌없이 지원해야 한다. 또한, 이들의 새로운 도전을 적극적으로 장려해야 한다. 새로운 서비스를 만들 때 이런저런 시도를 해보곤 하는데, 개발자들은 이러한 시행착오를 통해 경험을 쌓고, 이것이 실력으로 이어진다. 이러한 다양한 시도와 도전을 팀원들에게 공유하고 서로 장려하는 문화를 만들어야 한다. 개발자에게 다양한 방법으로 도전 기회를 주는 것은 매우 중요하다. 이는 개발자가 우리 회사에서 ‘일의 의미’를 찾을 수 있도록 도와주는 것이며 결과적으로 회사의 서비스 품질 향상과 연계되기 때문이다.
다양한 스타일로 팀과 소통하는 방법
우리는 개발자 개인 혹은 팀과 주기적인 소통을 해야 한다. 이들이 하는 말을 귀담아들어야 어떤 문제가 발생할지, 해결은 어떻게 해야 할지를 알 수 있다. 우선 업무에 관한 소통이 필요하다. 매주 할 수도, 격주로 할 수도 있다. 주기는 회사 사정에 맞춰서 진행하면 된다. 그렇다면 어떤 소통 방식을 활용하는 것이 좋을까? 여러 방식이 있을 수 있는데 그중 팀원들이 선호하는 방식으로 진행하는 것이 좋다. 업무에 관한 미팅이 필요하면 공식적인 팀 회의를 통해 현재 프로젝트의 진행 상황, 지난 미팅 후의 피드백 결과 확인, 향후 개발 일정에 관한 이야기를 심층적으로 하는 것이 좋다. 무겁지 않은 형식으로 회의를 하면 훨씬 가벼운 마음으로 참석할 수 있을 것이다. 개발자가 느끼는 어려움에 대해 주기적으로 소통하는 시간도 필요하다. 개발 진행에 어려움이 있다면 적극적으로 공감해줘야 한다. 프로젝트를 수행하면서 시간이 많이 소요되는 부분, 복잡한 부분, 잘 해결되지 않는 부분 등의 내용을 자유롭게 이야기할 기회를 제공하고, 회사는 이에 대해 깊게 이해하고 공감을 표현하는 것이 좋다. 이를 통해 개발자들은 회사에 대해서 더 깊은 신뢰를 하게 된다. 이러한 문화가 회사의 발전에도 긍정적인 영향을 줄 것이다. 인간 관계를 강화할 수 있는 소통의 시간도 필요하다. 회사의 동료이지만 서로의 인간적인 모습을 이해할 수 있는 시간이 될 것이다. 업무적인 대화보다는 개인적인 관심사 위주로 소통하는 것이 좋다. 자전거에 관심이 많다면 자전거 여행 코스, 자전거 구입법 등을 주제로 대화를 진행하면 인간적으로 더욱 친밀해질 수 있다. 이러한 친밀감은 회사에서 업무를 추진할 때 인간적으로 진행할 수 있게 만들어준다. 당연히 회사의 성과 향상에도 기여할 수 있을 것이다. 서버 컴퓨터 기업인 엑세스랩은 어떤 방법으로 소통할까? 엑세스랩에는 회식이 따로 없다. 대신에 상반기, 하반기 워크숍을 열어서 회사 문화를 함께 만들기 위해 노력한다고 한다. 또한, 회사 대표와 카카오톡, 슬랙 등의 채널을 통해 커뮤니케이션을 수행한다고 한다. 이를 통해 회사의 어느 직원도 대표에게 다양한 의견을 건의할 수 있는 것이다. 식사는 회사에서 비용을 지급하고 함께 먹는 문화를 권장한다고 한다. 식사하는 자리에서는 개인적인 이야기를 많이 하므로 서로 더 친해질 수 있는 계기가 되기 때문이다. 특정 개발자 1~2명이 특별하다는 느낌을 주지 않으려고 노력한다고도 한다. 비 개발자 직원도 개발 회의에 함께 참여하게 하고 관련 내용을 알기 쉽게 설명하여 전체 업무 흐름에 대해서 이해도를 높인다고 한다. 이런 시도는 개발 업무가 특정인이 하는 것이 아닌, 회사 전체에서 함께 하는 업무라고 생각하게 되어 서로 간의 팀워크를 높이는 장점이 있다.
상호 간 피드백 문화 정착하기
지속적인 피드백이란 무엇일까? 개발자가 하는 일에 계속 간섭하는 것인가? 아니면 지금 하는 일이 긍정적으로 흘러갈 수 있도록 지속해서 도움을 주는 것인가? 사실 피드백, 성과평가 등은 개발자들이 좋아하지 않는 단어이다. 그렇지만 조직의 발전을 위해서 피드백은 반드시 필요하다. 그러므로 상호 간에 피드백하는 방법을 아래와 같이 다양하게 시도해보는 것이 좋다. 피드백은 긍정적인 피드백과 잘못된 점을 바로잡는 피드백(이하 개선점 피드백)이 있다. 당신이라면 어떤 피드백을 듣고 싶은가? 내가 밤을 새워서 프로젝트의 일부를 완성도 높게 끝낸 경우, 해당 업무에 대해 긍정적인 피드백을 받게 되면 기분이 어떨까? 긍정적인 피드백은 받는 사람과 주는 사람 모두가 기분 좋아진다. 피드백을 주는 사람 입장에서는 개선점 피드백보다 말을 꺼내기 훨씬 쉬우니 그 효과는 몇 배가 된다. 다만, 잘하지 않았는데도 억지로 긍정적인 피드백을 줄 필요는 없다. 개선점에 대한 피드백도 반드시 필요하다. 사람은 일하다 보면 분명 실수를 할 수 있다. 본인만의 스타일대로 개발과 업무를 하다 보면 빠진 부분도 있을 수 있다. 이를 제때 바로잡아 주지 않으면 나중에 이것을 고치는데 시간이 더 걸리게 된다. 반면 적시에 피드백을 해주면 빠른 개선을 통해 우수한 결과물이 나올 확률이 높아진다. 이러한 지속적인 피드백을 위해 가장 중요한 것은 무엇일까? 개발자 개개인에 대해 소통하고 이해하려는 노력이 필요하다. 즉, 꾸준한 관심을 가지고 이들이 어떤 상황에서 업무를 하는지, 어려움은 없는지를 주기적으로 파악해야 한다. 그러면 개개인에 대한 피드백을 더욱 객관적으로 수행할 수 있으며 성과 향상에도 큰 도움을 줄 것이다.
수평적인 문화 사례
개발자들은 서로 협력하며 일을 하기도 하지만 독립적인 공간에서 일하는 것을 더욱 선호한다. 이러한 문화는 개발자들이 수평적인 문화를 좋아한다는 것을 대변한다. 최근 많은 기업들은 부장, 팀장, 과장 등으로 이어지는 수직적인 문화에서 탈피해 직급 없이 모두가 같은 직급을 갖는 수평적인 문화로 바꾸고 있다. 교육 플랫폼을 운영하는 클래스101이라는 스타트업은 사장부터 직원까지 모두 반말(평어)을 사용한다고 한다. 서로 간의 호칭은 별명을 부르며 직급은 대표와 부대표만 있고, 다른 직원들은 모두 리드라는 직책으로 불린다. 이러한 독특한 기업 문화는 더욱 창의적인 아이디어와 자유로운 의견 개진이 가능하여 기업 내 수평적인 문화 형성에 도움을 준다. 모바일 헬스케어 스타트업인 힐링페이퍼는 서로를 부를 때 각자 정한 호칭(닉네임)을 쓴다. 각 팀의 리더가 있지만 업무가 수직적이지 않고 수평적으로 진행된다. 시니어의 의견만 중시되는 것이 아니라 주니어 개발자들의 아이디어도 적극 반영한다. 주니어 개발자가 좋은 아이디어를 제시하면 시니어 개발자는 격려와 더불어 개인 프로젝트로 진행할 수 있도록 지원해준다. 또한 채용 과정에서 상급자들의 의견보다는 같이 일할 팀원들의 의견을 더욱 중요시한다. 각 팀에서 이력서를 검토 후 의견을 내면 이들의 결정을 가장 중시하여 채용을 진행한다고 한다. 카쉐어링 기업인 쏘카는 이름 대신 닉네임을 사용하고 있으며 수평적인 문화 정착에 앞서고 있다. 신입 개발자가 적극적인 의견을 내는 것도 장려하는 분위기이다. 이들은 번뜩이는 아이디어를 쏟아내 회사의 문화를 수평적으로 바꾸는 데 일조하고 있다. 예시로 든 기업 말고도 많은 기업들이 수평적인 문화를 만들고자 노력하고 있다. 우리 회사가 수직적인 문화를 갖고 있다고 판단한다면 지금 당장 개선을 위한 노력을 시작해야 한다.
신뢰 관계 만들기
신뢰 관계 형성의 중요성
어제 입사한 개발자에게 갑자기 “여자 친구는 있어요?”, “이번 주말에 뭐해요?” 등의 개인적인 질문을 하면 그는 어떤 생각을 할까? “별로 친하지도 않은데 왜 저런 질문을 하지?”라고 생각할 수 있다. 개인적인 질문은 서로의 신뢰 관계가 어느 정도 형성된 이후에 하는 것이 자연스럽다. 사람 간의 신뢰 관계는 하루아침에 만들어지지 않는다. 신뢰 관계는 시간에 어느 정도 비례한다고 할 수 있다. 이는 꾸준한 관계 유지와 상호 존중, 각자의 행동 패턴 등 다양한 요소들을 기반으로 형성된다. 이러한 관계는 처음에 형성하기는 어렵지만 한번 형성되면 쉽게 무너지지 않는다. 회사 내에서 개발자와 신뢰 관계가 형성되면 이 고리는 아주 단단해진다. 개발자들은 회사와 형성된 신뢰 관계를 바탕으로 ‘일의 의미’도 쉽게 찾을 수 있을 것이다. 개발자들이 높은 신뢰 관계를 기반으로 업무에 임한다면 회사의 생산성은 자연스레 높아질 것이다. 카쉐어링 기업 쏘카는 작은 성공사례를 기반으로 신뢰 관계를 형성하였다. 쏘카에서 처음 개발팀을 운영할 때에는 팀이 1개밖에 없어서 협업할 일이 없었다. 지금은 5개 규모의 부서를 운영하며 서로의 팀과 협업을 진행하고 있다고 한다. 개발자들은 작은 프로젝트부터 함께하며 점점 큰 프로젝트로 규모를 키워가며 상호 간 신뢰를 형성했다. 작은 프로젝트부터 성공을 경험하며 회사 및 동료들과 자연스레 신뢰 관계를 형성하게 된 것이다. 이렇듯 개발자들이 성공할 수 있는 다양한 기회를 제공하는 것도 회사의 역할이다. 이러한 신뢰 관계를 만들어나가는 데 중요한 역할을 하는 것은 무엇일까? 바로 팀워크다. 큰 규모의 기업은 팀워크를 객관적으로 평가할 수 있는 시스템이 있지만 작은 규모 기업은 이러한 시스템을 갖추기가 쉽지 않다. 규모가 작은 회사에서는 우수한 역량을 가진 개발자가 혼자 개발하는 것보다 전체 팀이 평균 이상의 성과를 내는 것이 더 중요하다. 실제로 이렇게 서로 이해하고 함께하는 팀워크를 구성했을 때 회사의 성과는 좋아지게 된다. 이러한 팀워크가 좋아지게 하려면 어떻게 해야 할까? MZ세대라고 불리는 요즘의 젊은이들을 상대로 예전처럼 회식을 많이 한다고 팀워크가 좋아지지 않는다. 또한, 회사가 성장해야 개인이 성장한다는 말도 통하지 않는다. 예전에는 내가 협력을 잘해야 회사가 발전하고 개인이 성장할 수 있다는 인식이 강했다. 지금 세대는 반대로 내가 성장해야 회사가 발전한다고 생각한다. 이러한 세대의 특성을 먼저 이해하고 이를 기반으로 팀원들과 업무를 해야 한다. 이들과 팀워크가 좋아지는 중요한 미덕은 소통이다. 쉽게 말하면 회사 대표는 항상 신입 사원의 새로운 제안을 받아들일 준비가 되어있어야 한다. 다양한 방법으로 소통하면서 이들과의 신뢰 관계를 구축하면 결과적으로 좋은 팀워크와 회사의 성과로 이어지게 된다.
개발자들이 자유롭게 일하도록 하라
신뢰 관계 구축에 전혀 도움이 되지 않는 행동은 회사 내에서 권한을 행사하려는 것이다. 회사에는 대표나 이사, 팀장 등 주요 결정 권한을 가진 사람들이 있다. 신뢰 관계 형성을 위해 이들이 가진 권한을 어느 정도 내려놓을 필요가 있다. 누구나 이런 권한을 누리고 싶어 할 것이다. 하지만 이러한 권한에 초점을 맞추면 조직이 건강해질 수 없다. 권한보다는 관계에 초점을 맞추어야 한다. 구글은 대표적인 개발자 중심의 회사이다. 구글에서는 관리자들이 가진 일방적 권한을 내려놓도록 했다. 그리고 직원의 관리보다는 관계에 초점을 맞추었다. 구글이 내놓은 ‘좋은 관리자가 가져야 하는 8가지 조건’을 보면 어떤 관리자가 개발자에게 좋은 관리자인지 잘 알 수 있다.
좋은 관리자가 가져야 하는 8가지 조건
- 좋은 코치다.
- 팀에게 권한을 양도하며 마이크로 매니지를 하지 않는다.
- 팀원의 성공에 관심을 표명하며 개인적 삶에도 관심을 기울인다.
- 생산적이며 결과를 중심으로 사고한다.
- 훌륭한 커뮤니케이션 능력을 가지고 있다.
- 팀원들이 경력을 키워나가도록 도움을 준다.
- 팀을 위한 명확한 비전을 가지고 있다.
- 팀에게 조언을 해주기에 충분한 기술적인 능력을 갖추고 있다.
이를 간략하게 설명하면 개발자들을 사소하게 통제하려고 하지 말고, 이들이 스스로 결정 권한을 갖고 자유롭게 일을 할 수 있도록 믿고 맡기라는 것이다. 쉽게 말하면 관리자의 권한은 최소화하고 개발자들의 자유를 극대화하는 것이다. 개발자들이 편하게 일할 수 있는 환경을 만들어주고 이들이 회사에서 자유롭다는 느낌을 받게 해야 한다. 개발자에게 자유를 준다는 것은 마음대로 하라는 얘기가 아니다. 자유가 있으면 책임도 있기 마련이다. 일을 하는 방법, 소통 방법, 근무 방법 등에서 회사에 얽매여 있다는 생각이 들지 않도록 해주는 것이 좋다.
개발자와 올바른 방법으로 소통하라
개발자들과의 신뢰 관계 구축을 위하여 가장 중요한 건 주기적인 소통이다. 업무를 수행하다 보면 여러 상황에 부닥치기 마련이고 회사에 요구해야 할 것도 많아진다. 이러한 이야기를 들을 수 있는 시간을 따로 만드는 일은 쉽지가 않다. 하지만 일부러라도 주기적인 대화 시간을 만들어야 한다. 일대일 형식도 좋고 일대다 형식도 좋다. 각 기업의 문화가 다를 것이므로 어떤 형식이 좋다고 딱 잘라 말하기는 어렵다. 중요한 것은 서로 만나서 대화하는 시간을 가지라는 것이다. 신뢰 관계 형성에 대화와 소통만큼 중요한 것은 없다. 하지만 개발자의 특성을 알지 못하고 소통을 하면 오히려 독이 될 수 있다. 그렇다면 개발자들과는 어떻게 소통하는 것이 좋을까? 여러분이 가장 궁금해할 질문일 것이다. 한 대표가 다음과 같이 말했다. “OO 개발자님, 우리 회사에서 고객 추천 시스템을 개발하려고 합니다. 고객이 만족할만한 멋진 서비스로 화려하게 만들어보세요”. 개발자는 이 말을 듣고 무슨 생각을 할까? “대체 뭘 어떻게 하라는 거야?”라고 생각할 확률이 100%이다. 개발자들은 추상적인 표현을 좋아하지 않는다. 추상적으로 말한다는 것은 기술을 제대로 모른다는 뜻이다. 이런 식으로 얘기하는 사람을 신뢰하지 않게 된다. 개발자들은 구체적이고 명확한 단어를 사용하여 대화하는 것을 좋아한다. 개발자들과 대화하는 방법을 한마디로 요약하면 명확한 ‘입력’과 ‘출력’이다. 즉, 입력에 해당하는 ‘고객의 요구사항’, ‘담당할 개발 범위’, ‘개발 기간’, ‘대상 고객’ 등을 구체화하고 출력에 해당하는 ‘디자인’, ‘사용자 인터페이스’ 등을 명확하게 알려줘야 한다.