愛伊米

大廠存在過“螺絲釘”嗎?

每個人進入職場之後都會面臨各種各樣的選擇和難題,比如是進大廠還是進創業公司,又比如進入大廠之後,是不是真的只能當業務上的“螺絲釘”,等等。而關於這些問題的答案,也許你可以從業務崗位、個體選擇等方面著手解答。本篇文章裡,作者便發表了一定看法,一起來看。

大廠存在過“螺絲釘”嗎?

總會在網際網路上看到一些觀點,例如:

“大廠福利是好,但是做的事情比較機械。”

“感覺在大廠就是一枚螺絲釘,做的內容比較簡單,還是創業公司成長大一些。”

彷彿在“大廠”與“螺絲釘”之間,已經畫上了一個約等號,但是真正進入一些網際網路圈子/職場APP,又總是看到一些“績效越來越難寫了”“組織架構又變了”這類的討論,圍城內與圍城外,彷彿兩個世界。

接下來本文將圍繞以下幾個觀點展開,淺談一下對於大廠螺絲釘的思考。

“螺絲釘”認知的背後;

個體與公司的選擇;

平臺能力與個人能力。

一、“螺絲釘”認知的背後

許多人會認為螺絲釘只是負責一個板塊的業務,簡單,單一,固定,構成整個部門業務的一部分,不用想別的,只需做好自己的事情。

然而現在,大廠真的還有這樣的螺絲釘嗎?

來看看以下的場景:

小茗經朋友介紹進入了一家大廠,在熟悉業務後,逐步承接固定的板塊,保證交付,當偶爾涉及到跨部門協作的時候,去找下上下游的同事溝通合作,這看起來像是一個好的工作氛圍,但不知道什麼時候,節奏變了。

他最直觀的感受就是資源和預算一直不夠用,隔壁幾個部門爭相推出內部孵化的創業專案,不僅員工的精力被大幅度消耗,大部門總的預算也所剩無幾,三個小部門做了三個模式出來,內部賽馬還彼此不相容。

資源/預算不夠用帶來的影響便是“呼叫資源/預算的難度“大大提升,等到內部透過多次對齊的會議磨合出一個方案10。0版的時候,發現風口已經過去一大半了。

這樣的場景在大廠中屢見不鮮,作為大廠打工的“螺絲釘”,在做好手頭工作的同時,還需要能想清楚業務規劃,搭配資源支援,否則業務很可能將逐漸“邊緣化”。

即使只是負責固定的板塊,依舊需要面對許多不確定性。

有沒有相對更穩定一些的”螺絲釘“崗位?來看看以下兩種情形。

大廠存在過“螺絲釘”嗎?

1. 工作量極大的崗位

存在一些技術無法完全替代人力+工作量極大的崗位,典型的便是大廠中的稽核和客服人員。

1)場景一

以重內容的平臺的稽核人員為例,小茗每天都要對創作者釋出的短影片進行初輪稽核,每天的工作固定,即必須要在下班前完成XXX份稽核,不然第二天不僅會有積壓,使用者滿意度也會直線下降。

更令他擔憂的是,他很難從這份工作中抽象提煉出什麼,因為量級實在是太大了,且停留在每個內容上的時間已經被精確到以秒為單位,上升的空間相對很小。

但是即使工作強度大到這個地步,上級領導依舊對他們這個崗位提出了更高的要求,希望透過小茗團隊在一線不斷積累的一線經驗,賦能技術團隊完善機器稽核,然後來讓團隊承接更多的稽核量。

大廠存在過“螺絲釘”嗎?

2)場景二

以重服務的平臺的客服人員為例,小茗每天都要線上解答使用者使用產品的疑問,包括不限於各種關於定價,功能,渠道的問題,經過一些問題的收集,小茗所在的團隊輸出了一版QA文件,並做成了線上的功能,同時優化了問題的分發與流轉,這些運營動作的確大大提升了團隊工作效率,但是上級領導依舊對他們這個崗位提出了更高的要求,希望在保證處理問題效率的同事,使用者滿意度可以再上升5%。

大廠存在過“螺絲釘”嗎?

大廠對員工的要求,往往沒有最好只有更好,如果從外向內看,“螺絲釘”們所有的成果會在企業財報裡籠統的總結於幾句話:

公司今年盈利收入XXX,相較去年提升XXX,其中,公司的重點專案在XXX領域取得重要突破,已搭建XXX人團隊開展專案。

十個專案角逐出三個專案,其中一個專案被重點表揚,剩下的“螺絲釘”們並非沒有工作產出,只是沒有出現在企業的財報中。

2. 業務趨於穩定的崗位

相對於工作量極大的崗位,大廠中還存在一類業務狀況,即專案本身已經趨於穩定,屬於無需過多人力維護的狀態,但是使用的使用者數目不少,而且在使用過程中可能又會出現新的問題和新的需求,所以也需要有人兼併處理一下。

面對一個增長空間已經達到上限的專案,大廠可能會採取以下舉措:

大廠存在過“螺絲釘”嗎?

拓展其他同類型專案,擴大業務面;

將原專案組的人手抽調去做其他專案;

在原專案組中繼續探索新的業務增長點。

當專案組給出的成績一直不盡如人意,一些在原有崗位上未做出亮點業績的員工,很容易被認為是團隊中的“螺絲釘”,長期這樣下來,員工拿不到更好的資源和機會,現有的業務也很難找出迭代的機會和跨部門的支援,在下一次組織架構合併時,業務可能就被合併了。

結合上文,“螺絲釘”認知的背後,往往對應著工作量大但上升空間相對小的崗位+與崗位能力模型不匹配的員工。

一些工作量極大的崗位,員工完成手中的工作後,自我成長的時間所剩無幾,他感覺自己像是一枚螺絲釘,但是大廠依舊給了他更高的挑戰,期望他完成更好的業績。

一些與崗位能力模型不匹配的員工,即使崗位存在著機遇與挑戰,員工心中也並無熱情,只希望儘快完成手中的工作,長此以往,他成為了別人眼中的“螺絲釘”。

辯證的看待“進大廠之後就成為了螺絲釘”這句話,一方面,大廠往往都希望員工發展成為在“螺絲釘”崗位上有傑出成就的人。

另一方面,隨著部分網際網路賽道的增長趨於平緩,一些大廠也感受到了壓力,選擇在組織架構中剔除“螺絲釘”業務。

二、個體與公司的選擇

1. 個體的選擇

1)當你被安排到“螺絲釘”崗位時,你會怎麼做?

假設今天小茗作為大廠的一名員工,接到了一項工作任務,小茗覺得這是一份“螺絲釘”工作,與此同時,同事小陳接到了一樣的工作任務。

幾個月過去,差距逐漸展開,小陳優化了這個工作任務的整體流程,透過技術手段的引入,大大減少了人工的處理。

同樣性質的工作任務,在不同人手裡可以做出不一樣的效果。正如上述這個例子所說,一些工作,在一部分員工眼裡是“螺絲釘”。

在另一部分員工眼裡,可以發現細節,找到破局點,總結專案管理的方法,最佳化它並嘗試讓技術/機器代替它,甚至向團隊論證這項業務存在的意義(如果業務合適就大力推進,如果業務不合適就調整資源分佈),厲害的人,總會提出更恰當的解決方案。

如果真的排斥“螺絲釘”類崗位,引入一個思考角度,就是在面試前,除去對於當前確定要做的業務,可以瞭解一下整個部門架構的業務情況。

大廠的快節奏,經常會出現員工轉業務/轉專案的局面。學會提前瞭解整體的業務氛圍,例如大部門整體偏做線上還是做線下,做C端還是B端等,用更包容的心態去面對未來可能會做的業務,對業務規劃存在預期準備,從而進行更好的選擇。

2)你會對“螺絲釘”崗位做出調整嗎

執行具體工作時,時常會遇到以下幾類博弈,尤其是當你對整體業務都有了一定的認知的時候,博弈會更為明顯,例如:

大客戶提出了一個需求,這個需求涉及到技術底層程式碼的改寫,改動極大。

這塊流程需要最佳化,但是其中一個環節涉及到跨部門的溝通,需要協調對方的資源。

競品在整體節奏上快了不止一步,如果要追趕對方的節奏提高市場覆蓋率,會超出預算。

單單看以上幾句描述,其實很難做出真正理性的決策,只有清楚的知曉當中的背景,程序,卡點和預期結果,才能更加清楚:

如果要進行調整,付出的資源能不能和得到的結果持平,ROI是不是正的?

大廠存在過“螺絲釘”嗎?

從試錯成本,實際效果,戰略意義等角度進行考慮,一些好的變革,往往圍繞“成本極小”“效果顯著”“自上至下”等角度進行實操,成為了行業標杆案例。

變革也需要循序漸進,只有身在這個業務,確定自己是有發言權的人,才能更好的對你負責的專案做判斷。

在專案推動的過程中,可能也會出現一些來自上下游的想法和建議,這又是另一波觀點探討了,就好像“每年都有XXX人想教產品經理做產品”。基於商業角度來說,每個人所處的位置不一樣,使用者表達感受,產品經理做出產品,PMO則需要審視全域性,探索找出最利於系統穩步上升的路徑和方法。

所以即使身處“螺絲釘”崗位,也需要有戰略意識,對工作範疇進行迭代調整的時候,需格外關注ROI。

2. 公司的選擇

公司會怎麼佈局自身的業務和人員安排?

大廠存在過“螺絲釘”嗎?

以一個團隊舉例來說,團隊中需要以下幾類人:

定戰略的人,即需要把控團隊整體的決策,確定業務方向;

整合幾條業務線的多維度反饋,向上彙報給老闆的中層領導;

整合一條業務線,向上彙報給中層領導的小組長;

執行人員,向上彙報給小組長。

如果團隊人多,那麼便是好幾位小組長/中層領導,如果團隊人少或者屬於內部新型孵化專案,還未調整組織架構,也存在執行人員直接向上彙報定製戰略的可能性。

上述提到的層層彙報,映射出一些大廠中的客觀事實:員工的能力是被一步步驗證的,在晉升制度下,員工升到對應的職級,都需要員工論證他已經擁有那個職級所對應的能力模型。

如果是新招進來的員工,預期培養成小組長/中層領導,基本上也需要先熟悉執行層面的工作,放到“螺絲釘”崗位去實踐一番,如果在不熟悉基本業務的情況下,很難制定出合適的戰略。

所以,公司將你放到“螺絲釘”崗位上,可能存在多種情況:

公司想透過“螺絲釘”崗位讓你快速熟悉業務;

公司現有架構內的業務基本全部屬於“螺絲釘”崗位;

公司有一些之前遺留下來的業務,不打算再投入新的成本,但是業務需要有人維護;

……

公司安排人員到崗位上的顧慮可能有千千萬萬種,但是員工自己內心需要明晰當前的就業環境和個人發展規劃。

大廠存在部分“螺絲釘”崗位,極大的工作量導致一些基礎的崗位離不開人手。但是假設企業在未來啟動戰略變革,選擇將一些基礎的工作內容以外包的形式進行承載,那麼一些“螺絲釘”員工,將失去自己的核心競爭力。

三、平臺能力與個人能力

伴隨著“大廠崗位許多都是螺絲釘”這句話,另一句話,相信很多人也不會陌生,那就是“不要把平臺的能力當成自己的能力”。

與其在未知詳細背景的時候,猜測平臺能力與個人能力之間的關聯,不如進一步透過完善的資料和系統化的認知,客觀論證自己的能力。

許多人在面試的時候自我介紹來自於大廠,會附上自己的經歷,例如做出了多少資料,產生了多少營收。光鮮的履歷背後,會引發一些質疑:

“他的資料這麼高,是因為那個產品本身日活就高吧”

“上一個他們公司來面試的,做的也是這個功能,我看不到創新點”

“又是一個把平臺能力當作自己能力的”

……

1. 如何體現個人能力

出現上述略顯矛盾的場景,是什麼原因導致的,員工又如何體現個人能力呢?

來看看下述內容。

大廠存在過“螺絲釘”嗎?

1)平臺能力和個人能力深度耦合,無法割裂

當員工身處大廠,成為大廠的一份子,所做的決策大多基於公司的戰略,所獲得的反饋也少不了公司的資源加持。

但是這並不代表集體光環下,就可以忽視個體的閃光點。

大廠之所以能成為頭部公司,並持續不敗,離不開背後的每一個閃光且努力的個體,如果沒有了那些所謂的“螺絲釘”和部門中負責把控業務節奏的各層領導,許多公司也無法在這個逆水行舟不進則退的商業世界裡維穩。

