顯示具有 頭銜 標籤的文章。 顯示所有文章
顯示具有 頭銜 標籤的文章。 顯示所有文章

4/05/2020

如何成為主管 (成為主管的31堂課)



一般資深的軟體工程師,或多或少都會有思考過也許自己可以當領導者- team leader, manager等等。

主管people manager的定義很簡單:就是有人直接對你報告,並且你負責直接管理團隊裡的人,包含考績評估,工作指派,以及,最差的情況下要解僱某人。

沒有人生下就會寫程式,當然,也不會有人生下來就會當主管。然而,和寫程式不同,主管很難事先「練習」。所以這就變成雞生蛋,蛋生雞的問題。

在組織趨向扁平的情況下,如果有心想要往主管方向前進,最好要做到以下三件事情:

自動擴大責任:


也就是,主動做跨出自己工作範圍的事情。這裡並不是指自告奮勇擔任福委會主委,或者安排一些團康活動,雖然這些對大企業來說也很重要,但如果時間有限,應該優先考慮:跨出自己工作範圍,但仍然還是在軟體開發工作的本質上。

這件事聽起來容易,但做起來相當難。尤其是資深的工程師常常手邊已經有忙不完的任務,自請擴大任務搞不好吃力又不討好。然而,這卻是成為主管的最必要且最實際的路。

要擴大責任範圍,最簡單的做法是先了解自己的主管現在在忙什麼,可以先幫他處理必要但是瑣碎的事情:例如,撰寫例行報告,安排會議,會議結束後的記錄和執行事項的追蹤,列出現在正在進行的風險控管等等。有些事項,表面上看似秘書類型的工作,實際上對掌握大局有相當大的幫助。

其次是針對雖然不在自己任務範圍,但是是很重要的技術事項,花額外時間的主動幫忙解決。在稍具規模的企業中,這種事情多如牛毛,問題只在於有沒有人有空去解決它。

尋找業界導師:


如果你覺得目前主管是個好主管,那麼可以主動要求他擔任你的導師(mentor)。其次是尋找在同公司中的其他主管,真的找不到再去尋求其他公司的主管。你所需要的導師最最最起碼要符合這些條件: (1). 工作經驗至少比你多5年。(2).至少在同一個組織裡有2.5年以上的管理經驗,(3).必須是樂觀進取的人。以上這三個是最低門檻,最佳的情況會是7~10年差距。超過13年可能會有反效果,最好要有數個成功的軟體專案經驗,起碼有10年以上的工作經驗,並且有至少雇用10人以及解雇人的經驗。

找一個自己的導師,聽起來難做起來相當簡單。重點在於只要去做就可以了。有幾個基本的事情要注意 (1) 誠懇地請求幫忙,並約定這幫忙的時間每週1小時而已,並也約定為期僅有6~24個月 (2) 不要一次找很多導師。一段時間(6~24個月)有一個導師即可 (3) 約好固定的諮商時間:每週30分鐘,或者,每兩週1小時都可以,聚焦於過去一兩週的實質問題的建議 (4) 誠摯的感謝和長遠的關係,比實質的利益來的重要太多,強烈不建議付補習費,遇到需要索取補習費的導師就表示你可能找錯人,但是每週的諮商時間,請杯咖啡之類的小事倒是可行。(5) 如果可以的話,最好是12個月以上,但如果可以的話也不要超過24個月

在工作上遇到的問題,尋求業界導師過去的類似經驗,是最佳的參考。

留在還不錯的公司:


這個世界上沒有完美的公司,每個企業組織都有好的地方和不好的地方。只要覺得自己現在的環境沒有特別糟糕,目前所在公司仍然願意投資資源在人才培育,自己的主管是可學習的對象,那麼應該起碼考慮未來3~5年留在同個組織發展。一般而言,內部升遷的機率是大於外部空降。尤其是,如果你現在還未曾擔任過主管職,從外面招募一個沒擔任過主管的人來當主管的機率微乎其微。

