GitLab 數據經理經驗分享:工程師當上主管,該專注於團隊還是 coding 技能?

【為什麼我們要挑選這篇文章】對工程師主管來說,兼顧團隊管理與 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」
【投稿】想當產品經理,一定要有工程師技術背景嗎?


全方位掌握消費者數位軌跡

AI 如何有效提升電商業績、降低導入成本?

《領取白皮書》

點關鍵字看更多相關文章: