Mt

← index

Loading contents...

Techie to tech lead: My five biggest mistakes

개발자에서 개발팀장이 되기까지 겪은 다섯가지 큰 실수

Peter Gillard-Moss

피터 길라드–모스

As a young, ambitious developer with a strong sense of my own talent, I was eager to become a tech lead, and it took less than four years for me to achieve this goal. But over the next two years, the experience and reality of leading a team put me off leadership completely. For several years after, I retreated into the security of the technology, shunning any opportunity to take on more responsibility.

젊었을 때는 자신의 재능에 확신을 가진 야심 찬 프로그래머로서, 팀장이 되기를 늘 꿈꿨습니다. 그리고 그렇게 되기까지 4년이 채 걸리지 않았죠. 하지만 2년간 팀을 이끌며 느낀 현실은 제게서 리더쉽이라는 것을 완전히 앗아가 버렸습니다. 그 이후로 몇 년 동안 저는 기술의 깊숙한 곳으로 숨어, 더 큰 책임을 요구하는 일에서 도망쳐왔습니다. (역주: Leader를 팀장으로 의역하였습니다)

Over time, I gained an understanding of the root causes of my mistakes and eventually regained the confidence to accept new leadership opportunities and grow as a leader, and with the right support over the last two years, I've grown as a Head of Technology inside ThoughtWorks. As I have coached and mentored other leads, I’ve learned that some of my mistakes weren't unique to me but are common among technologists who move into leadership.

시간이 지남에 따라, 제가 저지른 실수들의 근본적인 원인에 대해 이해하여 다시 리더가 되는 기회를 잡아 팀장으로 성장할 수 있었고, 지난 2년간 제대로 된 지원을 받으며 ThoughtWorks의 기술 부문장을 맡을 정도로 성장하였습니다. 다른 리더들에게 가르침을 받으면서 제가 했던 실수들이 저만 겪었던 특별한 일이 아니라, 리더쉽을 요구받는 개발자들이 공통적으로 가질 수 있는 문제임을 알았습니다.

I'd like to share my mistakes and what I have learned in the hope that others may benefit.

다른 분들에게 도움이 되기를 바라며 제 실수와 그로부터 배운 것들을 공유해봅니다.

1: I believed my technical ability entitled me to lead

1: 기술적인 능력이 리더쉽으로 이어질 줄 알았다

In my first tech lead role, I had hired a talented young graduate. We worked really well together and pushed each other forward into new ideas and skills. Within a few months, I realized that despite their inexperience, they were more technically able than me. As the tech lead, I felt that I had to prove myself as the most technically capable; I’d feel insecure every time they demonstrated their ability to others (especially my managers), concerned that they’d view them as more suitable for my role than I was. What was originally a great working relationship suffered from my feelings of competitiveness and mistrust. Rather than seeing them as a collaborator (or even as a potential successor), I was seeing them as a threat.

기술 리더 역할을 처음 맡으면서, 젊고 재능있는 졸업생들을 고용했습니다. 우리는 새로운 아이디어와 능력으로 서로 밀어주고 당겨주며 열심히 일했습니다. 고작 몇 달 만에 이 친구들이 경험은 부족할지 몰라도, 저보다 기술적으로 더 뛰어날 수 있다는 것을 깨달았습니다. 기술 리더로서 다른 그 누구보다 기술적으로 뛰어남을 증명해야겠다는 생각이 들었습니다. 그들이 다른 사람에게 – 특히 제 상관에게 – 가능성을 보여줄 때마다 저는 불안해져서, 그들이 저보다 제 역할에 더 어울려 보이지 않을까 안절부절못했습니다. 좋은 동료였던 관계가 제 경쟁심과 불신으로 휩싸였습니다. 그들을 공동 작업자(또는 최소한 잠재적인 후임자)로 여기지 못하고 위협적인 존재로만 여겼습니다.

Someone's technical ability is often one of the biggest factors when choosing them as leaders. It’s also certainly the most visible factor. And here began my first mistake: conflating that ability with the entitlement to lead.

기술적인 능력이 리더를 선택하는 데 있어 가장 큰 요인으로 주로 사용되곤 합니다. 가장 명확하게 보이는 요인이기도 하고요. 이게 제 첫 번째 실수였습니다. 기술적으로 뛰어난 사람이 리더로의 능력도 클 것으로 착각했죠.

