Why Engineering Managers Still Want To Write Code(왜 개발 관리자가 여전히 코드를 작성하길 원하는가)

Why Engineering Managers Still Want To Write Code(왜 개발 관리자가 여전히 코드를 작성하길 원하는가)

리더 역할을 맡으면서 기술적으로 직접 해보고, 코드를 작성해야 할까요? 이러한 기사들은 수없이 많고 흔한 주제입니다.

그러나 왜 이러한 질문을 애초에 하는 이유가 무엇일까요? 왜 이게 문제일까요? 팀을 이끌고 다른 개발자를 휼륭하게 하는 것이 주요 목표인데, 왜 가장 큰 영향을 미치지 않거나 팀에 중요한 가치를 더하는 것이 아닌 작업에 집중해야 할까요?

개인적인 경험을 통해 나 자신에게 같은 질문을 하면 이러한 생각을 해서 동기부여를 하는 3가지 주요 이유가 있다고 생각합니다.

코딩은 에너지를 줍니다.

대부분의 개발자 관리자는 오랫동안 개발 역할을 맡거나, 여러 가지를 구축한 것인 경력을 통해 관리자라는 역할을 맡게 될 것 입니다.

관리자 역할을 담당할 만큼 오랫동안 개발자를 해왔다면 몇년 동안 코드를 작성하고 여러가지 구축했을 것 입니다. 이것은 코딩과 기술적인 작업에 열정을 가지고 있다는 것을 의미합니다.

기술적인 작업을 즐겨하고, 그거에 크게 만족감을 갖는 사람들에게 팀을 이끌고 관리하는 일에 반드시 같은 만족감을 준다고 할 수 없습니다. 직접 구축하고, 창조하고, 문제를 해결하고, 결과물을 보는 것을 동기부여로 가지고 있던 사람에게는 다른 사람이 하는 걸 보면서 같은 기쁨으로 얻으려고 노력하는 것이 큰 변화일 것 입니다.

만약 저와 같은 사람이라면 코드를 작성하고 직접 결과를을 만들고 보는 것에 큰 힘을 얻을 것 입니다. 더이상 이러한 일을 하지 않을때 코딩하는 것을 그리워할 것 입니다.

아마도 한주의 끝이나 하루의 끝을 보내고 "내가 실제로 무엇을 했을까? 일하면서 어떤 시간을 소비했는가?"라는 생각을 해본적이 있을 것입니다. "여러분의 팀 개발자들이 휼륭한 것을 만들고 멋지게 해주셨다"라는 대답이 나왔을 때 종종 약간의 성취감을 느끼지 못한 채 끝날 수 있습니다.

개발 팀장으로써 여러분의 성공은 팀의 중요한 새로운 기능을 제시간에 만들거나, 여러분의 멘토링과 코칭 덕분에 고마워 하는 것으로 측정됩니다.

이것도 충분한 만족감을 줄 수 잇지만, 애플리케이션 기능과 같은 것을 가리키면서 "이것을 했다"라고 말하는 것과 다를겁니다.

팀 관리를 하면 사람 문제와 같이 더 어렵고 힘든 면이 있습니다. 아마도 팀 구성원 중 한 명이 개인적인 정서나 개인적인 삶에서 힘든 시간을 보내고 있어 도움이 필요할지도 모릅니다. 아마도 팀 구성원 중 한명에게 지속적인 개선을 위해 추가적인 도움과 접근이 필요할 것입니다. 휼륭한 관리자들은 그러한 상황에서 기쁨과 에너지를 발견할 수 있지만, 만약 여러분이 사람 문제보다 기술적인 문제를 다루는 것을 더 좋아한다면 이것 자체가 많은 에너지를 사용한다는 것을 발견할 수도 있습니다.

Slower Feedback Loops(느린 피드백 반복)

소프트웨어 엔지니어가 되는 것은 일련은 짧은 피드백 반복(무엇을 수행했는지, 그 결과를 보는 것 사이의 짧은 시간)을 가지고 있습니다.

만약 너가 TDD를 사용해 테스트를 작성한다면 실패, 코드 작성, 테스트 통과, 완료를 확인하게 될 것입니다.