大部分的人,總有看到別人碗裡面肉比較大塊的感受。然而,一旦發現自己目前的主管非常糟糕,組織文化負面而且破碎,當然要儘速離開的好。

最後,如果連續數個公司都待不到2年,應該是要檢討自己,而非檢討環境。




12/23/2018

軟體工程師的職稱頭銜重要嗎?



軟體工程師根據所在的環境不同,通常有不同的職稱頭銜。例如:程式設計師,工程師,技術經理,架構師,策劃工程師,平台工程師等等。對應於英文可能會有:programmer, engineer, technical manager, architect, principle engineer, platform engineer。 在大組織中,升遷可能是職稱上的轉換,例如在前面加個「資深」,大家就都知道你被升遷了。

對於轉換新的工作來說,職稱頭銜是否重要呢?

1.以工作的本質來說不重要


就技術為主的軟體工程師來說,(假設並沒有直接負責管理員工),職稱頭銜幾乎不重要,更重要的是做事情的內容和能力的展現。

假如在一個組織裡,一位新進員工的職稱是「sr architect資深架構師」,但他的工作內容實質上是對客戶提案,撰寫業務報告。則其實他是做接近pre-sales或者sales-consultant的工作。在未來無論是組織內部還是他要對外尋找工作,通常還是評估實際做的事情為主,並非職稱。

2.以團隊角度來說可能很重要


職稱是公開的,一個團隊組織裡如果有工程師,資深工程師,資深架構師這三種不同職稱的人:一般來說,大部分的人會傾向遵循同意資深架構師的意見。特別是剛組成的團隊或者互相不認識的團隊。畢竟,職稱的功能有時候類似制服,當你在路上看到穿著警察制服的人,在需要協助的時候自然而然會傾向找穿警察制服的人幫忙。

然而,就軟體開發組織成長來說,職稱的重要性是伴隨組織成長的缺點。這個缺點和人類的認知偏誤有很大的關係:團隊貢獻中,絕大部分的人會認為自己佔比重比較大,因而,在決定升遷或者其他公開獎勵時,一定會有很大比例的人覺得自己沒被升遷是不公平的。

團隊貢獻中,大部分的人會認為自己佔比重比較大:許多實驗(參考這裡)都說明,假設一個團隊的總貢獻是100分,有10個人自己評估自己佔的比重,並且加總起來,很容易就超過150甚至250,但這實際上是不可能的。

也因為大部分的人都有這種偏誤,導致於職稱很多時候對軟體開發團隊有負面影響。如果有重新建立軟體開發團隊的機會,可以採用「無職稱」或者「自選職稱」的方式。


3. 無職稱頭銜讓團隊與夥伴的三贏

當組織沒有職稱時,無論是中期還是短期發展,組織成員會更專注於「實質工作產出」而非「表面變化」。這對組織,對團隊成員,甚至對組織外的人都有好處:

- 對組織的優勢


在組織內,成員都知道自己「做出的事情」才是決定自己的「職稱頭銜」,而非「職稱頭銜」決定自己「做出的事情」。自然而言,團隊成員就會以提高自己的能力和對組織的影響力,並且使用的方式不會是以頭銜和權威。升遷和加薪兩者同時都變成機密,再也不會影響其他人的心情。

當組織要招募人才時,組織會更專注於了解應徵者「過去做的事情」,而不是過去有的頭銜職稱。過去我們面試的時候,常常在履歷表中看到非常驚人的頭銜,但是實際上做的事情可能非常基本。

無職稱會讓面試的效率提高,錯誤率降低很多。

- 對團隊成員的優勢

當團隊成員想要換工作時,在他對外面試的時候,很容易就專注於展現自己的產出。而非說明自己的頭銜。

同上一小節之說明,團隊成員專注於工作的本身而非頭銜的表面公平性不足時,更能發揮自己的潛力和提高產出。

- 對組織外部的優勢

其他外部組織在遇到沒有職稱的人前來面試時,更容易專注於尋找人才得要件。換言之,本來評估能力和是不是適合,本就不應該和職稱有關。已經有人自己不帶著職稱頭銜前來面試,就更容易避免錯誤。