In my example, this conflation led to unhelpful competitive behaviours. A lot of my insecurity came from my environment and my mistaken sense of entitlement. But even in the most modest and deserving of people, this mistake can aggravate imposter syndrome, and the lead may perceive other members of the team as more worthy; they may underestimate their teamworkcontributions and struggle to understand their own worth. When this happens, leads can become indecisive and avoid making decisions, rather than trusting those they know to be capable.

제 경우에는 이 착각이 별 도움도 안 되는 경쟁적인 행동들로 이어졌습니다. 주변 환경과 자격지심 때문에 제 불안은 커져갔습니다. 제아무리 겸손하고 능력 있는 사람이라도 이런 실수는 가면 증후군을 강화해, 팀의 다른 사람들이 훨씬 가치 있다는 생각에 빠지게 만듭니다. 팀워크를 과소평가하거나 자신의 존재 가치에 대해 의문을 가지게 되기도 합니다. 이런 경우에, 리더는 자신의 역할을 믿지 못해 우유부단해지고 필요한 순간에 결정을 내리지 못하게 됩니다.

This mistake prevents good people from putting themselves forward for lead roles, as they believe the most technically competent individual should be the lead.

기술이 뛰어난 사람이 리더가 되어야 한다는 잘못된 생각 때문에, 능력 있는 사람들이 스스로 리더 역할을 꺼리게 됩니다.

2: I focused on tech when I should have broadened my capabilities

2: 능력을 넓혀야 할 때 기술에만 집착하고 있었다

I was very excited about my first lead role. It was a brand new team with a greenfield project. I introduced new technologies and practices: unit testing, ORM, continuous integration, pairing, optimistic source control, nant build files. If I read a blog post about an exciting new idea, I incorporated it into our processes and tools.

처음 팀장을 맡았을 때 정말 좋았습니다. 완전한 새 프로젝트에 새로운 팀이었으니까요. 유닛 테스팅, ORM, 지속적 통합(CI), 페어 코딩, 더 나은 소스 관리 도구, 빌드 시스템 등 신기술과 방법론들을 도입했습니다. 힙스터의 새로운 블로그 글을 읽으면 바로 회사 프로세스와 도구에 도입해보았습니다.

Choosing tools and technologies was iteration 0 work. Now came the day-to-day stuff. The managing, dealing with stakeholders, representing my team in meetings, performance reviews, recruitment, budgets, etc. And while I knew enough to select svn, nunit, CruiseControl, and C#, I had no idea about all that other stuff.

도구와 기술을 선택하는 것은 처음에만 해당하는 일이었습니다. 이제 날마다 해야 하는 일의 차례였습니다. 관리하고, 관계자들을 설득하고, 팀 회의를 진행하고, 실적 리뷰를 하고, 사람을 뽑고, 예산을 관리하는 일 같은 것들요. SVN, nunit, CruiseControl, C# 같은 건 고를 줄 알았지만 다른 일들은 완전히 처음이었습니다.

I began to resent the activities I didn't understand and found difficult. Rather than address my gaps, I focused more on the things I felt I could control: technology. This only aggravated my imposter syndrome, especially if I was in a meeting with other managers who’d confidently talk about growing their teams by bringing in training or making business cases for investment or new team members or disaster recovery plans, etc.

제가 이해하지 못하고 어렵다고 생각하는 것들에 점점 화만 쌓여갔습니다. 문제의 원인을 알아보려 하지 않고, 저는 제가 그나마 할 수 있는 것에만 집중했습니다. 바로 기술이죠. 이는 제 가면 증후군을 더 악화시키기만 했는데, 팀 성장에 자신 있어 하는 다른 팀장을 만날 때, 투자를 위한 비즈니스 미팅, 새로운 팀 멤버들이나 장애 복구 계획 등을 얘기할 때 특별히 더 심했습니다.

As previously mentioned, technical ability isn’t the only basis for suitability for a leadership role. Alongside technical prowess are many other strengths: from influencing and persuading, to coaching, to understanding processes, to being a trusted advisor, to dealing with complexity, to strategic thinking (and many more). These competencies are much less visible and are probably needed in more nuanced ways throughout the working day and week.

