[조직문화 만들기] 사내 테크 블로그 기획하기

기획 과정에 대한 글은 아니다.
그냥 테크 블로그 하고 싶은데, 딱히 우선순위가 높은 일이 아니다보니 지지부진한 것 같아 일단 글 먼저 쓴다.
추후 이 주제에 대해서 이 글에 추가하거나 할지도?
노션에 쓸 수도 있긴 한데, 그래도 일단 블로그에 올린다고 생각해야 좀 글이 술술 이해하기 쉽게 써지기 때문에.

테크 블로그 하려는 이유

우리 개발팀에 팀장을 제외하고 디자이너와 기획자 2명, FE 2명, BE 2명 모두 또래들이다.
즉, 주니어 경력이다. 심지어 사실 나는 신입이다. 제일 연차 많은 분은 최근 입사하신 BE 개발자로, 이분도 1년 반 남짓의 경력이시다.
주니어 경력의 조직에서의 문제는 조직 전체의 레퍼런스와 경험이 부족하다는 점이다.
모두가 누군가가 리드해주기를 기다리고 있다는 느낌을 받았다.

테크 블로그는, 팀원 한 명 한 명이 조직의 리더가 될 수 있는 기회를 주는 것이다.

블로그에 올릴 글을 작성하게 되면, 그 글에서만큼은 내가 리더다.
회사 업무에서 대부분 “문서 작업” 이라고 하면 기획자의 업무를 생각하기 쉬운데, 사실 개발 업무에도 많은 부분 문서화가 되어야 하는 부분들이 있다.
어쩌면 누군가 시키지는 않았더라도 개발자분들 모두가 현재 어떤 문서가 없는지 파악하고 계시리라 생각한다.
스스로 그런 문서 작업을 진행하지 않는 이유는, 흔히들 자율성이라고 부르는 성질을 갖추지 않았기 때문이 아니다.
어떤 문서를 누군가의 지시 없이 한다는 것은 곧 그 업무의 책임자가 오롯이 나라는 뜻이 된다.
업무 자체의 투여 시간 뿐만 아니라 성과, 피드백, 유지관리, 인수인계… 모두가 자신의 업무가 된다는 뜻이다.
당장은 가벼운 일처럼 느껴질 지라도, 멀리 내다보면 사실 여러 업무들이 연장선 안에 등장하게 된다.
그 업무들을 맞닥뜨릴 것을 알고 있기 때문에 쉽게 하나의 업무를 자율적으로 시작하지 못하는 것이다.

그런데, 작은 조직이라면 사실 주요 업무 외의 자잘한 업무들까지 스스로 해야만 한다.
소위 ‘제너럴‘한 역량을 갖춰야 하는 것이다. 누군가는 별로 좋아하지 않는 스타일일 수 있다. 효용이 좋지 않은 자잘한 업무 때문에 주요 업무를 하지 못하게 될 수 있기 때문이다.
하지만 그런 업무들을 처리하는 배경 마음가짐에는 조직 구성원으로서, 조직에 대한 주인 의식이 깔려있다. 주인 의식이 있는 직원이 더 성실히 일한다는 건 자명한 사실이다.
물론 주인 의식을 고용주 측에서 강요할 경우에는 열정페이로 전락하기 십상이다.
그러나 스스로 주인 의식을 한 번 가지게 된다면, 업무의 거시적 맥락을 파악하고 로드맵 상에서 조직 전체의 진행 상황을 깨닫고(메타 인지) 그 속에서 알맞게 업무 강도를 조절하거나 스스로 업무를 찾아서 하거나 하는 등, 지시 없이도 일할 수 있게 된다.
결국 지시 없이 일할 수 있게 된다는 것은, 상사의 존재가 필요없다는 뜻이다. 여기서 상사란 업무 지시자로서의 상사를 말한다.
(당연히 전사적 과제를 주는 상사는 존재한다. 단, 전사적 과제란 맥락도 불분명하고 기한도 모호한 경우가 많기 때문에 이 진행 계획을 스스로 세울 수 있어야 한다.)
물론 멘토로써의 상사 혹은 사수의 역할이 중요하긴 하다. 이 부분 역시도 조직 차원에서 구성원 개개인의 학습 시간을 충분히 보장하고 장려한다면 메꿀 수 있는 부분이라고 생각한다.

