예전에 트위터 하다가 읽었던 글인데, 개인적으로 마음에 들어서 부족하게나마 번역해 보았습니다.
원문은 슬랙 개발 블로그의 Technical Leadership: Getting Started라는 글입니다.
번역에 크게 자신이 없으니 부담이 없으신 분들은 원문을 보셔요.
+
+
+
+
+
테크니컬 리더십: 시작하기
내가 소프트웨어 엔지니어가 되기 전에는 이 직업에서 가장 중요한 점은 코딩이라고 생각했다. 그것은 잘못된 생각이었고, 소프트웨어 공학의 가장 중요한(그리고 가장 어려운)점은 다른 사람들과 원만하게 잘 협력하는 것이다.
+
나는 “관리자는 되지 않을거야!”라고 스스로에게 말해왔고, “그렇게 하면, 내 모든 에너지를 개발에만 집중시킬 수 있을거야!” 라고 생각했다. 내 이후의 경력도 기술 지향적인 실무자 위주로만 관리해 간다면 이 어려운 대인관계를 어느 정도 무시할 수 있을 거라고 생각했다.
+
+빨리 가려거든 혼자 가고, 멀리 가려거든 함께 가라.
+
+
내가 업무에서 대인관계를 소홀히 여기던 때 의아하게 생각했던 점은 “왜 사람들은 나의 의견을 들어주지 않지?” 하는 점이었다. 이는 슬랙(Slack)의 플랫폼 팀에서 처음 작업을 시작했을 때 특히 그러했다. 나는 슬랙의 API가 토큰을 사용하고 있는 점을 변경하여 보안을 강화하고, 제품 개발팀 전체에 걸쳐 일관된 개발 과정을 유지하도록 개선하고 싶었다. 그러나 몇 달 동안, 나의 제안이 많은 이들의 시간을 보다 가치있게 활용할 수 있는 방법이라고 PM이나 팀원들을 설득하는 것은 불가능했다.
+
이후로도 몇 차례 나의 의견은 받아들여지지 않고, 같은 팀 수석 엔지니어들의 의견이 채택되는 것을 지켜보면서 내게 무언가 빠진 요소가 있다는 것을 알게 되었는데, 그것은 바로 ‘리더십’이었다. 나는 매일같이 키보드에만 코를 박고 있으면 안되는 것이었다. 내가 성장하기를 원한다면, 다른 사람들이 나와 동등한 수준으로 기여할 수 있도록 도움을 주어야 했던 것이다. 나는 리더십을 통해 나의 영향력을 키워야 할 필요가 있었다.
+
이 글을 통해 필자 스스로가 리더십에 대해 배운 점과, 개발자 리더십의 절차(Path)에 대해 이야기해 보고자 한다.
+
자기 자신을 리딩하기
슬랙의 엔지니어로 지내면서, 나는 관리(management)와 리더십(leadership)이 어떻게 다른지 이해하게 되었다.
+
관리자(manager)는 자신의 보고서에 대한 책임이 있다. 관리자들은 코칭과 구조화를 통해 좋은 팀을 구축하는 것에 중점을 둔다. 또한 팀의 성장을 위해 성과를 관리한다.
+
관리자(manager)는 종종 리더(leader)를 겸임하지만, 리딩은 사실 다른 누구라도 할 수 있는 별개의 것이다. 리딩은 권위에 의존하는 무언가가 아니라, 다른 사람에게 미치는 영향력에 대한 것이다. 리딩은 비전에 대해 소통하고, 비전을 실현하기 위해 다른 이들에게 힘을 실어주는 것이다.
+
당신은 다른 이들을 리드하기 전에, 먼저 당신 자신을 리드할 수 있어야 한다. 자신을 리딩하는 것은 타인을 리드하거나, 조직을 리드하기 전에 반드시 먼저 선행되어야 한다. 자신을 리딩한다는 개념은 다양한 분야와 기업에서 정리한 여러 리더십의 정의들에서 찾아볼 수 있다.
+
자기 자신을 리딩하는 것은 그 사람의 우수한 역량과 밀접한 관련이 있다. 모범적인 자세를 통해 드러나는 리더십은 타인에게 자극을 주는 가장 강력한 방법이기 때문이다. 자신을 리딩한다는 말은 늘 최선을 다해서 개인의 업무를 수행하고, 스스로가 만들어내는 결과물의 품질에 대해 책임을 지는 것을 의미한다.
+
자기 자신에게 성공적인 리더십을 발휘하기 위한 다섯하기 요소는 방향 맞추기, 전문가 되기, 공유하기, 일관되게 실행하기, 효과적인 의사소통하기 이다.
+
방향 맞추기(Finding Alignment)
+
+
직장에서 우수함을 나타내려면 먼저, 팀을 이해해야 하고, 회사를 이해해야 한다.
+
‘원칙’이란 어떤 행동이 바람직한지, 혹은 바람직하지 않은지를 안내하는 회사의 규범을 말한다. 대개는 이런 원칙들이 명확하게 규정되지 않은 경우도 많은데, 이런 숨은 원칙을 잘 찾아내는 것 역시 개인의 몫이다. 이 원칙들은 당신의 나침반과도 같다. 원칙들은 당신이 회사의 목표와 가치에 맞는 결정을 내리는데 큰 도움을 줄 것이다.
+
슬랙에서의 예를 들어보면, 우리는 슬랙의 사용자들에게 매우 뛰어난 사용 경험을 제공하고 있다는 믿음이 있다. 어떤 고객이 슬랙의 핵심 기능 중의 하나가 망가졌다는 제보를 한다면, 나에게는 그 즉시 내가 하고 있던 일을 모두 멈추고 현상을 확인해 즉시 문제를 해결하는 것이 가장 중요하다. 하지만 다른 회사에서는 내가 하던 일을 내팽개치는 것이 완전히 잘못된 판단이 될 수도 있는 것이다.
+
대부분의 결정은 여러가지 가치를 두고 다각도로 고민하면서 내려져야 한다. 오늘은 그동안 쌓아둔 기술 부채를 해결하는데 시간을 쓸 것인가? 아니면 좀 더 미루고 내일의 작업을 위한 기반작업을 할 것인가? 버그를 잡는 것, 툴을 만드는 것, 새로운 기능을 개발하는 것이 더 중요하진 않은가? 직장에서 할애할 수 있는 총 시간과 에너지의 양은 제한되어 있다. 회사가 중요하게 생각하는 것과 개인이 노력을 기울이는 방향을 동일하게 맞출 때 당신의 기여도는 가장 최대의 효율을 발휘할 것이다.
+
방향성 맞추기는 단지 회사가 당신에게 바라는 일을 수행하는 것만을 뜻하지 않는다. 여러분들은 리더로서 여러가지 문제를 직면하고, 이를 해결하기 위한 (숨어있는) 솔루션을 제시할 숱한 기회들을 마주하게 될 것이다. 하지만 그 때마다 다른 동료들에게 이것이 왜 문제이며, 왜 이를 해결하기 위해 에너지를 써야 하는가를 납득시키기 위해서는 먼저 회사가 무엇을 중요하게 생각하는지를 이해하고 다른사람에게 잘 설명할 수 있어야 한다.
+
전문가 되기(Become an Expert)
전문가가 되는 것은 개인 스킬을 연마하는 것에 관한 이야기다. 잠재력을 가진 상태라는 것이 하나의 좋은 자질일 순 있겠지만, 그걸로는 충분하지 않다. 리더는 실제로 뛰어난 전문가(export)여야 한다. 콜로라도 대학의 앤더스 에릭슨 교수에 따르면, 전문가가 되기 위해서는 평균 10년 이상 높은 수준의 의식적인 노력을 10,000시간 이상 기울여야 한다고 말한다.
+
사람들은 종종 내가 오페라를 불렀던 경험이 소프트웨어 공학 경력에 도움이 되는지를 묻곤한다. 맞다! 음악을 통해서 나는 스스로의 마음가짐을 발전시킬 수 있었다. 아리아를 연습할 때면 가장 자신 없는 파트를 제일 자신있는 파트만큼의 자연 스러운 소리가 나올 때까지 몇시간이고 반복해서 연습했다. 소프트웨어 공학도 이것과 똑같다. 우리는 자신이 취약한 부분을 개발하는데 더욱 많은 시간을 투자해야 한다.
+
숙련을 쌓는 방법에 지름길이란 없다. 다만 꾸준하고 의식적인 노력으로 개발시키는 것 뿐이다. 내 자신에게(그리고 당신 주변의 사람들에게) 질문을 던져보자: 내가 가장 크게 성장할 수 있는 분야는 무엇인가? 전문가가 되기 위해서 나는 어떤 스킬을 개발해야 하는가?
+
당신이 개발하기 원하는 많은 스킬들이 있을 수 있지만, 노력을 기울이기 전에 먼저 다음의 질문을 던져보기를 권장한다: 그 스킬은 회사가 추구하는 방향에 부합하는가? 그 스킬은 나의 개인적인 목표에도 부합하는가?
+
‘아직 아무것도 이룬 것이 없다’는 생각만 하고 있을 게 아니라 매일 꾸준히 지식과 스킬을 체득하고자 노력하는 과정이 필요하다. 누구나 태어날 때부터 전문가였던 사람은 없다.
+
공유하기(Share)
자기 자신을 리딩하는 과정이 지나면, 다른 사람을 리드할 기회가 주어지고, 당신의 동료들이 최고의 성과를 내도록 역할을 부여하게 된다. 이를 성공적으로 수행하기 위해서는 먼저 지식을 공유해야 한다.
+
스킬을 습득하기 위해 많은 개인 시간을 소비한 후라면 선뜻 지식을 공유하는 것이 쉽지 않을 수도 있다. 특별한 전문성을 혼자만 “소유”하고 싶은 것은 본능적인 생각이다. 전문 지식은 체득 과정의 노력이 보이지 않을 땐 마치 마술처럼 느껴질 수도 있다. 당신은 혼자만의 마법을 비밀 상자에 숨겨놓고 외딴 곳에 보관하고 있다가 필요할 때만 꺼내서 사용하고 싶어할 수 있다. 다른 사람들은 그걸 어떻게 하는지 모르기 때문에, 당신만의 전문성은 여전히 마법을 유지하게 될 것이다.
+
하지만 바로 이 부분이 핵심이다. 당신의 노하우를 혼자만 알고 있으면 동료들은 당신에게 의존하게 되고, 결국 동료들의 성장을 방해하는 셈이 된다. 당신 스스로도 새로운 일을 배우는 것을 불안하다고 여기게 되어, 자신의 성장마저 방해하는 셈이 된다. 당신은 동료들이 팀에 기여하는 것을 막고 있으며, 팀을 아주 적극적으로 망치고 있는 셈이다.
+
나도 내가 가진 정보를 혼자만 유지하곤 했는데, 일부러 숨기고자 해서 그랬다기 보다는 이것이 유익한 정보인지 깨닫지 못했던 경우였다. 예를 들어, 나의 프로젝트에서는 업무의 진행을 방해하는 일반적인 문제점들에 대해 탐구하고 정리해왔다: 킥오프, 최종 마일스톤, 회귀 없는 릴리즈 같은 것들(역주: 예시의 내용들이 무엇을 말하는지는 잘 모르겠습니다). 나는 주위 동료들도 함께 성공했으면 하는 마음에 내가 유지하던 정보들 중 다른 팀들과 공유할 수 있는 기술들을 분류하기 시작했다. 사실 내 프로젝트만 잘 돌아가면 상관 없는 일이었지만.. 그것은 추가 확장이 없는 x1배의 영향력이다. 허나 이런 정보들은 모든 팀들에게 적용 가능한 것들이었고, 이것은 xN 배의 영향력을 발휘하게 된다.
+
지식을 숨기는 대신 공유하라. 멘토링이나 페어 프로그래밍 같은 1:1 방식도 좋고, 프레젠테이션이나 문서화 같은 1:N 방식도 좋다. 당신이 배운 사실을 다른 사람들에게도 가르쳐라. 그럼 다른 사람들은 다시 그 다음 사람들을 가르칠 것이다. 당신은 다시 배우고자 하는 그 다음 스킬로 자유롭게 이동할 수 있다. 지식이란 마르지 않는 샘이다. 아무리 배워도 항상 더 많이 남아있다.
+
+
+
+
일관되게 실행하기(Execute Consistently)
일전에 나의 관리자와 나눴던 대화가 기억난다. 나는 관리자에게 최근의 프로젝트에서 내가 매우 뛰어난 성과를 기록했다고 말하고, 내가 언제쯤 승진할 수 있느냐고 질문했다. 그는 현명하게 대답했다: “당신은 이번과 같은 좋은 성과를 일관되고 꾸준하게 달성할 수 있음을 증명해야 합니다.”
+
일관성. 그것은 일시적인 운과 리더십의 차이를 말해준다.
+
당신이 어느 한가지 일을 딱 한 번 잘해냈다는 것은 별로 중요하지 않다. 정말 중요한 것은 당신이 그 일을 다시, 또 다시, 그리고 또 다시 잘 해낼 수 있는가 하는 것이다.
+
일관성 있는 실행력을 갖기 위해서는, 다양한 규모와 유형의 여러가지 프로젝트를 해봐야 할 것이다. 작은 규모, 큰 규모, 복합적인 기능, 사용자 친화적 UX, 백엔드 솔루션 등등. 이러한 경험들에서 당신은 다양한 도전 과제를 마주하고 해결 방안들을 개발하게 된다. 당신의 약점이 무엇인지를 드러내주고 당신이 스킬을 연마하도록 도울것이다.
+
당신의 관리자에게, 당신이 익히려고 하는 기술들을 미리 공유하라. 앞으로 맡게 될 프로젝트를 주시하고 그 중에 자신이 흥미가 가는 부분이 무엇이며 왜 그렇게 생각하는지를 관리자에게 미리 알려라. 당신이 지금 프로젝트를 진행중이라면, 작업하는 동안 나는 어떤 스킬을 선정해 발전시켜갈 것인가에 대해 생각하라. 이것은 직장에서의 시간을 최대의 효율로 활용하는데 큰 도움을 줄 것이다.
+
때로는 당신이 크게 열정을 느끼지 못하지만 팀의 임무에는 중요한(mission-critical)일에 배정이 될 때도 있다. 당신은 이 또한 잘 해낼 수 있음을 증명해야 한다.
+
일관되게 실행하는 것은 개인의 브랜드를 개발시키고 동료들에게 신뢰를 쌓을 수 있는 방법이다. 신뢰감을 형성하고 키우는 데에는 많은 시간과 경험이 필요하다. 하룻밤 만에 만들어지지 않는다. 한 번 신뢰를 얻었다 하더라도 지속적인 노력이 뒤따라야만 이를 오래도록 유지할 수 있다.
+
효과적인 의사소통하기(Communicate Effectively)
“왜 사람들이 내 말을 들어주지 않는거야?” 하고 궁금해 한 적이 있는가?
+
나는 신입일 때 여러 차례 위와 같은 질문을 하곤 했다. 그러던 어느날 문득 내가 성장의 준비가 되었을 즈음에, 사장님이 중요한 단서를 주었다: 나는 동료들에게 부정적인 성향으로 인식되고 있었다는 점이다. 처음엔 그 피드백을 듣고 기분이 상했다. 하지만 이것이 나의 경력에서 중요한 전환점이 되었다. 그 후로 나는 ‘목소리’ 코치와 함께 일하게 되었고, 효과적인 커뮤니케이션의 중요한 비밀을 깨닫게 되었다. 그것은 경청(listening)이다.
+
경청이란 단순히 정보를 받아들이는 것이 아니다. 경청은 정보와 함께 그것의 맥락을 모두 합쳐 하나의 덩어리로 합성하는 것이다. 경청은 상대방의 의견이 어디에서 왔는지를 이해하고, 더 깊은 이해를 얻기 위해 명확한 질문을 던지는 것을 말한다. 이 합성의 듣기는 효과적인 커뮤니케이션의 가장 기본임과 동시에, 당신이 말하고자 하는 아이디어에도 엄청난 힘을 실어준다 - 믿거나 말거나.
+
+
+
+레벨이 올라감에 따라 관리자 트랙과 엔지니어 트랙에게는 모두 동일한 의사소통 기술이 요구됩니다. 각 트랙의 진정한 능력자들이 서로 다른 트랙의 능력자를 존재할 수 있게 만듭니다. - Sarah Mei
+
+
효과적인 의사소통의 또 다른 측면은 적절한 맥락으로 반복하는 것이다. 사람들이 왜 내 말에 귀기울이지 않는지 몰랐을 때의 나는 했던 말을 다시 반복해야 할 때면 화를 내면서 말했다.
+
나중에서야 효과적인 의사소통의 고수들을 관찰하기 시작했다. 그들은 다방면으로 정보를 노출한다. 적절한 시간 간격을 두고 반복적으로 정보를 전달하고, 듣는 사람이 누군가에 따라 그에 맞는 다양한 세부 정보들을 제공한다.
+
정보를 듣고 종합하고, 효과적으로 공유하는 방법을 익히는 것은 직급에서 오는 권위에 의존하지 않고 사람들에게 영향을 미치는 기본적 기술이다. 모두가 하나의 비전을 바라하도록 사람들을 모으기 위해서는 이러한 영향력이 필요하다.
+
. . .
+
소프트웨어 엔지니어로 일을 시작할 때, 왜 나의 아이디어가 회사에서-그리고 업계에서-잘 받아들여지지 않는 것인가를 궁금해했다. 그러던 중 컴퓨터만 골똘히 들여다보던 시선을 잠시 벗어나, 주변의 훌륭한 동료들을 만나보게 되면서 깨달았다. 내가 생각하는 방향성을 다른 사람들이 함께 공감하고, 실현하기 위해 같이 노력하도록 동기부여할 수 있다면 훨씬 더 큰 영향력을 미칠 수 있다는 것을.
+
리더십에 관해서는 배워야 할 것이 많고, 필자 개인적으로는 더 많은 것들을 배워야 한다. 리더급 개발자가 되고자 한다면, 먼저 자기 자신을 리딩하는 것부터 시작하기를 권한다. 이 외에 당신이 찾아낸 리더십에 대해 내게도 알려주길 바란다!
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
`;
+ }
+ },
+ cssClasses: {
+ text: 'search-stats'
+ }
+ }),
+
+ instantsearch.widgets.hits({
+ container : '.algolia-hits',
+ escapeHTML: false,
+ templates : {
+ item: data => {
+ const { title, excerpt, excerptStrip, contentStripTruncate } = data._highlightResult;
+ let result = `