앞서도 말했지만, 기술적인 역량은 리더의 역할에 얼마나 적합한지를 알려주는 유일한 지표가 아닙니다. 기술적으로 탁월한 것은 여러 부분 중 하나일 뿐입니다. 동료에게 영향을 주고 설득하며 코칭하는 능력, 프로세스에 대한 이해, 신뢰받는 조언, 복잡도를 다루는 능력, 전략적 사고 등 이루 말할 수 없이 많습니다. 이러한 것들은 눈에 잘 띄진 않지만 업무 중에 계속해서 섬세하게 요구되는 역량입니다.

It's important for new leads to understand the significance of these other competencies and the need to build themselves out in breadth across many areas. Otherwise, they risk turning towards their most visible strength — technology — and focus on building depth.

새롭게 리더 역할을 맡게 되면 이런 역량들의 중요성을 이해하고 폭넓은 분야에서 자기 계발을 하는 것이 필요합니다. 그렇지 않으면 가장 눈에 띄는 역량인 ‘기술’에만 불나방처럼 빠져들어 문제를 악화시키게 됩니다.

Another trap is that it’s relatively easy for a technologist to build up new technical competencies. We're used to acquiring technical skills; we know the formulas, the blog pages, the StackOverflow posts, the thought leaders to follow, the conferences to attend, the books to read. Given a half decent 'Hello World' example and a few spikes later we're well on our way to picking up a new technology.

또 다른 함정은, 개발자들이 새로운 기술 역량을 익히기가 상대적으로 쉽다는 것입니다. 우리는 새로운 기술을 습득하는데 꽤 익숙합니다. 수식을 이해하고, 블로그를 읽으며, 스택오버플로우를 찾아보고, 좋은 리더를 알고 있으며, 컨퍼런스에 참석하며, 책을 봅니다. 적당한 ‘Hello World’ 예제와 몇 번의 시도를 하고 나면 새로운 기술에 이미 익숙해져 있습니다.

But other competencies don't work this way.

하지만 다른 역량은 이렇게 익힐 수 없습니다.

There isn't an obvious 'Hello World' for coaching or time management or influencing or persuading or articulating business value.

코칭이나 시간 관리, 비즈니스 가치에 영향을 주거나 설득하는 방법에 대해서는 명확한 ‘Hello World’가 없습니다.

We don't know who to follow on Twitter to get the 'right way' to communicate decisions or organize teams or manage stakeholders.

우리는 의사 결정을 내리거나 팀을 조직하고 이해 관계자를 이해시키는 ‘올바른 방법’을 듣기 위해 트위터에서 누굴 팔로우 해야 할 지 모릅니다.

This makes moving into the new domains required for leadership expensive. As many of these domains are relatively new, the lead is left feeling lost and intimidated. They may also mistakenly prioritize developing new technical competencies which are quick and easy to pick up and have obvious value over alien competencies, which are hard to get into without clear value.

리더쉽이 있어야 하는 새로운 역할을 맡을 때는 걸맞는 대가를 치뤄야 합니다. 이러한 것들 중 대부분은 새롭기 때문에 신임 팀장들은 갈팡질팡하게 됩니다. 익숙하지 않은 역량들은 익혀서 어떤 가치를 줄지 알 수 없으므로, 눈에 보여 쉽게 익힐 수 있을 것 같은 기술적 역량을 익히는 데 치중하기가 쉽습니다.

3: I continued to see myself as an individual producer

3: 계속해서 개발자로 일하려고 했다

After a few months into my first tech lead role, I was becoming increasingly anxious. It seemed like I needed to do a lot of things that didn't feel productive. Less and less of my time was spent pairing and writing code as I was busy in meetings, replying to emails, answering questions from stakeholders, etc. I felt as if every story with my name on it wasn't progressing. My response was to sacrifice my personal time to make up for what I'd missed due to these distractions (as I perceived them). I quickly became overworked.

팀장이 되고 나서 처음 몇 달간은 근심이 깊어갔습니다. 개발과는 무관한 일들만 잔뜩 해야 하는 것 같았습니다. 코드를 작성하는 시간은 점점 줄어만 가고, 회의와 이메일, 이해 관계자들을 상대하는 일들로 바빴습니다. 제 이름이 걸린 일들은 진전이 없게 느껴졌고요. 이런 일을 하느라 못했던 것들을 제 개인 시간을 희생해서라도 하려고 했습니다. 당연히 야근으로 이어졌습니다.

