개인적인 정리
Lana Brindley는 Timescale의 문서 관리자라고 합니다. Red Hat, OpenStack, SUSE 등 다양한 기업을 거쳐 Timescale에는 2021년 합류했습니다. Timescale은 시계열 데이터에 대해 SQL을 확장하고 분석하는 도구라고 합니다.
2018년 시작한 회사이고 이쪽 분야에서는 독보적인 기술을 보유한 듯합니다.
앞에서 화려한(?) 경력을 가지고 있다고 설명했는데 정확하게 어떤 회사인지는 말하지 않지만 이 정도 규모의 문서 팀에서 일했다고 합니다.
(1) 4명에서 시작해서 14명까지
(2) 2명에서 시작해서 9명까지
(3) 오픈소스 커뮤니티 (다수명)
(4) 1명에서 시작해서 2명 (스타트업. 회사 망함)
(5) 1명에서 시작해서 현재 3명(Timescale)
팀을 확장하고 싶다면 일단 계획이 필요합니다(의사결정자를 설득하기 위한).
* 노자의 도덕경을 인용하는데 원문은 아래와 같다고 합니다.
제66장 - 남의 위에 서려거든 자신을 낮추어라
江海所以能爲百谷王者, 以其善下之, 故能爲百谷王,
강해소이능위백곡왕자, 이기선하지, 고능위백곡왕,
是以欲上民, 必以言下之, 欲先民, 必以身後之,
시이욕상민, 필이언하지, 욕선민, 필이신후지,
是以聖人處上而民不重, 處前而民不害,
시이성인처상이민부중, 처전이민불해,
是以天下樂推而不厭, 以其不爭, 故天下莫能與之爭.
시이천하낙추이불염, 이기부쟁, 고천하막능여지쟁.
강과 바다가 계곡들의 왕이 될 수 있는 것은 그것이 가장 낮은 곳에 있기 때문이다. 그래서 모든 계곡의 왕이 될 것이다. 그러므로 백성 위에 있기를 바란다면 반드시 겸손한 말로 자신을 낮추고 백성의 앞에 서고자 한다면 반드시 몸을 남의 뒤에 두어야 해 준다. 그래서 성인은 위에 있어도 백성들이 짐스러워 하지 않고 앞에 있어도 방해된다고 여기지 않는 것이다. 세상 사람들이 그를 받들면서도 싫어하지 않는 것이다. 다투려 않기 때문에 누구도 그와 다툴 수가 없는 것이다.
팀이 중요한 이유 중 하나는 그들이 있기 때문에 당신이 휴가를 즐길 수 있다는 겁니다(현실적이네요).
어떤 팀을 만들 건지 결정하는 것도 중요한데 팀의 특성이나 프로세스, 가는 방향이 명확하지 않으면 팀원들이 일하는 시간대가 다른 경우(Timescale은 풀타임 리모트) 매번 관리자에게 확인을 해야 할 수 있습니다. 때문에 팀원 모두가 공유하는 방향성을 가져야 합니다.
예를 들어 Voltron(백수왕 고라이언 百獣王ゴライオン 미국판 리메이크)의 경우 각 부분(합체된 부분)이 자신의 역할을 알아서 수행하는 것처럼 팀원들도 그래야 합니다(같은 시간대에 같은 장소에 모여 일하는 경우에는 또 다른 관점을 가질 수 있으나 이번 세션에서는 온전히 리모트 환경에서 일한다는 전제하에).
팀원들에게 업무를 어떻게 할당할 것인가도 고민이 필요합니다.
제품별로 문서를 담당할 것인지 아니면 프로젝트마다 업무를 할당할 것인지.
제품별로 담당할 경우에는 해당 제품에 전문성을 가지겠지만 다른 제품에 대한 이해가 떨어지며 프로젝트 단위로 할당하는 경우에는 모든 제품에 대해 어느 정도 이해가 필요합니다.
팀원이 많아지는 경우(그렇지 않더라도) 갑작스럽게 팀원이 오랜 시간 참여하지 못하게 되고 그런 경우 업무를 다시 나누어야 하게 될 수도 있습니다.
누구를 채용할 것인가?
일단 자신과 같은 사람을 채용해서는 안됩니다! 절대!
경력이 화려한 사람을 뽑는 것이 안정적인 듯 보이지만 인터뷰에서 강한 인상을 보이면 경력보다 우선적으로 마음이 땡길 수 있습니다.
커뮤니티(WTD 같은)에서도 충분한 인재풀을 가지고 있지만 더 많은 이들이 커뮤니티에 참여하지 않을 수 있어서 특정 커뮤니티에만 의존하는 것은 바람직하지 않습니다.
인터뷰 시에 같은 질문과 점수 카드를 사용하라고 권함. 뭐 물론 조직마다 다르겠지만 일관성이 인터뷰를 유용한 도구로 활용할 수 있는 방법이라고 합니다.
최초 2배로 성장할 때가 중요합니다.
1명에서 2명이 되는 시기죠. 첫 번째 팀원을 위한 온보딩 프로그램을 시간을 내어 준비해야 합니다.
그렇다고 너무 방대한 목표를 제시해서는 안됩니다. 기본적으로 다루어야 할 제품을 접하게 하고 어떤 도구를 사용해 문서화를 진행하는지 경험하게 합니다.
지식의 저주
무언가를 알수록 설명하기 어려워진다. 와는 상관없을 것 같은데. 하여간 위에서 잠깐 언급했지만 팀원들이 물어볼만한 것들은 이슈가 생길 때마다 어딘가에 기록해놓고 팀원들이 언제든지 찾아볼 수 있도록 해야 합니다.
좀 더 규모가 커질 때
10명 이상의 팀원을 직접 관리하는 것은 좋지 않은 생각입니다. 5명 정도가 적당합니다. 규모가 커지면 그룹으로 나누고 각 관리자와 커뮤니케이션합니다.
경력 관리 부분에서는 관리자와 테크니컬 라이터로 계속 일할 이들을 구분할 수 있습니다.
테크니컬 라이터는 인포메이션 아키텍트, 문서 엔지니어, 콘텐츠 개발 전략 등으로 확장할 수 있습니다.
또 하나 중요한 건 문서 팀이라고 해서 모두 자신의 경력을 계속 문서 팀에서 유지하지는 않을 것이라는 겁니다.
PM이나 마케팅 쪽으로 경력을 키워나갈 수도 있습니다.
예를 들어 팀원이 5명이고 3가지 제품을 다루고 있다면
규모가 큰 제품에 3명을 할당하고
나머지 제품에 각 1명을 할당합니다.
그렇다고 해서 서로 커뮤니케이션을 하지 않는 것은 아닙니다.
같은 도구를 사용하고 아이디어를 공유합니다.
제품에 대한 이해를 공유하기 위해 모든 문서는 초안부터 공개적으로 작업되어야 합니다. 그리고 제품 관련 미팅이나 정보는 기록되어 언제든지 접근할 수 있게 합니다. 하지만 이런 노력에도 불구하고 일부 지식은 공유되기 어려울 수 있습니다. 때문에 어느 정도 같이 일하는 단계가 필요합니다(쉐도잉이라고 표현).
관리자가 되면 이제 글쓰기보다는 더 많은 미팅이 필요합니다.
업무 회의 외에도 각 팀원이나 하위 관리자와의 일대일 미팅을 진행해야 합니다.
관리자가 이야기하기보다는 경청하고 있다는 느낌을 주어야 합니다.
업무뿐 아니라 팀원들의 삶에 대해서도 공감해주어야 합니다.
Q&A
인터뷰(질문)는 어떻게 하나요?
같은 질문을 여러분 하게 되면 그 질문에 대해 사람들이 어떻게 반응하는지 직관적으로 알 수 있습니다.
인터뷰와 테스트는 어떠한가요?
테스트를 사용할 때는 제한된 시간 동안 글쓰기를 하는 테스트를 진행합니다(1시간 정도).
인터뷰에서 좋았는데 테스트가 엉망이었다면 테스트를 무시하기도 합니다.
영상
현장 스케치
Lana Brindley (she/her) - From Me to Us: Building a docs team from the ground up
Explore writethedocs' photos on Flickr. writethedocs has uploaded 2645 photos to Flickr.
www.flickr.com
