개발과 관리 사이, 40대 IT 개발자의 갈림길

개발이 재밌어서 개발자가 되어 어느덧 15년차에 접어들었다.

4차 산업혁명으로 인해 개발언어들이 다양해지고 개발방법 또한 변했다.

새로운 기술을 익한 개발자들이 대량으로 시장에 나오게되면서

회사 내 조직문화도 발빠르게 변화하고 있다.

회의하는 방식이나 소통채널 등도 가끔은 따라가기 버거울 정도이다.

 

이런 변화의 중심에서 회사에서는 나에게 리더의 역할을 맡기려고 한다.

개발을 하면서 리더를 같이 할 순 없는 것일까?

내가 생각하는 개발을 계속하던 사람이 리더로 변화하기 위한 3가지 준비사항

1. 보고하는 기술

개발자일 때는 빠른 기능 개발과 오류없는 코딩, 장애대응 순발력이야 말고 인정받는 보고의 방식이었다.

메일이나 문서를 쓰더라도 결국 결과를 통해 충분히 보고가 될 수 있다.

그러나 리더는 다르다.

리더는 가고자 하는 방향에 대해 명확한 전략을 제시해야한다.

해당 기능이 왜 필요하며 기능을 개발하기 위해 얼마만큼의 개발자 공수가 들어가는지

논리적으로 주변사람들을 설득할 수 있어야 한다.

2. 소통하는 기술

개발자는 소통을 잘하는 기획자나 리더에게만 자신의 의견을 전달하면 되기 때문에 

한명에게만 소통방식을 맞추면 되었다.

그러나 리더는 상사에서 부터 부하직원까지 모두 소통하는 가교역할을 해야 한다.

뿐만 아니라 다른 부서의 협조 등오 받아야하기 때문에 회사 내 다양한 사람들과 두루 알고 지낼 수 있어야 한다.

3. 변화하는 기술

개발자는 개발기술에 대한 변화에 빠르게 대응해야 한다.

가끔은 젋은 개발자들의 빠른 적응력에 긴장이 될 때도 있다.

그래도 깊이 있게 하나의 개발언어를 정확히 이해한 개발자라면 새로운 개발언어가 나온다고 해서 두려워할 필요는 없다.

일반적인 개발 로직은 유사한 방향으로 설계되기 때문이다.

그러나 리더는 조직 내 프로세스를 변화시킬 수 있게 팀원들에게 동기부여를 해줘야 한다.

과거에는 상사가 지시하는 대로 따르는 것이 일반적이었기에 야근이나 갑작스러운 업무를 주는 것에 큰 불만을 제시하지 못했다.

 

최근 조직은 애자일 프로세스 도입으로 인해 계획적이며 개인별 업무 트래킹이 철저해 지고 있다.

문제는 예전 방식으로 일에 적응된 팀원과 새로운 방식으로 일하길 원하는 팀원들과의 협업을 하는데 있다.

리더는 중간매개자로써 서로가 융합될 수 있게 개인별 동기부여와 보상 등을 객관적으로 제시해야 한다.