What I hadn't realized when I moved from a techie to tech lead, was how my responsibilities and metrics for success, in terms of being a producer, had changed. If you look at any delivery team, you can see the main goal is to maximize the amount of 'value' produced. In this light, there are two main activities in the team: those that directly produce value, and those that work to maximize the impact of what is produced. One of the simplest (but by no means the only) ways to do this is to ensure that the producers (in this case the developers) have the maximum time to focus on productive activities (i.e., producing code). The rest of the team, from PM to XD to BA to QA are working to ensure that the flow of work is as correct and smooth as possible and doesn't get blocked or create failure demand (due to bugs, etc.). Simple version: to keep developers productive, the team around them work to remove any obstacles or distractions so developers can focus on writing the right code to deliver value.

개발자에서 개발팀장이 되면서 깨닫지 못한 게 있다면, ‘생산자’라는 관점에서 제 책임과 성공의 척도가 바뀌었다는 것입니다. 전달하는 조직에서는 주된 목표가 생산된 ‘가치’를 극대화 하는 데 있습니다. 이런 관점에서 팀에는 두 가지 주된 활동이 있습니다. 하나는 직접 가치를 창출하는 일과, 다른 하나는 생산된 가치를 극대화하는 일입니다. 이 일을 하기 위한 유일한 방법은 아니지만, 가장 단순한 방법은 생산자(개발자)가 생산 활동(코드를 작성하는 것)에 집중하는 시간을 극대화하는 것입니다. PM부터 XD, BA, QA까지 이르는 다른 팀은 업무 과정이 최대한 정확하고 물처럼 흘러 일이 막히거나 실패 요인(버그 같은 것)을 만들지 않도록 노력해야 합니다. 간단하게 말하자면, 개발자들의 생산성을 높이기 위해서는 주변 팀에서 장애나 산만함을 제거해서 개발자가 제대로 된 코드를 작성해 가치를 창출하는데 집중할 수 있어야 한다는 것입니다.

When someone moves from techie to tech lead, they’re shifting from being one of the producers to being part of the team whose goal is to maximize overall impact (which includes removing obstacles and blockers).

개발자에서 개발팀장이 된다는 것은 더 이상 생산자의 역할이 아니라 전체적인 영향을 극대화하는 역할로 바뀐다는 것입니다. 물론, 장애물과 방해자들을 제거하는 일도 포함해서요.

This misunderstanding places a lot of stress on the new tech lead, especially around time management, specifically a feeling of not having enough time to code or pair with others. Sometimes this is expressed in frustrations of too many meetings or a desire to have meetings only at certain times (core coding/pairing hours etc.). In some extreme cases, I've seen this manifest as a complete rejection of any activities which were not considered technical (talking to stakeholders for example). All of these originate from the tech lead's perception of being a direct producer rather than as someone who is maximizing the impact of others.

이런 것들을 잘 이해하지 못한다면 다른 개발자들과 같이 코딩하는데 시간을 쓸 수 없는 현실에 정말 큰 스트레스를 받게 됩니다. 너무 많은 회의에 좌절하거나 특정 시간에만 미팅을 하려고 하기도 하죠(코어 코딩/페어링 시간을 정해서). 극단적인 경우에는 기술과 관련 없는 모든 활동을 거부하는 행위를 보이기도 합니다(이해 관계자를 만나야 한다거나 하는). 이런 일련의 행동은 개발 리더가 다른 사람의 가치를 극대화하는 사람이 아니라 직접 개발을 해야 한다는 인식에 기인합니다.

In my case, it even led to me perceiving myself as the main, and an indispensable, contributor to the team. I've seen this happen a lot with others too, especially in smaller teams where there is a large skills gap between the lead and the other members. Under the combined pressure from additional responsibility along with normal delivery pressures, the tech lead can feel that if they shift away from writing code, the productivity of the team will significantly suffer.

제 경우에는, 저 자신을 팀의 핵심적인, 대체할 수 없는 역할로 여기기까지 했습니다. 다른 사람들도 이렇게 하는 것을 자주 봤는데요, 팀장과 팀원 사이의 기술적 역량 차이가 큰 작은 규모의 팀에서 특히 심했습니다. 개발을 해야 한다는 압박감에 다른 책임감까지 더해져 짓눌리는 상황에서 기술 리더들은 자신이 직접 개발하지 않으면 팀의 생산성이 떨어진다고 여기게 됩니다.

4: I wanted to know, and control, everything when I needed to empower others

4: 다른 사람에게 위임해야 할 때 모든 것을 알고 제어하려고 했다.

One day, I was in a meeting when a manager asked about a bug. Having never worked in that area of the application I struggled to answer the question, and the more I tried, the less convincing I became. In the end, for fear of exposing my ignorance, I made an educated guess. It turned out that other teams started making changes in their applications to accommodate my guess and, after wasting a load of effort, they discovered I'd been wrong. I attributed my failure to ignorance and tried to prevent it happening again by reading the commit log at the start of every day.

어느 날, 회의에서 다른 팀장이 저에게 버그에 관해 물었습니다. 제가 손 댄 적이 없는 분야였기 때문에 답하기가 어려웠고, 노력하면 할수록 제 말의 설득력은 떨어졌습니다. 모른다는 것을 인정하기가 어려워 경험에 따라 적당히 답을 해버렸습니다. 다른 팀이 제 추측에 따라 애플리케이션을 변경하기 시작했고, 엄청난 시간을 낭비하고 나서야 제 추측이 틀렸음을 밝혀냈습니다. 저는 이런 실수가 무지에서 비롯되었다고 여기고, 아침마다 모든 커밋 로그를 읽기 시작했습니다.

When reading the commits, I noticed a piece of code that looked rather procedural and I felt could have been more object-oriented. I sat down with the developer and discussed trying a different approach. I decided to pair with them and became absorbed in this small area of the code for several days. At the same time, another pair were working on a significant architectural change. When they released, it caused a bug due to a simple incorrect assumption which I should have picked up.

커밋을 읽으면서, 절차적으로 작성된 코드의 특정 부분이 객체 지향적으로 바꾸면 좋겠다는 생각이 들었습니다. 다른 개발자 옆에 앉아서 다른 방법을 시도해보자고 얘기했고, 며칠 동안이나 코드의 작은 부분을 고치는 일에 빠져 있었습니다. 그러는 와중에 다른 팀원들은 큰 틀에서 설계를 변경하고 있었습니다. 그 변경 사항이 배포되고 나서 제가 눈치채지 못한 잘못된 가정 때문에 엄청난 버그를 일으키고 말았습니다.

I was honest with my manager about what had happened; I'd been focusing on getting this code right and missed what the other pair were doing. But I struggled with the feedback that I was worrying about things that weren't important. Surely making sure we were doing OOP code was important? Their response? I needed to pick my battles.

저는 제 상관에게 어떤 일이 있었는지 솔직히 얘기했습니다. 제가 맡은 코드를 제대로 만드는 데 집중하느라 다른 부분에 신경 쓰지 못했다고요. 하지만 중요하지 않은 일에 신경 쓰고 있다는 질책을 이겨내기 어려웠습니다. 객체 지향적으로 코드를 작성하는 게 정말 중요했을까요? 그들의 반응은? 저는 선택을 해야 했습니다.

Both these situations had one thing in common: that I couldn't be involved in everything that was happening. It wasn’t humanly possible. As a tech lead, I had to trust others with responsibilities and focus on the most important things. Sometimes that would mean ignorance and other times it would mean that things weren't done exactly the way I would choose to do them, or even that they were done in a less than ideal way. Saying "I don't know, I need to check with the team" was OK but accidentally spreading misinformation was harmful. And having little things that weren't quite perfect, like a bit of procedural code, was OK. But taking on large architectural change without my oversight was not acceptable.

이런 일에는 공통점이 하나 있습니다. 모든 일에 개입할 수는 없다는 것입니다. 인간적으로 불가능합니다. 개발 리더로서 저는 책임감을 느끼고 다른 사람들을 믿고 중요한 것들에 더 집중해야 했습니다. 때로는 모른 체 해야 할 수도 있고, 제가 원하는 방식이나 이상적인 방법으로 진행되지 않아도 어쩔 수 없습니다. “나는 잘 모르겠고, 팀과 확인해봐야겠다.”고 얘기하는 게 잘못된 정보를 퍼트리는 것보다는 낫습니다. 절차적인 코드가 좀 있으면 어떻습니까. 오히려 제가 눈치채지 못한 큰 설계의 변경은 있을 수 없는 일입니다.

I also realized that there are other tools, such as mentoring and running code reviews as a team, which are far more effective in improving the code base over the longer term than trying to fix every small issue, as and when it arose.

장기적인 관점에서 코드 수준을 높이기 위해서는, 문제가 생길 때마다 작은 문제를 고치는 데 노력을 기울이지 말고 멘토링과 코드 리뷰를 운영하는 것이 훨씬 효율적임을 깨달았습니다.

5: I didn’t recognize that the signals changed

5: 신호가 바뀐 걸 몰랐다

I'd attend project meetings, suggest improvements, but my frustrations grew as I felt nothing was changing. My contributions didn't seem to turn into anything concrete. We'd discuss having the test teamwork with the developers on each story; we'd try it once and then we'd go back to queuing everything up for pre-prod. People would agree that the developers should own the database, but we'd still wait for the DBAs to build stored procedures. I'd coach developers on TDD but one iteration in, everyone had given up on it. Everything felt like a talking shop where nothing got done, and I felt increasingly frustrated and despondent.

프로젝트 회의에 참석하고, 개선을 제안해도 무언가 바뀌는 것이 없다고 생각되니 두려워지기 시작했습니다. 구체적인 제 성과가 보이지 않았습니다. 모든 단계에서 개발자들과 팀워크를 재고하는 방법들을 논의했습니다. 하지만 한 번 하고 난 다음에는 번번이 원래대로 돌아가기 일쑤였습니다. 다른 사람들은 개발자가 직접 데이터베이스를 다뤄야 한다고 생각하겠지만, 우리는 DBA가 스토어드 프로시저를 작성해줄 때까지 기다렸습니다. 개발자들에게 TDD를 하자고 해봤지만 한 번 하고 나서는 다들 손을 들었습니다. 말만 하고 아무것도 되질 않으니 겁이 나고 위축되었습니다.

When technology is your every minute of every day, you become attuned to the feedback loops and signals put in place. We’re part of the story wall: our brains release endorphins every time a build passes or story goes to production, and cortisol, when the build breaks or we detect a story, is stuck ‘in development’. But when you move into a leadership role, the signals come from other places.

매일 매일 기술만 생각하고 있다면, 당신은 피드백 과정과 일상적인 신호에 적응하게 됩니다. 우리는 일감 스토리보드의 일부로, 빌드가 통과되거나 프로덕션으로 릴리즈 될 때 엔도르핀을 방출합니다. 그리고 빌드가 깨지거나 새로운 스토리(이슈)가 생기면 코르티솔이 분비되어 ‘개발 중’ 상태에 빠집니다. 하지만 리더쉽을 요구하는 역할에서의 신호는 다른 곳에서 옵니다.

It's hard for techies to detect this shift especially as the concerns of each day are mainly the same: stories still need to be picked up and delivered, the code still needs to be written. So the signals a new lead receives still look technical.

개발자가 신경 쓰는 것은 매일 매일 비슷하기 때문에 이러한 변화를 알아차리기가 어렵습니다. 스토리는 계속해서 만들어지고 전달되어야 하고 코드는 계속 작성되어야 합니다. 기술 팀장이 받는 신호는 여전히 기술적으로 여겨집니다.

When moving into leadership roles, we need to look out for and learn the other signals. If we want to change direction, we must influence others. We must learn to see the signals that tell us who understands our ideas and whether they’re convinced and supportive or skeptical. There are also other signals, for instance team members struggling with the workload and needing support; or if they’re missing the tools to develop new skills or disciplines; or there are gaps in communication structures leaving the team ignorant of what it’s supposed to achieve. Often these signals are hard to detect because they come from people — who often hide or mask or highlight other things.

리더쉽이 필요한 역할을 맡는다면 다른 신호들도 배우고 유심히 지켜봐야 합니다. 방향을 튼다면, 다른 사람에게 끼치는 영향이 있을 겁니다. 누가 아이디어를 이해했는지, 그리고 어떤 사람이 납득하고 누구를 설득하지 못했는지, 아니면 협조적인지 회의적인지에 대한 신호를 반드시 배워야 합니다. 다른 신호들도 많이 있는데, 이를테면 팀원이 업무에 지쳐 도움이 필요로 한다던가, 새로운 기술을 배우는데 적합한 도구가 없는 경우, 팀이 무엇을 목표로 해야 하는지 모르고 의사소통하는 문제들에 대해서요. 이런 신호들은 무언가 숨기거나, 다른 것을 강조하기도 하는 ‘사람’에게서 오기 때문에 알아차리기가 쉽지 않습니다.

