![]()
【為什麼我們要挑選這篇文章】對工程師主管來說，兼顧團隊管理與 coding 技能非常困難，若要帶好團隊，就必須犧牲 coding 時間，若要貢獻自己的 coding 專長，勢必無法花時間在團隊運作上。以下，是 GitLab 數據團隊經理的管理經驗分享。（責任編輯：郭家宏）
今天文摘菌（本文作者）為讀者們推薦一篇文章，來自一位數據工程師 Taylor Murphy 分享的，他成為數據團隊經理一年以來的經驗教訓。
2018 年 4 月到 2019 年 5 月期間，我擔任 GitLab 數據團隊的經理。在我的經理離職後，我開始以數據工程師的身份直接向 CFO 彙報工作。
我記得對他說：「對於您來說，讓我擔任經理似乎不是正確的選擇。」我還表示不想長期擔任經理的角色，因為我之所以來到 GitLab，從經理變為工程師，就是為了專注於數據工程領域。
下面是我任職數據團隊經理一年學到的（並重新學習的）一些經驗教訓。我的目標是再次成為一名經理，希望能記住這些經驗並學到更多。
考量公司需求，招募足夠數量的數據人員
我擔任數據團隊經理期間，GitLab 的規模成長了約 300%。對於以前只在知名公司和一家很小的新創公司工作過的我來說，我並沒有準備好應對這種成長水平及相伴隨的的資源壓力。
最近我對數據部門中的同事做了個調查，發現大多數公司數據團隊的數量占全體員工數量的 2% 至 8%。
這意味著一家擁有 200 名員工的公司應至少有 4 名數據人員，實際上大約有 10 名人員，包括數分析師、工程師、科學家和經理。2018 年 4 月，我們的人員低於 1%（1/300），且整個 2018 年繼續低於 1%。
隨著公司的發展，我並沒有完全瞭解企業計劃的實施，以及數據團隊將如何擴張，以滿足各部門的數據需求。由於缺乏戰略思維，我對數據和分析的需求應該達到多少才算合理感到迷茫而不知所措。
雖然我聘用了更多優秀的人才，但沒有做好我的工作來幫助我的團隊取得成功。
經驗：數據團隊經歷應該瞭解公司的發展軌跡，擁有和期望承擔的工作量，合理選擇人員的數量，堅持招募並考慮團隊結構。
要不就專心寫程式，要不就專心帶團隊
2018 年底，我們的數據團隊由三個人組成：一個數據分析師，一個數據工程師和我。可以自信地說，我們三個人的工作能力都十分出色，超出三個普通全職員工的工作水準。
但是我們也有侷限，很多事還是來不及做。
由於工作量巨大，有時我需要同時承擔分析師和工程師的工作。所以我常常一次想同時做好幾件事。
有時候，我需要做很多管理工作，所以就沒時間處理分配給我的工作。如果專注只做我自己的事，我又沒法管理團隊。最糟糕的時候是我同時想做兩件事情，但一件也做不好。
隨著時間的流逝，這種分身無力的情況變得越來越糟，我開始感到身心俱疲。
我本可以僱用更多的人，但這又對我的管理能力提出了更多要求，工作量在增加，而我還是代碼庫的主要編輯者和維護者。後來，我覺得自己既不是一個好經理，技術也在變差。
經驗：如果你是經理，請做一名全職經理。是的，你需要承擔一些工作，尤其是在專案開始時，但要想清楚退出機制，以便將這項工作交接給團隊，團隊會比你做得更好。
找到最棒的團隊成員
僱用優秀的人才會使你的工作更輕鬆。最初數據團隊的四名員工（2018 年兩人，2019 年初兩人）擁有令我歎服的好奇心，堅韌和智慧。
我從以前的工作和老闆那裡學到了尋找優秀人才的重要性，以及他們在完成工作時的驚人效率。
經驗：堅持僱用優秀人才，並考慮如何能夠大量招到賢才。
優化技術流程，提升運作效率
我從 Emilie Schario（我僱用的第一位數據分析師）那裡學到了這一課。她教我思考公司擴大規模時，如何以及在何處需要流程，以便保持高效。
我們用 GitLab 來管理程式碼，並且內置了合併請求工作流，但是她花了一些時間來思考圍繞該流程的混亂的人員管理。
她建立了一個簡單的列表：
▌新分析師的入職準備；
▌入職腳本以幫助新分析師快速進入角色；
▌合併請求的模板，因此每個人都遵循同一個待查清單。
雖然她不是經理，但她經驗豐富，並且知道在公司哪些環節掉鏈子會拖慢整個團隊的進度，她想讓工作盡可能自動化。我從公司外部那裡聽說很多人對我們的文檔，尤其是入職流程十分讚賞。
這件事說明這位同事非常擅長思考如何讓工作效益規模化，也有同理心去理解 GitLab 新手的處境，從他們的角度去看問題。
隨著數據團隊的成長和發展，技術化越來越重要。這意味著投資技術流程也很重要：包括對所做的一切都設計版本控制，變更控制（合併請求），自動化測試和文檔。
一些工具可以使實施技術流程變得更好，更容易，我將在下一節中重點介紹。
經驗：
深入思考過程並記錄一切。
保持初學者的心態並不斷思考：對新人來說，第一天使用 GitLab 是什麼體驗。
記錄過程，文檔和測試會讓你在未來十分受用。
選擇最佳工具：dbt
隨著過程的進行，選擇合適的工具可以成為團隊事半功倍。一開始，我們使用 PostgreSQL 作為數據庫。Postgres 不是面向序列的，且在一些時候不能將其用作分析數據庫。
但無論如何，選擇 Postgres 是因為我們相信使用無聊的解決方案，並且它與我們的疊代價值保持一致。對於要處理的數據量，Postgres 的表現十分讓人滿意。使用 CloudSQL 託管的版本，該版本能夠使用 GitLab CI 進行出色的編程工作。
一旦超過 Postgres 的處理能力，我們就決定用 Snowflake。
當然，GitLab 的產品可以用於任何事物，這為我們節省了挑選工具的壓力。從程式碼的角度來看，它有你想要的所有功能，而作為經理，它能幫你提升團隊辦公室協作效率。不需要單獨使用 Trello、Jira 和其他工具。
到目前為止，對於數據團隊的效率而言，最好的工具是 dbt（數據建構工具）。如果沒有 dbt 和偉大的團隊，我們將無法以如此有限的人手，來為公司和社區提供良好的支持。
經驗：團隊最佳工具，用 dbt！
積極為表現不佳的員工提供協助
直到 2019 年，除了幾名實習生，我沒有僱用過一個能力不足的人。主要原因是我挖優秀人才的能力比較好，但也有可能只是運氣比較好。
去年，我的團隊中有兩名能力不足的員工，現在我意識到，當時本可以提供更好的支持。當我沒有把自己當經理時，我就很難與員工好好溝通。我的建議是要關注前幾週的工作表現，如果發現技能或積極性上有問題，儘可能以友好和高效的方式指出改進方向，然後為員工提供一切提高的機會。
經驗：要做好團隊管理，需及時察覺事件的發生，積極為團隊提供幫助。
盡可能幫下屬擋掉會議
GitLab 有優秀的開會文化。
首先會議要準時開始，要提前確定議程，若議程順利可提早結束會議。但即便有如此嚴格的紀律，你還是會發現你的經理日程表被大量會議佔據。但這都不是問題。這是工作的的一部分。
我仍會建議你減少會議時間，但如果你需要開會，如果可能的話，儘量讓團隊中其他隊員免於會議。對於生產者來說，比如你的直接下屬，會議是件很麻煩的事。儘可能幫他們擋掉不必要的會議。
經驗：會議是工作的一部分，但要儘可能減少，避免團隊成員參與不必要的會議。
你需要高層的支持，推動高品質的數據文化
我當初很樂意加入 GitLab 的原因，是因為公司管理層很支持建立一支數據團隊。即使在細節和執行方式還處於模糊階段，CEO 和 CFO 都明白數據團隊能帶來的效益。這很重要。如果公司管理層沒有人能夠明白描述性和預測性分析的價值，你就會處於一個艱難的位置。數據品質是一種企業文化，如果 CEO 不想推動，這種品質是不太可能發展起來的。
在一定程度上，你要有超出團隊經理所需的數據領導力。你需要一個主管級別以上的人在公司內部離推數據。高管需處理的日常工作很多，因此沒法在這方面花費太多時間。
經驗：要小心那些公司管理層不相信數據的公司。最好要有主管級別以上的人員在公司推動數據。
做好一些投資的準備
公司高管對數據團隊的支持是非常重要的，因為搭建數據團隊並不便宜。要提高效率，必須招募多名員工，或者為加強數據管理購買第三方軟體。
首先，你需要諸如 Stitch 或 Fivetran 之類的數據提取和加載工具，需要數據庫（例如 Snowflake、BigQuery 或 Redshift），需要計算來轉化數據，還需要 BI 工具。也有些免費的工具可以湊合一段時間，但如果你需長時間使用，最好投入一些資金。
經驗：遠期的成功離不開投資。剛開始可能可以少花些錢，但兩上去了必然需要花費資金。
不要自己造車，花點錢請第三方公司完成
尤其像從比如 Salesforce、Zendesk，或是 Zuora 等工具中提取數據時，千萬別自己寫腳本來完成。花點錢讓第三方公司幫你完成即可。否則你會把大量時間花費在不能為公司帶來效益的事情上，還可能有無盡的後續麻煩。
你應該把時間花在能夠為公司創造效益的事情上，比如自動彙報和提供洞察等，而不是把 Salesforce 的 Snowflake 提取器又寫一遍。
經驗：一般的數據提取任務花點錢在 Stitch 或 Fivetran 上完成就好。
經理是一份不一樣的職業，他不是 IC 晉升的必經之路
不要把成為經理當做是你作為技術人員生涯的延伸。這是一條不同的職業道路，你的 IC 技能肯定能幫你成為一個更好的經理。但是，管理有它自己的一套技能，選擇進入該領域會使你走向不同的職業道路。對你而言是否是更好的道路取決於你如何定義成功。
進入管理道路，要認清你是換道而行而非更進一步。不過這也不是永久性的，想掉頭隨時可以。
經驗：不要認為成為經理是 IC 晉升的必經之路。認真思考你的職業生涯。
自私一點也可以，當經理不是必然道路
我曾經有些糾結如何變得自私些。我是討好型心態，這種心態在企業新創時期非常有用：新創企業需要大家樂意為公司的成功不計回報地付出（當然了，要合理！）。不過一旦公司開始走向成長階段後，這種心態就會使你異常疲憊。
在我待的上家公司裡只有不到 30 名職員。保持不斷學習和實踐的態度是很有用的。我學到了非常多，身上也背負了很多責任，也發展了公司的業務。到了 GitLab 後，剛開始這種態度是可行的。隨著時間推移，很明顯我沒法掌控所有事情，我的精力開始備受考驗。
自私點是指：我必須接受自己想從經理的位置往後退一步退回 IC 的想法。（提醒：其實不是後退一步！看看上面提到那點！）
我得承認我希望專注在程式工作上，而繼續在經理道路上前進，對我目前來說並不是一條正確的道路。這個想法其實有點自私，因為現在看公司其實需要的是一位想要當經理的人。我雖恰好處於這個職位，但不一定由我繼續發揮經理的作用。
雖然我退回到 IC 角色對團隊會有些短期影響，但我會更加舒服，現在我們團隊有著兩位經理，相信比我單人帶領團隊走得更遠。
經驗：
要作出優先級排序，為自己身心健康著想，自私些是好事。
勇敢地說「不，我不想再繼續做下去了。」
公司需要喜歡自己崗位的職員，這樣他們表現會更好，人也更開心。
我希望這些經驗對你來說有價值，能夠適用於你的生活和工作。歡迎提出相反意見，或與我分享你在數據工作上的故事和經驗。感謝閲讀。
原文 傳送門
（本文經合作夥伴 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈团队管理 VS 个人贡献：一位数据团队经理的心声 〉。首圖來源：Who uses Java, Perl, PHP? CC Licensed）
更多工程師相關消息
【coding 護國】工程師在 GitHub 開打「主權捍衛戰」，讓台灣在疫情地圖重新正名
【防疫外交】台灣人為韓國開發口罩地圖，向全球證明「Taiwan can help」
【投稿】想當產品經理，一定要有工程師技術背景嗎？
缺乏資源，卻得升級網路效能、可靠度？
回答 3 個關鍵問題，看見企業網管最大癥結點
《即刻了解》
舉一段機器學習課程來看
模型認為數據中的哪些特徵是最重要的？
