좋은 개발 팀 리더가 되는 데 어떤 기술이 도움이 될까요?

안녕하세요. 제 이름은 Aleksandr Guzenko입니다. 저는 대기업에서 프런트 엔드 개발 팀 3개를 이끄는 팀 리더입니다. 최근 한 직원이 저에게 다가와서 이렇게 말했습니다. “저는 팀장으로 성장하고 싶습니다. 어디서부터 시작해야 할까요?" 이것이 이 기사의 아이디어가 탄생한 방식으로, 나중에 가이드로 그에게 보내기로 약속했습니다.

이 글에서는 제가 어떻게 팀 리더가 되었는지, 이 자리에서 없으면 할 수 없는 기술이 무엇인지, "보통" 개발자라면 팀 관리 능력을 향상시킬 수 있는 방법을 알려드리겠습니다.

팀 리더는 누구이며, 그는 어떤 일을 담당하나요?

이론부터 시작해 보겠습니다. 이론이 없으면 왜 개발을 관리하러 갔지만 대신 프로젝트 예산을 계산했는지 이해하기 어려울 것입니다.

고전적인 의미에서 팀 리더는 개발 팀의 책임자입니다. 이는 사실이지만 약간의 유보가 있습니다.

오늘날의 환경에서 팀 리더는 프로그래머를 넘어 디자이너, 분석가, 테스터, SEO 전문가, 다양한 IT 및 비IT 전문가를 포함합니다. 따라서 특히 개발자에 초점을 맞추겠지만 팀 리더를 동일한 역할을 공유하는 직원 그룹의 리더로 정의하는 것이 더 정확합니다.

둘째, 팀장은 단순한 팀장이 아니라 직원과 경영진 사이의 주요 연결 고리입니다. 이는 중요한 추가 사항이며 그 이유를 아래에서 설명하겠습니다.

셋째, 팀장의 책임이 무엇인지 이해하기 위해서는 역할과 직책을 구별하는 것이 중요합니다.

팀 리더의 역할에는 주로 관리 업무가 포함됩니다.

• 중요한 문제에 대한 경영진의 입장을 전달합니다.
• 조직 변경을 수행합니다.
• 직원들에게 작업을 분배하고 구현을 모니터링합니다.
• 현재 팀 질문에 답변합니다.
• 분쟁 해결
• 팀 내에서 편안한 분위기를 조성합니다.
• 각 팀원의 특성을 고려하십시오.

채용 사이트의 책임 목록에 다르게 명시되어 있더라도 순수한 형태에서는 해당 역할을 거의 찾을 수 없습니다.

팀 리더의 위치는 팀 리더, 기술 리더, 수석 개발자 등 여러 역할을 동시에 결합할 수 있습니다. 이 직위에서는 전문가가 직접 코드를 작성하고 팀 작업을 관리하며 기술적인 부분을 담당하는 경우가 많습니다.

• 프로젝트 개발 전략을 수립합니다.
• 디자인 아키텍처;
• 특정 작업 및 프로젝트에 대한 기술 스택을 정의합니다.
• 관련된 라이브러리의 버전을 모니터링합니다.
• 코드 품질을 담당합니다.
• 기술 부채 수준을 제어하여 프로젝트에 심각한 영향을 미치지 않도록 합니다.

팀장과 기술장이 1인일 때 업무가 훨씬 편리합니다. 실제로 대기업에서도 팀 리더의 위치에는 세 가지 역할이 모두 서로 다른 비율로 조합되어 있습니다. 따라서 팀 리더가 수행하는 작업에 대한 아이디어는 종종 다릅니다.

여러 회사의 개발자에게 팀 리더의 책임이 무엇인지 묻는다면 대답은 다를 것입니다. 팀 리더들 사이에도 비슷한 의견이 있을 것입니다. 이를 확인하려면 구직 사이트 로 이동하여 다양한 공석의 책임 목록을 살펴보십시오.

누가 팀 리더가 될 수 있나요?

개발팀을 이끌려면 심각한 역량과 경험이 필요합니다. 따라서 팀장이 되는 가장 일반적이고 올바른 방법은 먼저 고위직에 올라야 리더십 위치를 목표로 하는 것입니다. 그러나 이것이 항상 일어나는 것은 아닙니다.

