dzone에 재미있는 글(https://dzone.com/articles/pitfalls-of-a-non-technical-manager)이 올라와서 여기에 정리한다.

이 글은 소프트웨어 산업 분야에서 일하는 비기술 관리자 즉, 개발팀을 리드하는 비기술 관리자를 대상으로 한다.

기술자와 비기술자 사이에는 엄청난 의사 소통의 차이가 있다. 전문가 집단에서는 이 둘은 “다른 세계”라고 표현한다.

두 세계 사이를 아래 이미지가 잘 설명하고 있다.

대략 내용은 이렇다.

관리자: “사용자가 사진을 찍으면 앱에서 위치가 국립공원인지 확인해야 합니다.”

개발자: “GIS 조회는 매우 쉬워요. 조금의 시간만 주세요.”

관리자: “그리고 새의 사진인지 확인하세요.”

개발자: “연구팀과 5년의 시간이 필요해요.”

위의 내용을 이해할 수 없다면, 대규모 프로젝트와 참여 멤버들을 관리할 때는 어떻게 해야 할까?

우선, 비기술 관리자를 정의해보자. 아래 내용중 하나라도 해당된다면, 당신은 비기술 관리자이다.

1. 실제 프로그래밍을 한 적이 없다.
2. 담당하고 있는 프로젝트의 코드와 아키텍처를 전혀 모른다.
3. 기술 회의에 참석하지 않는다. (아키텍처 미팅, 코드 리뷰, 기술 논의등)
4. 개인적으로나 직장에서 프로그래밍을 하지 않는다.

저자가 이 글을 쓴 이유는 비기술 관리자가 빠지기 쉬운 몇 가지 실수 그리고 함정들에 대해서 알게 하기 위함이다.

이 글을 읽는 사람중에 비기술 관리자가 있다면, 본인의 상황과 비교해보고 조언을 해주길 바란다.

비기술 관리자의 함정

1. 프로세스가 모든 것을 고칠 것이다.

비기술 관리자들은 대부분의 문제가 개발 프로세스를 변경하면 해결될 수 있다고 생각한다. 이는 모든 문제가 프로세스를 조정하면 해결될 수 있으며 사람의 질과 업무의 질이 덜 중요하다는 것을 의미한다.

관리자는 개발자가 사무실에 더 오래 머물러야 하고, 압박과 스트레스를 유지하기 위해 비현실적인 완료일을 만들어야 한다고 생각한다. (개발자들이 열심히 하고 있음에도) 소프트웨어 개발을 기계적 프로세스로 보는 것이 비기술 관리자의 가장 큰 실수이다. 프로세스라는 것은 패턴이 비슷하거나 반복되는 작업에 적합한 솔루션이지, 창의적인 작업에는 적합하지 않기 때문이다.

2. 질보다 양

마감일이 다가오면 마감일을 앞당기거나 요구 사항 범위를 줄이는 것보다 코드 품질을 희생하여 마감일을 지키려는 의도가 강해진다. 이유는 코드는 나중에 언제든지 리팩토링 할 수 있지만, 마감일은 지키기 힘든 목표이기 때문이다.

이 부분은 참 어렵다. 코드 품질을 유지하기 위해 마감일을 미루거나 오픈 범위를 줄여야 한다.

“저는 이미 약속했어요…” 라고 얘기하면서 마감일을 지키도록 드라이브 한다.

3. 애자일에서 릴리즈 날짜에 대한 약속

납품 날짜를 지정할 때 개발 작업의 복잡성과 규모를 이해했는지?

종종 Lean, Agile 방법론으로 진행한다고 말할 때, 개발팀에 대해서만 얘기한다. Agile의 중요한 측면은 개발팀외에 회사 전체가 이 모델을 받아들여야 한다는 것이다.

마감일을 말해주는 대신에 2~4주마다 개발 진행 상황을 볼 수 있다고 말할 수 있을까?

4. 관리자 vs 리더

기술적인 노하우가 없다면 개발팀 관리자는 바다에 떠다니는 나무 조각에 불과하다. 장애물을 헤치고 나아갈 능력도 없고 여러가지를 고려하여 의사 결정을 내릴 수 도 없다.

결국, 관리자 타이틀은 가지고 있지만, 리더로 여겨지지는 않을 것이다.

5. 모든 개발자는 똑같다.

기술 작업의 본질을 이해할 수 없다. 개발자들은 코드에 대해 아는 것, 코드로 대화하는 문화가 있다. 10배 잘하는 개발자가 다른 개발자와 동일하게 대우 받게 된다. 개발자는 항상 자신의 작업, 얼마나 열심히 일했는지, 작업에 걸린 시간을 정당화해야 한다.

어떤 회사든 최고의 개발 인재를 채용하고 유지하려면 올바른 문화를 만드는 것이 중요하다.

6. 보상

비기술 관리자는 다양한 사람들이 하는 일을 실제로 구별할 수 없기 때문에, 그들이 하는 기술적 작업을 평가하고 구별할 수 없다. 이런 점으로 인해 최고의 개발자가 보상 받지도 못하는 문화로 이어진다.

그러면 누가 보상을 받고 큰 급여를 받을까? 답은 명확하다. 가장 많이 말하는 사람이다. 가장 큰 목소리를 내는 사람이 일을 잘하는 사람으로 인지하게 된다.

왜? 평가하고 구별할 능력이 없기 때문이다.

실제로 잘하는 사람은, 이런 환경에서 일하는 것을 결코 원하지 않을 것이다.

7. 작업을 이해할 수 없음

관리하고 있는 사람들이 하는 일을 이해하지 못하는 것보다 더 불행한 일이 있을까? 개발자들이 하는 일을 알지 못한 채 어떻게 그들을 대적하거나 변호할 수 있을까?

개발팀을 관리한다면 프로그래밍 개념에 대해서 알아야 한다. 숙련된 기술자만이 다른 기술자로부터 존경을 받는다.

“왜 개발자들은 경영 업무를 이해하려고 하지 않을까?” 라고 묻는 사람이 있을 수 있다. 답은 관리자가 개발자를 돌보는 역할이지, 그 반대가 아니라는 것이다.

8. 지나친 단순화

아인슈타인이 말했다. “모든 것은 가능한 한 단순하게 만들어야 하지만, 더 단순하게 만들어서는 안된다.”

안타까운 현실은 대부분의 관리자가 프로그래머에게 기술적 개념이나 문제를 설명할 때 좀 더 쉬운 용어나 쉬운 설명을 해달라고 요구한다는 것이다.

이런 접근 방식의 가장 큰 단점은 기술적인 내용을 지나치게 단순화함으로써 프로그래밍의 본질적인 복잡성과 기술 작업의 특성을 전달 받지 못한다는 것이다.

이로 인해 개발자가 하는 모든 일이 지나치게 단순화되어 편향이 생길 수 있다.

결론

이 글을 읽은 우리는 관리자가 비기술자일 때 발생하는 문제를 알게 되었다. 개인적인 경험에 의하면, 관리자가 자신이 관리하는 사람들과 그 사람들이 하는 일을 진정으로 이해하지 못하면 어떤 것도 해결할 수 없다는 것이다. 비기술 관리자에게 관리를 받고 있자면 문제가 생기면 개발자는 관리자가 프로그래밍 개념, 매커니즘, 아키텍처, 직면하는 문제 등을 알고 있는지 확인하는 것이다.

이렇게 일해야 하는게 맞을까요?

개발자가 맞추는 것이 아니라, 그 조직을 관리할 수 있는 관리자 혹은 기술적 능력 부족을 극복할 수 있는 관리자와 매칭해주는 것이 정답이라고 생각한다.