운영 방식에 대해서

현재 기획자 님과 나(프로덕트 디자이너)는 당장에 우선순위가 높은 과제들이 있기에 좀 바쁠 예정이다.
그러나 개발자님들은 아직까지 과제들을 맞닥뜨리지 않은 상태로, 얼핏 듣기로 머신러닝 스터디가 최근 하기로 결정됐다고 들었다.
물론 스터디도 앞으로의 어려운 과제들을 처리하기 위해서 불가피한 숙제다.
그러나 사실 스터디도 마찬가지로 CTO 님의 제안 하에 생긴 것으로 알고 있고, 우리 조직의 시니어급인 4명의 개발자들이 여전히 나머지 주니어 개발자의 경력상 선배 위치기 때문에, 팀원분들 한 분 한 분의 자율성을 보장하기 위해서 시도해볼 만한 가치가 있다고 느낀다.

따라서 CTO님과 팀장님 2분 외 7명의 팀원이 모두 두루 참여하는 형태로 운영하려고 한다.
카테고리는 일단 여러 글을 모아본 다음에 분류하면 될 것 같다. 초반엔 분명 우리만의 블로그일 것이기 때문.
복잡한 생각없이 그냥 주 2회정도 두 명이 각자의 글을 완성하고 서로 피드백한 다음 동시 업로드하면 될 것 같다.
주제는 자유. 개발자가 조직 문화에 대한 글을 써도 좋겠다.

단, 목적은 “정보 전달”, “조직 문화 공유” 로 한정지으려고 한다.
특히 “정보 전달”도 단순히 뉴스 기사 등을 인용하는 식의 글보다는 스스로 스터디를 하게 된 내용을 정리하는 형식으로.
“조직 문화 공유”는 사내에서 하게 될 여러 이벤트들에 대한 홍보성 글이 예시다.
당장은 특이한 조직 문화가 없지만, 앞으로 이렇게 테크 블로그 운영처럼 여러 종류의 조직문화를 시도해보고 찾게 될 텐데, 그 정리의 장이 되면 좋겠다.

테크 블로그 시작을 위한 액션 아이템

차주는 월요일 공휴로 화요일에 아마 팀 Sync Up 회의를 하게 될 듯하다.
이때 테크 블로그를 비롯하여 조직 전체의 업무 파이프라인을 구축하고자 제안을 하나 발표할까 한다.
발표 마지막에 테크 블로그 베타 서비스 시작한다고 알려야겠다. 사전에 유저를 몇 명 꼬셔둬야 한다.
이를 위해서 몇 분한테 글쓰기 좋아하시냐고 좀 떠보긴 해야 할 듯.

한 사람만의 업무가 되는 것은 바라지 않기 때문에, 무조건 2인 1조로 진행할 생각이다.
일단 나는 제안자로서, 블로그의 첫 글을 장식하고자 1명이 될 거고 나머지 한 명은 랜덤하게 추첨으로 정할 것.
우리는 모두 스터디라는 명목하에 주 1회 2시간 미팅을 가지려고 한다. 이 때 글을 작성해도 되고, 글 작성을 위한 스터디를 해도 된다.
단 2시간동안 혼자서 숙제한다는 느낌이 아니라 그냥 서로 두런두런 이야기 나누면서 업무에 대한 사담을 나눠도 되고, 어찌됐던 글감이 나오기 위한 시간을 가진다.

이렇게 글을 쓰다보니 든 생각인데, 우리 팀이 조직된지 채 2달이 될까말까한 조직이라서, 근 2달간 팀빌딩을 명목으로하는 사적 미팅이 너무 잦았다.
물론 일이 아니니까 나는 너무 좋긴 했지만, 각 자리가 그저 휘발성을 띄는 소위 ‘노는 시간’이 되어서는 안된다고 생각한다.
글을 쓰는 걸 어려워 하는 사람도 분명 있을테니 이런 분들을 위해 글자 수와 사진 개수 제한을 두어서 가볍게 써올리는 포스트도 허용하면 좋겠다.
어차피 주에 2개 글이 올라오니까, 둘 중 한 명은 무조건 “정보 전달”형 포스트를 써야겠지만!ㅎㅎㅎ 두 명이 서로 업무적 Cap을 고려하여 양보하면 될 것이다.