팀이 미들 프로그래머로만 구성되어 있고 그 중에 모든 사항을 알고 프로젝트를 지원하는 주도적인 직원이 있다면 그는 훌륭한 팀 리더가 될 것입니다. 네, 선배보다 기술력은 떨어지지만 팀에 더 높은 사람이 없다면 그의 역량은 충분할 것입니다.

동시에, 모든 선배가 팀의 직책을 맡아 적절한 진로를 찾을 수 있는 것은 아닙니다. 리더십 위치에서 일하는 것은 정말 흥미로울 것입니다. 그렇지 않으면 관리 업무량이 줄어들 수 있습니다.

작업 부하를 처리할 수 있다는 것을 어떻게 이해합니까?

짧은 대답: 시도해 보세요. 추가 책임을 무료로 맡고 싶다고 관리자에게 말하고 무슨 일이 일어나는지 확인하십시오. 이는 상생 계획이므로 경영진은 일반적으로 기꺼이 협력합니다.

팀 리더가 승리합니다 . 누군가가 그를 위해 일합니다.

비즈니스의 승리 : 작업은 완료되지만 이에 대해 비용을 지불할 필요는 없습니다.

팀 리더 연습생에게도 장점이 있습니다 . 이 모드에서 몇 달에서 1년 동안 작업한 후에는 자신이 성공하는지, 리더를 좋아하는지 스스로 이해할 수 있습니다. 그리고 각 항목에 대한 대답이 '예'라면 이 방향으로의 성장을 진지하게 생각해 볼 수 있습니다.

팀 리더가 되는 방법: 성장 전략

옵션은 두 가지뿐입니다. 첫 번째는 회사의 다른 모든 개발자들을 제치고 "가장 나이가 많은" 직원으로서 팀 리더가 되는 것입니다. 그러나 "old"라는 단어를 따옴표 안에 넣지 않아도 되는 위험이 있습니다. 두 번째 옵션은 스스로 주도권을 잡는 것입니다.

나한테는 어땠는지 말해줄게. 제 졸업장에 따르면 제 직업은 관리자이고, 대학 공부와 동시에 프로그래밍을 스스로 공부했습니다. 그래서 저는 프로그래머라는 직업을 갖기 전부터 개발팀 리더가 되기로 결심했습니다.

처음에는 작은 회사에서 일했어요. 요령을 익히고 후배에서 강력한 중견수로 성장하는 데 2년이 걸렸습니다. 프로그래밍 경험이 없으면 좋은 팀 리더가 될 수 없습니다. 개발 프로세스가 어떻게 진행되는지, 어떤 실수와 함정이 있는지 이해해야 합니다.

몇 년 후 저는 대기업에 입사했고 즉시 팀장이 되고 싶다고 밝혔습니다. 대기업에서는 보통 6개월이나 1년에 한 번씩 성과 평가를 실시하는데, 관리자가 직원을 만나 함께 가까운 미래에 대한 개인 개발 계획을 세웁니다. 그런 모임마다 나는 팀장이 되고 싶다고 말했다. 처음에 그들은 나에게 "모든 것이 훌륭하지만 먼저 경험을 쌓아라"라고 말했습니다. 리더십 경험을 쌓을 수 있도록 개발 계획을 세웠습니다.

약 6개월간 팀장과 함께 업무를 평가하고 분해하여 직원들에게 분배하려고 노력했습니다. 우리 작업의 질이 어느 정도 비슷해졌을 때 회사에서는 새로운 프론트엔드 개발팀을 구성했고 제가 그 팀을 이끌었습니다. 대기업에서는 너무 오래 기다릴 필요가 없습니다.

팀 리더의 성장에는 두 가지 중요한 이정표가 있다고 합니다. 첫 번째는 직원이 2~6명이고 두 번째는 7명 이상입니다. 처음에는 직원이 한 명뿐이었는데 지금은 프런트엔드 개발 팀 3개, 즉 직원 12명을 이끌고 있습니다.

나는 단순히 주도력을 보여 경영진 앞에 모습을 드러냈고, 기회가 오자마자 팀장으로 임명됐다.

성장을 기다리거나 다른 회사로 떠나시겠습니까?

팀 리더는 회사 내에서 임명되는 경우가 많으므로 이를 고려하는 것이 중요합니다. 현재 직장에서 성장할 가능성이 있다면 주도적으로 관리자의 역할을 시도해야 합니다. 그러나 팀 전체가 프런트엔드와 백엔드이고 모두가 자신의 팀 리더라면 기적을 기대해서는 안 됩니다. 더 큰 회사로 이동하고 앞으로 리더십 위치를 차지하고 싶다는 것을 나타내는 것이 좋습니다. 프로세스를 연구하고 프로젝트의 비즈니스 로직을 이해하려면 시간이 필요합니다. 그러나 회사에서 적합한 자리가 열리면 외부인 대신 당신을 선택할 가능성이 높습니다.

훌륭한 팀 리더가 되는 데 어떤 기술이 도움이 될까요?

팀 리더의 위치에서는 하드 스킬과 소프트 스킬이 모두 똑같이 중요합니다. 개발자는 일반적으로 하드 스킬에서 무엇이 부족한지 알고 있습니다. 더욱이 이러한 요구 사항은 전문화 및 기술 스택과 밀접하게 연관되어 있으므로 보편적인 목록이 없습니다. 나는 제품과 회사에 중요하다고 생각하는 소프트 스킬에 대해 이야기하겠습니다.

프로세스에서 문제를 찾아내는 능력

개발 속도와 품질, 그에 따른 비용은 회사의 프로세스에 따라 다르지만 이상적인 경우는 거의 없습니다.

예를 들어, 버그를 수정하고 빌드를 스탠드로 가져올 준비가 되면 비즈니스가 기다리고 있습니다. 하지만 이렇게 하려면 5개의 파이프라인을 거쳐 관련된 모든 사람으로부터 승인을 받아야 합니다. 당신은 책임자에게 편지를 씁니다-침묵. 당신은 그들을 잡아당기기 시작하지만 응답하기 위해 공식적인 메시지가 도착합니다. 모두가 시간이 없습니다. 수정된 버전이 스탠드에 도착하기까지 최대 6시간이 걸릴 수 있습니다. 그리고 이 모든 시간을 동료들에게 다가가려고 애쓰다가 사업은 돈을 잃습니다.

또 다른 예는 다양한 시스템, 프로그램, 스탠드 및 저장소에 대한 엄청난 수의 액세스입니다. 은행은 대개 이로 인해 어려움을 겪습니다. 사람이 일하러 오면 프로젝트를 이해해야하지만 첫 달 반 동안은 전혀 아무것도 할 수 없습니다. 왜냐하면 – 맞습니다 – 접근이 불가능하기 때문입니다. 액세스의 또 다른 문제는 액세스가 많고 이름을 기억할 수 없다는 것입니다. 예를 들어, 디렉토리의 "저장소에 대한 액세스" 대신 A32B18KZ가 있을 것입니다. 이를 찾아보십시오.

개발자가 한두 달 동안 일을 시작하지 못한 실제 사례를 알고 있습니다. 그동안 그는 월급을 받았지만 환멸을 느끼고 그만 두었습니다. 즉, 회사는 직원을 찾는 데 6개월을 투자하고, 그에게 두 달치 월급을 지급한 후, 채용 과정을 처음부터 다시 시작해야 했습니다.

이러한 프로세스 문제는 작업을 복잡하게 만들고 속도를 저하시킵니다. 팀 리더의 임무는 이를 보고 정확히 무엇이 제대로 작동하지 않고 어디에서 실패가 발생하는지 이해하는 것입니다.

문제를 해결하거나 이를 비즈니스에 올바르게 전달하는 능력

프로세스의 문제를 보는 것뿐만 아니라 솔루션을 제공하는 것도 중요합니다. 관리를 거치지 않고도 스스로 어려움을 처리할 수 있습니다. 예를 들어, 한 팀이 불편한 상태 관리자로 인해 어려움을 겪고 있습니다. 프로젝트가 작거나 시작 단계인 경우 전화를 주선하고 최선의 옵션을 찾고 손실 없이 새로운 상태 관리자를 점진적으로 도입하는 방법을 간략하게 설명할 수 있습니다. 해결책을 찾았지만 기업에서는 문제의 존재조차 인식하지 못했습니다.

그러나 대부분의 문제는 고위 경영진의 도움을 통해서만 해결될 수 있습니다. 예를 들어, 빌드를 스탠드에 빠르게 출시하기 위해 모든 부서에서 좋은 관계를 갖고 있고 의사 결정자와 접근할 수 있는 사람을 식별하고 승인 프로세스에 참여시킬 수 있습니다. 다른 부서 동료의 피드백이 없으면 누구에게 편지를 보낼지 알고 프로세스를 수동으로 설정할 수 있습니다. 하지만 이러한 업무에는 별도의 직위가 필요하므로 회사 경영진의 승인을 받아야 합니다.

접근 문제도 비슷하게 해결됩니다. 대부분의 개발자에게는 동일한 시스템과 프로그램이 필요합니다. 예를 들어, 저장소, 스탠드, Jira 등 프런트엔드 개발자의 경우 표준 액세스 패키지를 만들고 적은 급여를 요구할 사람을 고용하는 것은 어떨까요? 그러나 이를 위해서는 회사 최고 경영진의 의지도 필요합니다.

따라서 팀장의 주요 능력 중 하나는 문제의 본질을 비즈니스에 정확하게 전달하는 것입니다. 여기에는 몇 가지 비밀이 있습니다.

• 한 번으로는 충분하지 않습니다 . 첫 번째 연락 이후에는 문제가 해결되는 경우가 거의 없으므로 일정한 간격으로 경영진에게 가서 문제를 상기시켜야 합니다. "이것은 팀의 사기를 떨어뜨리고 있습니다." "우리는 생산성을 잃고 있습니다."

  
  

• 팀의 문제와 비즈니스 이해관계가 어떻게 연결되어 있는지 확인했다면 이 지점을 방문하세요 . 예를 들어, 작업 시간은 몇 시간밖에 안 되었는데 수정하는 데 이틀이 걸리는 심각한 버그가 있었고 그 결과 회사는 돈을 잃었습니다. 경영진에 가서 빌드 조정 문제에 대해 이야기합니다. 그러한 순간에 기업은 제안에 최대한 개방적입니다. 하지만 솔루션은 이미 준비되어 있어야 합니다.

비즈니스와 동일한 언어를 사용하세요.

가장 확실한 방법은 문제를 경영진에게 가져가기 전에 문제가 회사에 얼마나 많은 비용을 초래하는지 계산하는 것입니다.

저는 프론트엔드 팀장으로서 정기적으로 직원들로부터 피드백을 수집합니다. 예를 들어, 개발자는 작업이 제대로 설명되지 않는다고 끊임없이 불평합니다. 이 때문에 문제의 작성자가 그들에게 원하는 것이 무엇인지 알아내는 데 오랜 시간이 걸립니다. 그런 다음 테스터는 개발자에게 와서 무엇이 완료되었는지, 정확히 무엇을 테스트해야 하는지, 그리고 체인을 따라 더 나아가 이해하려고 노력합니다. 결과적으로 모든 사람은 여전히 자신의 방식으로 본질을 이해하고 버그가 나타납니다.

나는 평균적으로 팀이 업무 시간의 40%를 버그 수정에 소비한다고 계산했습니다. 우리는 팀과 함께 후향적 분석을 실시한 결과 이러한 버그 중 절반이 문제의 본질을 오해했기 때문에 발생했다는 사실을 알아냈습니다. 즉, 개발자의 작업 시간 중 20%는 작업 설명이 제대로 이루어지지 않아 낭비됩니다. 이것은 당신이 관리에 가야 할 번호입니다. 이를 돈으로 바꾸는 것은 쉽습니다. 이는 기업이 이해하는 것과 동일한 언어입니다.

팀 내에서 유리한 환경을 조성하십시오.

사람들이 서로 즐겁게 협력하면 모든 상호 작용이 더 원활해집니다. 스크럼이 왜 그렇게 인기가 있나요? 이것은 문서에 관한 것이 아니라 사람에 관한 것입니다. 때로는 동료가 답변을 문서화하고 모든 것을 자세히 설명할 때까지 이틀을 기다리는 것보다 동료에게 2분 동안 전화하는 것이 더 효과적일 때도 있습니다. 그래서 팀 내에서 상호 이해와 상호 지원의 분위기가 조성되면 사람들이 서로 연락하기가 더 쉬워집니다. 예를 들어, 코드 조각을 찾았는데 그 코드가 무엇을 하는지 이해하지 못한다고 가정해 보겠습니다. 팀의 상황이 좋지 않으면 전화해서 물어보는 것이 두려울 것입니다. "그 사람은 내가 멍청하다고 생각할 거예요."