無數個不甘於做“螺絲釘”的員工,一起構建並增強了公司的能力。

所以迴歸上述提到的觀點,在平臺能力和個人能力深度耦合,分不清自己的能力邊界時,如何客觀闡述自己的能力?

① 擁有全域性思維

許多人講不清楚自己跟進專案的資料,是因為這個專案涉及到多個業務方,一部分資料得益於A流程,一部分資料來源於B部門,未知全域性,很難理清專案整體的邏輯。

在這個場景下,員工如果擁有全域性思維,例如全面瞭解團隊業務所在的節點,認清自己在整個專案中起到什麼角色,並客觀講清楚自己為專案帶來的貢獻,這些具有全域性思維的論證,往往更能凸顯個人的能力

② 擁有迭代思維

假設三個月前,A團隊負責這一業務,他們做出了怎樣的成果;三個月後,你帶著B團隊和A團隊進行交接,開始負責這一業務,你們做出的成果,是否有顯著的進步和亮點?

客觀闡述你接手業務之後帶領團隊做的迭代,例如以更少的成本拿下XXX客戶,整體的成交額增長率上升XXX,這些具有迭代思維的資料,往往更能凸顯出個人的能力。

2)跨部門專案繁多的情況下,KPI共背

如上文提到,許多大廠都會存在跨部門的合作專案,這類專案往往存在一個問題:它的指標是整體的,甚至有時候只有一個。

看看下述的場景:

小茗之前做過APP推廣活動,同樣參與活動的還有其他地區的人,而小茗完成工作任務之後,無法看到後臺對應的開啟率,只有總負責人可以看到,而總負責人定期在群內公佈的資料,是全國的資料,小茗無法得知自己所帶來的實際效果是什麼,只能得出一個籠統的結論:100人共同提升了30%的開啟率。

這類結論一樣會存在於目前的大廠,跨部門合作專案中,大家整體圍繞著一個目標努力,如果要清晰的得出自己團隊的產出的話,需要怎麼做呢?

一是上文提到的,擁有全域性意識,需要了解自己團隊在這個專案中擔任的角色,負責產品板塊還是運營板塊,明確有哪些業務方會共同推進合作,出現需要解決的問題時,找哪個負責人。

二是大目標下的小目標需要具體落實到人,大目標下,多方共同朝著一個目標努力,但是當目標拆解之後,需要有不同的業務方負責完成拆解後的小目標。那麼即使KPI共背的情況下,團隊也可以清晰的知道自己的工作達成了什麼結果。

迴歸上述APP推廣的案例,如果當時小茗和總負責人溝通,推動專案組把30%的開啟率這一目標按照地區活動人數分佈/使用者分佈等維度進行拆解,應該就可以產生更清晰的結論。

平臺能力和個人能力從來不是等號,至於是大於號還是小於號,往往取決於員工和公司在業務領域內的相對能力。

2. 去大廠還是創業公司

這是一個不陌生的問題,許多職場文章的評論區下,都會出現這樣的討論:

去大廠感覺像是去當螺絲釘,去創業公司感覺什麼都要會,大家覺得怎麼選?

這便會出現兩種情況,部分員工從大廠跳槽到創業公司,會有不適應,不適應自己負責不止一個板塊。

而當部分員工從創業公司跳槽到大廠,也存在不適應,不適應自己剛開始只負責一個業務板塊。

去哪類公司其實要結合許多因素,例如時代背景,就業趨勢,個人偏好,行業熱門……

大廠存在過“螺絲釘”嗎?

一部分人說,大廠好,列舉了大廠的多個優點;另一部分人說,創業公司好,論證了創業公司的業務潛力。

去哪裡其實都是個人的選擇,許多員工會選擇去一個當下最能凸顯自身勢能的公司,發揮自己的價值,而這個選擇,往往是公司與員工的相互選擇。在做出選擇的那個時刻,員工看好公司的亮點,公司看好員工的能力,能合作多久,便看磨合程度了。

提示:平臺文章內容為個人當前觀點,基於行業更新變遷/個人想法迭代等多重因素,不構成決策~

專欄作家

燈衍,公眾號:阿燈筆記,人人都是產品經理專欄作家。95後網際網路運營人,關注內容創作和流量變現。

本文原創釋出於人人都是產品經理,未經許可,禁止轉載。

題圖來自unsplash,基於CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。