Detecting these signals is almost a sixth sense which you develop with experience, and when you are not attuned to them, you don't even realize they exist.

이런 신호를 알아차리는 것은 경험에 따른 육감에 가깝습니다. 이런 일에 익숙하지 않다면 전혀 모를 일이죠.

And they also have to be treated with caution: they may not always be caused by what you think.

그리고 이런 일들은 주의 깊게 다뤄져야 합니다. 항상 당신이 생각한 일 때문에 일어나는 것은 아니라서요.

The really good leaders seem to be highly attuned to all these signals and understand how to interpret and respond to them. Although it can look like a dark art, akin to reading the tea leaves or animal entrails, there are real rational approaches which, while not as deterministic and certain as technology, are learnable.

정말 좋은 리더가 되려거든 이런 모든 신호에 귀 기울이고 그것들을 어떻게 이해하고 답을 줄지 고민해야 합니다. 찻잎이나 동물 내장을 통해 짐작하는 흑마법을 쓰는 주술사처럼 보일 수도 있고, 기술만큼 확실하지는 않겠지만 합리적으로 접근하여 배울 수 있는 일입니다.

Growing from my technical roots

개발자 출신으로 성장하기

One thing you may have noticed is that a lot of these mistakes relate to each other. For example, it’s hard to stop seeing yourself as a producer when you believe your technical ability is your reason for leading. That makes it harder to develop other skills. The way these mistakes fed into each other is what put my leadership journey into a death spiral.

이미 눈치채셨겠지만, 각 실수들은 서로 연관되어 있습니다. 예를 들어, 자신이 리더인 이유가 기술적인 면이 뛰어나서라고 생각한다면, 자기 자신을 생산자로 여기는 것을 피할 수 없을 겁니다. 그러다 보니 새로운 기술을 배우기가 더 어렵죠. 이런 실수들이 서로 꼬이고 꼬인 제 첫 팀장 경험은 완전히 망해버렸습니다.

Taking a leadership role is a big change and can be very daunting, and when we, as humans, struggle, we turn to our strengths. And while technical ability needs to form the roots of leadership, we need to grow from our other strengths as well. Whether those are our abilities to work with people, to communicate, convince and persuade others or are technical skills which are transferable such as an ability to learn fast, pick up new things, reason about complex matters or reframe problems in more understandable terms by building abstractions. Once I felt confident in my strengths, I began to see the opportunities to grow new skills and branch out into new exciting areas of learning and development.

리더쉽 역할을 맡게 된다는 건 큰 변화이고 벅찰 수 있습니다. 하지만 인간으로서, 고생한 만큼 새로운 능력을 발견할 수도 있습니다. 기술은 리더쉽의 근간이 되어야 하지만, 다른 부분에서 능력을 성장시켜야만 합니다. 이런 능력들이 사람과 함께 일하고, 의사소통하고, 납득시키고 설명하는 능력이든, 아니면 빠르게 습득하고, 새로운 걸 발견하고, 복잡한 문제의 원인을 찾거나 추상화 능력을 발전시켜 문제를 이해하기 쉽게 재구성하는 기술적인 능력이든 간에 말이죠. 제 능력에 자신감이 붙고 나서는 새로운 기술을 배울 수 있는 기회를 찾아, 흥미진진한 새로운 영역을 배우고 개발하는 것으로 뻗어 나갈 수 있었습니다.

It’s also crucial to understand that the leadership journey isn’t linear.

리더쉽이 선형적으로 발전하는 게 아니라는 것을 이해하는 것이 중요합니다.

It’s fine to play a leadership role and move back to pure tech. It will only make you a better technologist. And likewise, leadership is not exclusive to those who carry the label ‘lead’.

팀장을 맡았다가 다시 순수한 개발자로 돌아가도 좋습니다. 더 나은 개발자로 만들어줄 기회가 될 것입니다. 뻔한 얘기지만, 리더쉽은 ‘팀장’ 딱지를 달아야만 생기는 건 아니니까요.

Teams should create smaller opportunities for development, without taking a lead role and find ways for others to practice developing the other skills in safer environments.

팀은 자기계발을 위한 작은 기회들을 마련해서, 리더 역할을 맡지 않더라도 더 나은, 안전한 환경에서 다른 능력을 연습하고 배울 수 있는 방법을 찾아야만 합니다.

Translators

Latest update at 2019-04-05T19:07:37Z

In alphabetical order