팀 내에서 좋은 관계를 유지하기 위해 일주일에 한 번씩 한 시간씩 통화를 합니다. 이 시간을 세 부분으로 나눕니다. 첫 번째는 '편안함'입니다. 우리는 밈과 농담을 공유합니다. 두 번째 부분은 문제에 대한 토론입니다. 때때로 우리는 Miro에서 카드를 함께 던지는데, 이는 모든 사람이 좋아하는 것이 아닙니다. 이것이 내가 정확히 무엇이 사람들의 속도를 늦추는지에 대한 그림을 얻는 방법입니다. 그런 다음 솔루션에 대한 옵션을 제시하고 이를 경영진에 로비할 것입니다. 그리고 우리는 다시 "편안하게" 마무리합니다. 영화나 다른 것에 대해 토론할 수 있습니다. 이러한 만남은 긍정적인 분위기를 조성하고 리더로서 팀에 어떤 어려움이 있는지 이해하게 해줍니다.

대리자

새로운 팀 리더의 일반적인 실수는 작업 프로세스를 자신에게 집중하는 것입니다. 이런 경우 팀장이 갑자기 아프거나 휴가를 가면 업무가 정체되기 시작하고 끊임없이 끌려가게 된다. 이런 일이 발생하지 않도록 하려면 팀의 누군가에게 팀 리더의 책임 중 일부를 수행하도록 가르칠 수 있습니다. 예를 들어, 한 달에 한 번 작업을 배포하도록 다른 사람을 신뢰하십시오. 이렇게 하면 팀의 다른 누군가가 이 기술을 갖게 될 것이고, 팀장은 그 사람 없이는 아무것도 망가지지 않을 것이라는 것을 알고 침착하게 휴가를 갈 수 있을 것입니다.

아마도 이것은 팀 리더의 작업을 평가하는 좋은 기준일 것입니다. 팀에서 제외되면 안전 여유는 한 달 동안 충분해야 합니다.

팀 내 책임 영역을 적절하게 분배

개발 중에는 버스 요소와 같은 측정 기준을 사용하여 프로젝트의 위험을 관리합니다. 이는 전체 프로젝트를 무너뜨리기 위해 가상의 버스에 치여야 하는 팀원 수를 보여줍니다. 버스 계수 = 1이면 심각한 문제가 있는 것입니다.

예를 들어, 우리는 복잡한 프로젝트를 개발하고 있습니다. 정교한 모듈을 갖추고 있으며, 단 한 명의 개발자만이 그것이 어떻게 작동하는지, 어떻게 처리하는지 알고 있습니다. 이 사람이 아프거나 그만두거나 휴가를 가면 이 모듈을 변경하는 것은 매우 길고 비용이 많이 드는 절차로 바뀌어 전체 프로젝트에 부정적인 영향을 미칠 것입니다. 이런 일이 발생하지 않도록 하려면 점차적으로 다른 직원에게 복잡한 모듈이나 라이브러리를 사용하여 작업하도록 가르쳐야 합니다.

팀 리더는 프로세스를 한 사람에게만 국한시키지 않고 팀 내에서 책임을 올바르게 분배할 수 있어야 하며, 그를 프로젝트에 중요한 역할을 하게 만들지 않아야 합니다.

프로젝트의 전략적 비전

팀 리더는 프로젝트가 어디로 진행되고 있는지, 어떤 문제가 있는지, 어떻게 해결해야 하는지 이해해야 합니다. 예를 들어, 팀의 총 작업량은 주당 100시간입니다. 그리고 사업은 100시간 내내 소망을 던집니다. 이때 프로젝트에 기술적 부채가 쌓이고 있는데, 이 역시 처리해야 할 시점이다. 팀 리더의 임무는 기술 부채가 심각해지기 전의 순간을 추적하고 팀이 현재 문제를 해결하는 데 일정 비율의 시간을 소비하도록 로비 관리를 하는 것입니다.

팀 리더로서 어떤 문제에 직면할 수 있나요?

팀 리더가 알람 벨을 인식하기 위해 노력하는 이유를 처음부터 아는 것이 더 좋습니다.

기업 측의 오해

이것은 매달 경영진에게 연락하려고 노력하고 문제와 기성 솔루션을 제시했지만 맨 위에서는 문제를 백로그에 추가하고 아무 일도 일어나지 않을 때 가장 일반적인 문제입니다. 여러 가지 이유가 있을 수 있습니다. 첫 번째는 비즈니스에 잘못된 언어를 사용하고 있으므로 접근 방식을 바꿔야 한다는 것입니다. 두 번째는 당신의 상사가 "모든 것을 가장 잘 알고" 있고 계속해서 그의 방식대로 모든 일을 한다는 것입니다. 이 경우 가장 좋은 해결책은 회사를 바꾸는 것입니다.

자원 부족

간단한 예: 귀하의 팀은 지속적으로 작업에 압도당하고 더 이상 인력이 충분하지 않습니다. 중소기업에서는 신규 직원을 고용할 자금이 없을 수도 있습니다. 이 경우 시스템 분석가 역할과 같은 추가 역할을 맡고 작업 설명을 시작하여 작업이 더 빠르게 진행될 수 있습니다. 대기업에서는 돈이 있을 가능성이 높지만 의사 결정 체인이 너무 길고 3~4급 상사 사이에 고양이가 통과하지 못했다는 보장이 없으며 이로 인해 프로세스가 중단되지 않을 것입니다. 여기서는 최고 경영진의 누군가를 당신 편으로 끌어들이거나 기다릴 수만 있습니다.

작업 결과가 보이지 않습니다.

회사에 와서 전략을 세우고 계획을 세우고 일에 열정을 쏟지만 시간이 흐르고 아무것도 변하지 않는 경우가 있습니다. 여기서 낙담하는 데는 오랜 시간이 걸리지 않습니다. "누가 이 모든 것을 필요로 하는가?" 이 경우 회고적 분석을 수행하여 프로젝트가 진행되지 않는 이유를 이해할 수 있습니다. 스스로에게 물어보세요. "내가 잘못된 목표를 겨냥하고 잘못된 문제를 해결하고 있는 것은 아닐까?"

목표를 달성하기 위한 도구가 부족함

이는 당신이 리더십 위치에 있고 책임이 부여되었지만 통제 수단이 주어지지 않았을 때 발생합니다. 예를 들어, 독립적으로 인터뷰를 진행하고 팀에 합류할 개발자를 모집할 수 있는 방법은 없습니다. 여기에는 두 가지 옵션만 있습니다. 비즈니스에 연락하여 귀하의 입장을 밝히거나 회사를 바꾸는 것입니다.

고위 경영진에 직접 접근

제품을 개발하고 팀의 현재 문제를 해결하려면 팀 리더가 의사 결정자와 지속적으로 접촉해야 합니다. "상위"에 대한 접근이 차단되면 문제는 해결되지 않은 상태로 유지되고 유망한 개발 전략은 언급되지 않으며 작업 동기가 상실됩니다. 탈진하지 않으려면 경영진과 관계를 맺을 수 없다면 회사를 바꾸는 것이 좋습니다.

영구 비상 모드

때로는 작업이 너무 많아서 팀이 더 이상 들어오는 흐름에 대처할 수 없습니다. 긴급 상황이 계속되는 상황에서는 정기적인 전화가 백그라운드로 사라집니다. 버그를 제거하는 데 이 시간을 소비할 수 있는데 누가 밈과 공허한 잡담이 필요한가요? 결과적으로 팀 전체가 구동 말로 변하고 조만간 활력이 떨어지고 사람들이 떠나기 시작할 것입니다. 팀 리더가 할 수 있는 일은 직원을 늘리거나 작업을 대기열에 넣는 것뿐입니다.

팀 분위기가 안 좋다.

모두가 서로를 미워하는 이미 확립된 팀에 합류하면 이런 일이 발생할 수 있습니다. 유해한 의사소통 스타일이 이미 팀에 뿌리를 내리고 있으며 상호 지원에 대한 이야기는 없습니다. 그렇다면 할 수 있는 일은 팀 전체를 해체하고 다시 영입하는 것 뿐이다.

문제가 무엇이든 항상 유리한 결과를 얻을 가능성이 있습니다. 첫 번째 실패 이후에 포기하지 마십시오. 조금 기다리거나 접근 방식을 바꾸는 것이 좋습니다. 그러나 모든 것을 시도했지만 빈 벽을 두드리는 것 같은 느낌이 든다면 떠나기로 결정하는 것이 유일한 올바른 결정일 것입니다.

결론

문제 해결 능력은 팀 리더의 중요한 자질입니다. 그러나 아쉽게도 항상 성공하는 것은 아닙니다. 하지만 1~2년 동안 시간을 투자해왔고 어떤 식으로든 영향을 미칠 수 없다고 생각하지만 성장하고 싶다면 회사를 바꾸는 것도 나쁜 생각은 아닙니다. 변화를 두려워하지 마십시오. 직업을 바꾸는 것은 정상입니다.