그리고 다음으로 넘어가게될것입니다. 이 과정은 몇분 심지어 몇초만에 가능합니다. 이러한 과정에서 즐거움을 느끼고 다시 동작하는 것에 즐거움을 줄겁니다.

만약 너의 팀이 CI/CD를 사용한다면 고객이 몇 시간 또는 몇 분 내에 운영환경에서 코드를 사용할 수 있을 것입니다. 다시 말하면 무언가를 하고 사람들에게 가치를 주는 것에 짧은 시간이 있습니다. 이러한 것이 매주 만족스러울겁니다.

그러나 개발 관리자는 이러한 피드백 반복이 매우 매우 길어집니다.

아마도 좀 더 좋은 개발 프레임워크를 팀에 도입하려고 있을 것입니다. 이러한 프레임워크를 만들거나 도입하는 과정은 오랜 시간 걸리거나 팀 구성원 중 한명이 몇 주, 몇달, 심지어 몇년까지도 볼 수 있습니다.

아마 TBD(trunk-based development, 단일 브랜치에서 모두 작업하는 것)으로 전환하는데 도움이 될 수 습니다. 다시 하지만, 이것은 하룻밤 사이에 일어날 일이 아닙니다. 이러한 결과를 보기 위해 많은 시간이 걸릴 것입니다.

대신에 매시간과 매일은 종종 넛지효과를 가져올것입니다. 이러한 시작을 조금씩 진행하면서 이후 시점까지 이런 궁극적인 성과를 거두지 못할 것 입니다.

Future Career Prospects(미래의 경력 전망)

새로 온 관리자나 일정 기간 근무경력이 있고 이것이 자신의 경럭이 맞는지 오랫동안 확신하지 못하는 사람들을 위해 코드를 작성하는 것이 실제로 너의 경력과 미래의 역할과 관련되어 잇는지 아닌지를 또 다른 사람에게 질문을 할수도 있다.

Charity Majors가 “Manager/Engineer Pendulum.” 이라 부르는 것에 대해 매니저에서 개인적인 컨트리뷰터로 전환하는 것이 흔해지고 있다.

하지만 현재 예전만큼 코딩에 얽매이지 않는다면, 어느날 갑자기 멈춰 둘려보면서 "6개월 동안 코딩하지 않고 다시 실전을 하는 역할로 돌아갈수 없다"라고 생각할 수 있다

개발자로 지원하려고 생각할 때, 너가 작성한 코드를 잊어버린 것 처럼 느껴서 너는 면접을 보는 동안 기술 테스트의 예상을 무서워 한다.

물론 그렇지는 않다. 매일 실전 경험을 하지 않으면 녹슬겠지만, 당신이 알고 있는 모든것을 잊어버리지는 않을 것입니다. 그냥 그렇게 느끼는것을 뿐입니다.

Understand and Acknowledge the Feelings(감정을 이해하고 인정해라)

만약 너가 코드를 작성하는게 필요한지 아닌지 궁금하다면, 자신의 이유를 이해하는것이 중요합니다.

만약 너의 열정이 진심으로 팀을 관리하는 것이 아니라 개발자가 되는 것에 있다면 그것을 할 수 있는 방법을 찾아야 합니다. 궁극적으로 자신을 행복하게 만드는 것은 자기자신에게 책임이 있습니다. 그러나 더 중요한 것은 자신의 팀에게도 빚을 질 수 있다는 것입니다.

개발자 관리자로써 당신은 팀을 지원하고 팀원들이 최선을 다하도록 도와줄 책임이 있습니다. 그게 당신의 주요 관심사 일것입니다. 그들의 경력과 발전은 너의 손에 달려있습니다. 만약 그것을 실현하기 위해 노력을 하지 않는다면, 정직하게 너 자신에게 고민해봐야 하고 다른 누군가에게 그 역할을 건네줘야 할 필요가 있습니다.

휼륭한 관리자와 그것을 진정으로 사랑하는 사람들이 많습니다. 그들은 팀을 성장시킴으로써 진정한 기쁨과 에너지를 얻습니다. 그것이 당신을 위한 것이 아니라면 괜찮지만, 그것을 인식하고 모두에게 옳바른 일을 인정하게 하는 것이 중요합니다.

글을 읽어주셔서 감사합니다.