工程師轉職管理職心得 @ PressPlay

Raguhn Lee
Mar 3, 2019 · 12 min read

我第一份管理職的工作在2016年,是在高雄的小新創公司。整間公司不到十個人。而真正像個管理職是在2017年我加入PressPlay之後的事了。

工程師時期的心態

在面對第一線時期的我,主要工作是接受來自主管或是PM的需求,把程式寫出來,而有時候我會很納悶「為什麼這個東西看起來就很奇怪,難道他們都想不到嗎?」

反應了之後雖然有些可以得到認真的解答,但大部份是問了反而問題更多,或是對方沒有想要和我爭,開始搬權力出來化解事情。最後我還是抱著疑惑把東西作出來,然後抱著疑惑上線。然後看著那些我覺得很奇怪的東西在線上運行,然後收到我早就知道會出現的客訴,或修正的需求出現。

「看吧!我就知道會這樣」這是心中的OS。

我想了解產品設計是怎麼一回事,所以我就開始看有關產品設計的文章,訂閱大神們的BLOG,然後發現書本上講管理的正確概念,現實生活中應該要有,但是不太常出現。這時候看PM在作事情時會充滿疑惑,為什麼他那樣作?不是應該要怎樣怎樣作才對呢?

例如不會擋掉來自老闆的奇妙需求,明知道是不對的但仍要作。或是時程很奇怪,功能在後期一直追加,甚至是真正的開發時間是給老闆看的final review後到原訂的上線時間…(那麼前面都在幹嘛?)

在PTT SoftJob版上看大家分享碰到的問題都差不多,取暖推文中也撫慰了我好幾個年頭。

我一直納悶:「為什麼大家都知道對的事情,但都作不到呢?」


心態的轉變

2017年8月,我正式承接部門主管一職。我多年來的疑惑有機會可以驗証了。

「為什麼時程總是那麼趕?」
「為什麼需求一直改來改去,好好想清楚很難嗎?」
「為什麼老闆想要馬兒好,又想要馬兒吃屎就好?」
「讓工程師可以安心工作的制度真的那麼難嗎?」
「如果是我來作,我會怎麼作呢?」

在我接下主管職時,我就要來試試看以前的主管們作不到的事情真的那麼難嗎?我的目標是讓工程師身心健康地工作,曾任工程師的我,很清楚達成這幾點就可以讓工程師安心工作:

1. 良好的設備
2. 讓工程師們有機會作自己想作的事
3. 讓工程師們了解策略方向和手上作的事的關係和重要程度
4. 良好的scope和開發時程
5. 良好的制度和報酬

工程師其實蠻單純的,只要滿足前四點,第五點就不會太拘泥。而且能滿足前四點的公司,基本上都會達到第五點。

我身為一間新創公司的技術主管,公司制度還是概念,是可討論的階段,正適合讓我來實現我的目標,並體會看看是不是那麼難。

咁!還真的很難….

視野的轉變

在當主管之前有作過PM的工作,了解PM是在工程師和老闆們中間的夾心餅干。很多時候是身不由己的,不…應該說是大部份的時候。當工程師聽到從PM口中說著奇怪的需求而抱怨時,他們並不知道在這個會議前,PM花了多少心思讓這個怪東西從80分怪降到20分怪了。當然也是有些PM只是老闆的傳聲筒而已。而重視「合邏輯」的工程師對於「怪需求」的接受度不高,所以常會有PM和工程師對立的情況發生。

以前作工程師的我,對到只是PM或主管,而作了技術主管的我,對到的是老闆、業務單位、客戶和整個市場。接收到資訊量是以前的數倍至數十倍。

以一個新創公司來說,組織小速度快是優勢,所以我們需要快速的反應市場,才能夠在資金燒完前殺出一條血路。那麼我們就要有所取捨。

最常被拿來說明的集合圖

工程師會想要邏輯架構清晰,蓋出堅固又富有延展性的功能,那麼就會慢。在一開始人員還沒有充足,甚至還請不動技術大神時,只能作出快又成本低的東西,那麼品質就會比較差,畫面普普,三不五時有bug要修。要變得成熟穩定需要一段時間。

如果讓工程師慢慢打造出有品質的東西,那麼動不動就是三個月以上的開發期,要三個月後方向不變對新創公司還真的有些難,可能作好了之後,發現三個月前沒有想清楚,而作出一個漂亮而沒人用的東西。

通常拿快但品質不高的方案和品質高但要花比較多時間的方案給老闆選,他通常的回答是:

老闆的野望

這已經是家常便飯了。在工程師位置的我可以很輕鬆地說有一好沒兩好,事情要取捨。但我會把自己也放在老闆的處境,公司要成長,又有資金壓力,沒有作出好東西比較不容易達到成果,然後募資難度變高,然後更有資金壓力。所以都會進行以下的對話:

我:「A方案比較快達到我們的目的,不足的地方要用人工來處理。B方案呢變動比較大,但比較完整,系統建立起來以後就沒什麼好擔心了」

老闆:「那有沒有什麼辦法可以快,然後完整又穩定呢?」

最後會走向作一個初級版本,畫面看起來OK,流程也OK,後台部份粗糙點,甚至部份用手工的,然後上線後再安排優化的方向。

要和老闆達成共識就死了我許多腦細胞,那麼接下來就是要和工程師們說明要作這件事了。

這還不包括過兩天老闆的想法又改了,想要重啟討論。也不包括初期人力不足,制度不完全,其他部門對工程開發流程沒有概念而產生的溝通事件。

要在時間、人力、資源中找到一個平衡是非常困難的事情。這都是在未轉職成PM或是技術主管前,一個小工程師無法體會的事情。

開發產品是要尊重產品的靈魂

產品成長到一定程度後,彷彿就有了靈魂,是個活生生的人。我們雖然是打造產品的人,但是無法把我們所有的期望都實現。它就像人類一樣,我們好像身為父母。我們對小孩子有期待,希望他以後可以變得厲害,達到我們對它的期待。

但實際上我們無法強壓我們的期待上去,我們只能作的是「幫助它成長」。例如我們希望我的iOS APP可以有購買的功能,以便讓使用者可以搜索專案、查看專案介紹,甚至訂閱。但是唯一解套方式是像遊戲公司一樣買點數然後去消費。而新增一個金流管道是件極費工的事。

如果我們APP在2018年初剛上線時要作到這個功能,勢必就要在6個月前就要籌備這件事了,而那時的PressPlay的人力物力都無法支援這件事的發生,要也是可以啦,但是變成現有人力都要為此投入,然後完全無視這半年發生的問題。

就好像連站都沒有站穩的孩子,而就要他為了跑步比賽作準備,然後學講話、學上廁所、學自己吃飯通通省略了,這樣子就算可以參加跑步比賽,但是後續的人生問題還是一大堆啊。


在打造PressPlay這個產品,就好像所有人在一艘船上,大家分工有的查地圖,有的划漿,有的指揮,有的看路。每一個人的節奏要在同一個韻律上。新增人員、讓人員上手、負責轉向的人、水象皆會影響整艘船的平衡。我們必須在船體平衡下調整重心、熟悉工作技巧、修補船身、讓新船員適應,然後再擴建這艘船,同時看前方有沒有什麼暗礁之類的要閃開,還要留意不要被敵船碰上了。

開發產品就像所有人都在同艘船上

這是人世間最困難的事了!!我當了主管後才有深刻意識到維持一艘船的平行是那麼困難的事。以前工程師時期,所管的事就是系統架構和需求,對上層的決定百思不得其解,甚至在PTT上看到別人有類似的狀況時,也會跟著抱怨「難道他們不覺得奇怪嗎?這件事不是應該要怎樣怎樣怎樣嗎?」

就好像我以前沒開過船,只是站在岸邊平穩的地上,但在指責船上的人怎麼開船。

老闆和工程師們都是人

我思考的突破點是某一段時間我都在陪老闆聊天,聊他過去的經歷和對產品的看法。我聽到他講出宛出Junior產品人員的想法時,我才想到「啊對,老闆年紀比我小。而且工作沒多久就出來當老闆了,他還在學習當一個老闆。」

我才想到以前對上頭的抱怨總是抱著「他應該要懂這些東西啊」,都是站在主管或老闆是個成熟、熟練的角色,只要他作出非成熟的判斷時(而且成不成熟的標準是由不成熟的我來決定),我就會對他失望。

我為什麼對主管、老闆那麼嚴苛?
為什麼這種想法是根深蒂固在我心中,以致於我沒有發現呢?
我為什麼覺得他們什麼都要會呢?

這些都是我在轉職後,視野變廣後,在公司裡已經肩負要維持船的平衡責任的時候才冒出來的問題,甚至覺得奇怪,我為什麼以前沒有想過呢?

老闆也是人,年紀還比我小,工作經驗沒有長,就連婚姻時間也少我個七八年。再來我又是工程專業,我比他懂是很正常的。我對於其他不懂的人都有耐心和他們說明,為什麼面對老闆態度就變了?

這其實是一個華人世界的人生大課題:權威議題。不過這不是本篇的重點,我就不提我如何探索這個問題了,有機會再說。


總之,我對老闆的方式不再是拿超高標準去對他,而是理解他有不懂的地方,有需要學習的地方。然後仔細去看他擅長的地方是哪邊,然後有需要他的意見,或是能運用他擅長能力的地方,我就去請教他。

碰到討論策略,或是開發功能的事時,若發現他不懂,我也把我的看法和經驗告訴他,不懂的地方講到他懂。然後他也會分享他的角度看到的東西,有些時候我會驚訝於他的想法,因為是我完全沒想過的方向。有時候可以套到產品,有時候不行。

不過沒關係,光把老闆當人看(?),而不是當作是「權威」就已經讓整個工作順暢許多了。


同理,對於工程師提出的問題,我可以用工程師的語言,來說明這個決策是怎麼訂下來的,包含面臨的情況、中間有什麼困難、然後我怎麼作決定的、未來會朝什麼方向,說明清楚後,大家都可以接受了。

我回想起以前,PM或主管常說「老闆覺得不OK,決定吧啦吧啦」實在是太簡略了。說明的確會很花時間,但我只是嘗試和以前不一樣的作法,反而省下大家互相猜忌的時間,以成果來看十分划算。

而我也會和老闆聊到工程師們的顧慮,並以過去開發系統的經驗,說明快快作的隱性成本、決策改來改去會影響士氣、訂定開發流程或使用某某開發工具的必要性等。老闆的確會吸收會學習,當花時間告訴他這些知識後,之後的討論效率愈來愈好,因為我們的資訊漸漸對齊了。

我的溝通技巧

我沒有辦法告訴你如何有效的溝通,市面上有很多老師專門在教這門技術,我看愈多其實愈不懂。因為看是一回事,懂是另一回事,你要知道在什麼情況用什麼方法又是一大學問了。

如果要我建議的話,我建議是先有一個認知「每個人都是不一樣的個體」。最糟的溝通法叫「說服」,因為抱著要說服人的心態去溝通,只是把自己的價值觀強壓在別人身上。極端一點的人是說服失敗還會當著面罵對方白痴。

而是去好好暸解對方是什麼樣子的一個人,背景、學經歷、喜歡什麼不喜歡什麼、作事和思考的方法等。愈暸解一個人,你就愈明白他為什麼這樣想,如果他困住在某個想法中是為什麼,你要如何把他從思考的迷宮中拉出來。

不否定對方,甚至是認同對方的某些說法,順勢帶出你看到的問題和想法,去引導對方思考。如果對方在忙或是擺明沒心思和你討論下去,也不用強求當下要有個結論,可以改天再來。

還好我有替人解夢的經驗,引導對話還算熟悉,為了暸解人類,還去上了人類圖的課程。這個課程讓我明白很多事情,有的人先天就有自己消化資訊的方式,有的人作事急急忙忙但漏東漏西,也有的人需要幾天的時間沉澱一下才不會亂作決定。當你明白每一個都是不同個體,有著不同運作模式的時候,自然而然就會用每一個最適合的方式去和他互動。有了這層尊重,溝通合作自然會比較順。

人類圖 :看見每一個人不同的設計

如果要一句話來總結我溝通的技巧,我會說「把每一個人當獨立平等的個體,用適合對方的方式去對待。」

現在工作的心態

我今年滿37歲,我已經渡過20幾歲什麼都想作,30歲找方向努力向前走的時期。30歲的後半,我想作的事是「培育和傳承」。

2018年下半年,我默默地在找可以頂替我的人。這個經歷很有趣,我尋找比我厲害的工程師,然後把Web工程師們交給他。起初我有點擔憂,如果找了比我厲害的人,那麼是不是沒有我的位子了呢?不過回想起以前公司,有些技術部門的主管,是部門的天花版,那麼這個部門技術要成長勢必要主管成長才有辦法。

那麼,如果我找比我厲害的人,並把位子讓給他,我是不是就失去價值了呢?說實在的我有點緊張,但很犯賤的我(?)就會想去試試看。2019年1月,我正式把所有Web工程師交給一個從別家公司挖來的高手,讓他去帶領。

而我專注在定訂開發流程,並把這套流程推廣出去,讓老闆、業務單位都知道如何有效率的參與到工程的開發中。同時也帶著設計師和PM進行設計和開發,我所能作的就只是把經驗傳承給他們,告訴他們某某情況用什麼方作比較好,要怎麼和其他部門的人討論,然後在他們熟練之前,都是在幫他們厘清問題和處理較複雜的事。

喔對,還有背鍋。我們公司願意讓員工去嘗試,而且我很變態,我喜歡看人在自己想作的事上努力求突破的糾結的樣子(?)。所以工程師和設計想嘗試作的事情,我都不會拒絕。

也因為他們知道我會鼓勵嘗試,所以不會提那種太離譜讓我難作人的事,都是在現有開發主線上想玩的新花樣。但有時候實驗失敗了,我也會一同被砲,然後再想辦法修改。

也因為我們彼此都有信任在,所以我從老闆那得到奇妙的需求時,他們也不會太為難我XD

放權給其他人的目的只有一個,就是沒有我你們也要活得好好的(?),因為我不能因為我擔心我的地位而把關鍵的東西握在手上。人生只有一次,我會想嘗試別的東西,所以我要把手空出來才能去接新的東西來玩。


結論

人生是不斷學習碰撞成長的。我常常碰到問題時會回想起「以前的主管會怎麼作?」,然後去想想現在我應該怎麼作。通常我都可以理解以前主管作出奇妙決策時的原因,但是我大部份選擇的是和他們不一樣的路,而是我現在覺得正確且平衡的決定。

就目前的成果看來,還不錯。希望我明年看到這篇時,能有更多的體會可以再寫下來。

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade