前言

• 節錄並譯自：https://klinger.io/posts/managing-people-%F0%9F%A4%AF
• 以下的「我」代表原作者 Andreas Klinger。

作者介紹 - Andreas Klinger

• I managed several small and midsized engineering teams
  • CTO at On Deck
  • prev VPE at CoinList
    • Head of Remote at AngelList
    • and CTO at Product Hunt

I wrote this article for managers of small teams/startups. I’d assume that most might not apply to management in larger enterprises. Btw here are my recommendations on joining hypergrowth companies in general.

本篇寫給小型團隊與新創團隊，未必適用於大型公司。以下是我對加入一個快速發展的團隊 (hypergrowth) 時的一些建議。

直接切入主題吧

因為你是主管，所以全部都是你的錯

我知道……這是一句非常「正向」的開場白 👀

身為主管，你沒有任何理由對你的團隊不滿：

主管是負責「指揮」團隊成員與「管理」進度的人，通常也比其他人掌握更多的資訊。

如果發生問題，要嘛是你管理的流程有誤，要嘛就是你領導的團隊成員有誤；

所以，不管怎樣都是你的錯。

要管理的是流程、要領導的才是人

基於種種原因，很多人誤解「管理下屬」就是去「控制他們的做事方式」，

最後形成 micro-managing —- 也就是俗稱的「過度管理」：成為「每件事都要插手」的主管。

如果你花大把時間在控制下屬的工作方式，那代表公司根本就不需要付你主管階級的薪水。

會出現這種情況，我認為是對主管職責的誤解：

主管的職責不是在「控制」，而是要著重在「管理」並「領導」。

主管應該要依照自己的預期去管理工作流程及安排團隊成員在流程中的職責、並且領導他們完成工作，

同時也需要把團隊成員個人的職涯規劃也納入整體的評估；

畢竟每個人還有自己目標、擔憂、動機……種種工作外的問題。

所以，身為主管，你要帶著「同理心」領導下屬，做大家的榜樣。

如果角色對調，你自己也必須能做到「你期望他們做到」的樣子。

流程是「期望結果」的具體展現

A lot of people make huge disclaimers around “processes.”

很多人對「流程」常抱持著強烈且先入為主的態度：

“We don’t want too many processes” etc

「我們不想要有太多流程」云云。

again, imho a misunderstanding

依我淺見，這一樣是個誤會。

Processes are not complex chains of people doing things that are burdened by horrible overheads

流程，不是一些複雜的枷鎖，讓團隊成員徒增難以想像的重擔；

Processes are expectations made explicit

流程，是對「期望結果」的具體描述。

They can be as simple as “every morning we all do X to ensure everyone else is unblocked.”

這些描述可以非常單純，例如「我們每天早上都會做 X 來確保大家工作更順暢」。

Have few but very explicit processes and expect them to be followed

流程數量可以不多，但都要非常具體，並預期所有成員都會遵循。

決策 vs 意見

In every discussion/project/problem/situation, it needs to be clear who makes decisions

在所有的討論 / 專案 / 問題/ 處境中，對於「誰需要負責『決策』此事」大家都要有清楚共識

…everyone else only adds opinions.

……而其他人只是提供「意見」。

Ideally, the person who will afterward do (or lead) the follow-up work makes the decisions.

理想情況下，通常是需要「接手」或「領導後續工作」的人來負責決策。

Everyone else just adds opinions.

而其他人只是提供「意見」。

This includes people of higher “rank” or pay.

這道理同樣適用於更高階的主管。

Their manager has a handbrake they can use to hard-stop decisions.

當然對於該負責決策的成員，他的主管仍然有「煞車」來防止一些意外狀況，

Treat this as a literal handbrake.

可以想成物理意義上的煞車：

Imagine a car driving, and you need to pull the handbrake because the car needs to stop, but the driver

doesn’t react. Damage will follow.

想像開車時，遇到突發狀況、但駕駛沒反應時，你需要迅速拉起煞車強迫車輛停止，否則損傷會更加慘重。

Pull the handbrake if absolutely needed and then discuss how to fix the situation.

強迫踩剎車這件事，只有狀況危急、真正需要時主管才會插手，而且必須要「與團隊討論」當下的狀況該如何解決。

Hire based on good decision-making skills

雇用具備「良好決策能力」的人，

Fire based on poor decision-making skills

反之，開除「差勁決策能力」的人。

Good decision-making skills include listening to other people’s opinions.

好的決策能力，包含傾聽其他人的意見。

In case of doubt, see if you can trust the decision-maker by default.

如果不確定此人是否具備良好決策能理力，可以問問自己是否可以在「缺乏其他資訊的情況下」信任他自行決策。

讓員工自主 (Ownership)

It’s hard to get people to own a problem space fully

要一個人對於問題成因、預期結果、解決方案 (統稱「問題空間*」) 全盤了解是很困難的，

But this is the goal

但這是目標；

If they are the wrong person, you can still fire them

如果發現該負責人是錯誤的人才，仍然可以選擇開除他。

Feedback them, help them

提供你的成員反饋與協助，

Trust them and let them make mistakes (within damage barriers)

信任他們，且允許他們犯錯 (在可接受的影響範圍內)；

Consider mistakes “them leveling up”

把犯錯當成讓他們進步的機會。

The worst thing that can happen is that you frequently step in, and people disassociate from their work

最差的狀況就是「因為你頻繁插手，讓成員覺得此項工作與他無關」，

They become drones who do what’s told instead of taking ownership.

最後變成「無人機」型的員工：只會聽令行事而不會主動參與。

If this is your goal, you can hire cheaper, less talented people.

當然，如果你需要的只是「無人機」型的員工，大可雇用更便宜、更普通的人才。

*譯注：Problem Space：https://zh.m.wikipedia.org/zh-tw/%E9%97%AE%E9%A2%98%E7%A9%BA%E9%97%B4

避免來來回回

When defining processes, avoid back and forth

在定義流程時，要避免產生「來來回回確認」的結果。

Eg. if you give feedback on something assume that they will either do it or get back to you with reasons why not

例如，你某事給出了一個回饋意見，理想狀態下應該是：同仁「直接去做」、或只會回頭問「為什麼不這樣做」；

Don’t expect them to get your approval

而不是指望同仁回頭跟你確認是否同意。

Ain’t nobody got time for that

沒人有那個時間做這件事。

信任

Always reflect if your nervousness is due to other people’s work or your insecurity

永遠忠實反映你的不安，自問其究竟是來自於「其他人的工作成果」還是自身的「不安全感」。

Should other people have to handle your emotions for you?

其他人有必要替你處理你自己的情緒嗎？

Also, it’s easy to trust when things go well

另外，當事情順利時，信任彼此非常容易，

The real challenge is when things go wrong

信任真正的挑戰都是在出現危機時。

Always differ between your frustration about a situation and your frustration about a person

當你感到挫折時，永遠要區分清楚究竟你是對「現在的處境」還是「某人的表現」感到挫折？

I am not saying “stay out of it”

解決方案並非不再讓某團隊成員處理，

Stay in the loop, set expectations, voice opinions, but let them handle it. Use your handbrake if needed.

而是在說明清楚你對這個工作的「期望」、及自己的「意見」後，仍然讓該成員全權處理；當然，如果情況不對仍然要適時踩下「煞車」。

建立以「透明」為基礎的信任

The easiest way to have people trust your work is by transparently sharing it without request.

若要讓其他成員信任你工作的成果，最簡單的方式是：不等待其他人的詢問就先「公開透明地分享」內容；

Have everything accessible where people would look for it

將所有內容，開放完全的讀取權限給所有可能有關的成員

Don’t make them ask for it, because most won’t

不要讓其他成員「需要詢問權限」才能存取，因為沒有人會這樣做。

Trust is not binary

信任不是零與一，

We tend to think of trust as binary

我們常錯把信任當成非黑即白的選項：

I either trust someone, or i don’t

我信任某人、或是我不信任他。

But this isn’t true

但這不是事實。

You trust different people with different things differently over time.

你隨著不同的時間，會在不同的事情上，信任不同的人，

Think of trust as something that you systemize

把信任當成可以系統化處理的事情：

Eg what kind of trust do you give a new team member?

例如：哪種信任是你可以給新進的成員？

What are they expected to do in the first weeks? first month?

你預期他們第一週要做什麼？第一個月要做什麼？

別搞混「自治」與「放生」(autonomy and abandonment)

• I frequently meet founders who hire people “and get out of their way”

我常常遇到一些 Founders，他們相信「雇用新成員、但自己退出管理盡量不阻礙團隊發展」。

• While this is in principle correct, it doesn’t absolve you from enabling them to succeed

雖然這件事原則上是正確的，但「提升『使團隊成員邁向成功』的機率」仍然是這些 Founder 的責任。

職責階層 (Decision Layering)

Different people in the company on various levels rely on each other on doing their work.

公司中不同的人都各有不同的分工階層：

A product manager can’t do their job if the CEO doesn’t know what their current priorities are.

例如，當 CEO 不清楚目前公司最優先發展的方向時，產品經理便無法正常工作。

Don’t load your work onto others in the company.

所以不要把你職責應該要做的事情分攤給其他人，

And also avoid stepping into their work just because looks more fun.

也不要去插手其他人的職責範圍。

避免「路過」型管理 (Avoid drive-by management)

Don’t start throwing your opinion or ideas around in meetings

不要隨意加入遠端會議、或在遠端會議中「隨意」拋出你的意見或想法，

You most likely lack context, and most likely, you won’t be the person needing to follow through.

你很有可能不懂事情的脈絡、且你更有可能不是那位需要接手處理的負責人

Make it clear that it’s just opinions and not decisions.

若要拋出意見，要確認在場的人都清楚「這只是意見，而不是決策」

But know the power that the “opinion of the founder (or manager)” has towards most employees

但還是得知道，主管 (或是老闆) 的「意見」對大部分員工仍非常有影響力，

Use fyi tags in async communication that usually lacks the “nuance” of voice.

所以適時加上 FYI 的註記 (For Your Infomation)，可以補上以純文字*溝通時所缺乏的細微語調。

Btw, I call it drive-by management because the manager comes by a group of people having a discussion.

我稱呼這種作法為「路過」型管理，是因為通常主管都在同仁討論事情中途加入，

They throw requests, change mandates, and ideas around like bullets, create confusion, panic, chaos, and when they leave, they leave a bloody mess behind.

然後開槍掃射一樣隨意拋出各式各樣要求、改變命令、或提供想法，讓所有人產生困惑、驚慌與混亂；最後離開時只留下一堆爛攤子給大家。

*譯註：或稱「非同步溝通」，與「同步溝通」的差別在於，不用等待對方回應。文字訊息是非同步溝通，可以傳出去後不用掛在線上等待對方回應；而電話與會面則是同步型的溝通，需要掛在線上、或是空出時間面對面。

給同仁回饋

people x context = output

同仁 x 脈絡 = 成果

I had great people in bad setups that had lousy output

我遇過才華洋溢的人，配上糟糕的組織、制度，最後卻產生不盡人意的成果

I had very ordinary people in great setups that churned out more work than a whole team

我也遇過平凡人，但配上絕佳的制度，最後成果竟然可以超越一整個團隊。

When you feedback work, it’s usually easier to discuss the context objectively than the person themselves

在對工作的脈絡提供「主觀的」感受或意見時，針對「工作內容」討論會比起針對「同仁本身」討論來得容易。

What is the situation that led to current problems?

例如，「什麼情況下導致了目前的問題點？」

What changed? What is currently required?
「什麼東西改變了？什麼是目前工作所必須的項目？」

A junior engineer not keeping up with the work?

「新進的工程師尚未跟上目前的進度？」

Is it their fault? Or is your team right now not able to support a junior learning the game?

「是他們的錯嗎？還是目前你的團隊無法協助新進工程師上手？」

This is ok, but should be either fixed or acknowledged (by discontinuing)

這些狀況都可以接受，但是這些狀況如果不是「修正」它、就是「中止」它

A huge production incident happened?

「在正式環境遇到嚴重的突發事件？」

How was this possible in the first place?

「這當初到底是怎麼發生的？有哪些可能成因？」

Where was the focus of the engineering team?

「工程團隊之前聚焦在哪些問題上面？」

Was there a process in place to avoid it?

「有哪些流程可以改善以避免這種問題？」

Should there be one?

「或是否需要一個新的流程？」

The person breaking production isn’t at fault here.

並不能完全怪罪於搞壞正式環境的人。

A whole team focused on other priorities

團隊應該要將注意力聚焦在其他更重要、更正確的事情上，例如

Was this for the right reasons? (eg release pressure?)

更正確的方向：「發生這個嚴重問題，是否有哪些可改善的內部因素導致？例如新版本的開發進度壓力過度緊湊？」

Or the wrong ones? (lacking sophistication?)

錯誤方向：「是不是有人太沒品？」

Always assume people you hired are motivated, and have the best intentions in mind

永遠都先假設你雇用的同仁充滿幹勁、而且有良善的動機把事情做好；

And fire the ones that don’t

並開除那些不具備這些狀態的人。

解僱不應該讓對方出乎意料

People should never be surprised that they are fired

同仁永遠不該對即將被開除感到驚訝。

Context changed; new requirements should have been communicated

「營運方針有調整」、「公司有新的需求」等狀況，都需要經過彼此溝通

When you discontinue someone, you do it usually because of context

當你需要請同仁離開，通常都是因為「策略調整」、

The company changed

「公司方向改變」

The expectations of the role changed

「公司需要的角色已經改變」

You realized you looked for the wrong hiring criteria

你意識到「你目前的提出僱用條件已經不合時宜」

It’s most likely more your fault than theirs

所以更像是你的錯誤，而不是對方的

They might have hoped that their new efforts were enough

他們也許會希望在接到離開通知後，有作出改變可以讓情況不同，

But they will still understand when you fire them

但最後他們還是會理解為什麼公司現在需要他們離開。

不拖延解僱

Once you decide to fire someone, do it.

一旦你決定開除某人，就直接做。

Frequently people keep employees around in a zombie-like state

大部分的主管不會直接開除，只讓那些不適任的同仁維持在跟殭屍一樣的狀態

“We should discontinue them.”

心裡想著「我們應該開除他們」

But you don’t

但你沒有

It’s not for them

保留職位並沒有讓對方更好

They are most likely unhappy in their setup

他們通常會對目前的組織更不滿意

Not appreciated

不熱愛現況

Not able to do good work

無法把工作做好

You are most likely doing it for yourself

所以你不開除他們更多是為了你自己

Because you are not feeling good about firing someone

因為你如果開除他們，你會感到抱歉

They deserve better than you caring more about your feelings and future than theirs

但是比起「你的感受」，他們值得更好的地方、一些能為他們帶來更多發揮空間與效益的地方

Set up a call and discontinue them

安排一通電話，然後請對方離開

Avoid any chitchat in the beginning

避免一開始有任何閒聊

Start directly with the topic and have explicit clarity on the next steps

直截了當地開始主題，並清楚說明下一步的規劃

Make sure to communicate it as fact and truth

確保你們溝通的內容都是基於現況、與事實

Remember that in this moment it’s not about your feelings or problems

請記得處理這件事時，重點不是「你的感覺」或是「你的問題」

Then help them find new roles

而是在幫助對方找到「新的角色」、「新的發揮空間」

They trusted you with their career, make sure to keep that trust

他們原先在這邊任職就是信任你的安排，你要確保這份信任仍存在

Last note: In some countries firing someone is a matter of days in some months

最後，在不同國家，開除所需的時程有長有短

In either case manage that process pro-actively and with respect to the people who trusted you

但不管時程長短，你都需要主動管理此事的執行，並尊重那些 (即將離開但) 信任你的同仁

Those people trusted your team with their career

這些同仁選擇用職涯的一部分時間花在你的團隊上面

Most likely the reason they are leaving not their fault but the changes in context

他們要離開，更有可能是因為大環境改變、策略改變，而非他們的錯。

Help them landing a new role that fits them

所以，盡你所能地幫助他們找到新的舞台

具體 > 不具體

Clear decisions after meetings

在會議之後你要提供明確的決策

No clear decision? Make that explicit too.

如果沒有明確的決策？那至少讓方向、條件寫得具體

Clear owners

同樣，後續項目也要有明確的負責人

No clear owner? Make that explicit too.

如果沒有明確的負責人？那至少讓負責的條件寫得具體

Hear everyone’s opinions

聽取所有人的意見

Make explicit who makes the decision

然後確保讓所有人明白這是「由誰」做的決策

And what the decision is

以及該決策具體是什麼

etc

等等

尋找「運作的最佳方案」時，具體提出會「自然浮現的好事」 (Best practices: Start by making true what’s real)

When looking for best practices or changes in the team/processes, always look at first what already naturally emerged

當你在尋找團隊或流程調整時的「最佳方案」時，永遠要先觀察哪些事情會自然浮現。

If you hire good people, they usually start looking for solutions naturally

例如，你雇用了好人才，碰到問題時他們自己就會開始尋找解決方案，彷彿本能一樣

Is this good? If yes, make it explicit

這樣聽起來不錯吧？如果你也同意，那就具體提出「團隊要自發尋找解決方案」這件事。

“Make true what is real”

好的風氣自然會產生好的執行方向，你需要的就是具體提出這些執行方向：“Make True what is real”

If not, discuss changing it

如果產生的方向不理想，就召集大家討論，並試圖改善。

Expect to refactor your company every few months

你應該要預期你的公司，每隔幾個月就要重新檢視並改善內部的執行結構與流程，就像程式碼越寫越多，就要定期重構 (refactor) 一樣。

Fast-growing startups have to refactor how they operate internally every 3-6 months

對高速成長的新創公司而言，需要每隔 3 到 6 個月重新檢視內部運作狀況 (亦即，重構)

So just go with the minimum changes you currently need

所以情況許可的話，就盡量依照可接受的最小幅度做出調整

There will never be a final endstate

改善永遠沒有盡頭

You will always be unhappy with processes in your company

你會永遠對內部流程有不滿意的地方

You will have growing pains until you stagnate

在成長停滯之前，永遠都會有持續調整的痛苦

Use the same principles you’d use in refactoring code

可以以程式碼的撰寫與維護的原則，來調整公司內部的流程

Consider to

考慮

Test in small isolation first

先測試一些相較獨立的小區塊

Peer review

配合同仁互相檢視與確認

Not to change everything at once

不要一次大改所有的東西

Avoid over-engineering

也要避免過度設計 —- 要殺雞卻在設計牛刀一樣

etc

等等

倦怠 (Burnout)

It’s a common misconception that burnouts come from hard work.

對於倦怠，大家常常誤以為其來自於過度工作

Burnout comes from a felt loss of control and/or impact.

但通常它都肇因於缺乏「對周遭的控制力」或「影響力」

Remember that you can burn out employees (or yourself) with little to no work.

請記住，只要用少少的力氣 —- 例如降低職責的影響力 —- 就可以讓同仁 (或是你自己) 感到倦怠。

How can you give people control over their impact?

另一方面，你如何賦予同仁影響力？

How can you define boundaries around chaos around them?

你要如何定義這些影響力帶來的混亂、如何控制影響範圍？

對元兇而言，由其產生的混亂所造成的影響，他會覺得比其他 (被影響的) 人還少 (Chaos is felt less by the people creating it)

A common frustration of founders is that their team can’t keep up with pivots.

對於公司創辦人 (老闆) 來說，一個常見的挫折是「團隊無法跟上公司的 pivot* (營運策略軸轉)」

As a founder, you most likely got more context on changes, you know earlier of them, and most importantly,

you have control over them.

身為創辦人，你對於市場趨勢、公司狀態與發展脈絡有更多的資訊，所以你會比其他團隊還更早知道目前的情況；更重要的是，你對於員工與公司有更多的控制權。

Employees don’t.

但員工並不具有以上這些。

*譯注：pivot (軸轉)，根據精實創業的定義，指的是「組織內部針對核心產品企劃上的路線更改，在產品、方向策略與成長引擎上建構全新的假設，使之繼續走在具潛力的發展道路上」；截自 Inside 網路趨勢觀察。

原文：structured course correction designed to test a new fundamental hypothesis about the product, strategy, and engine of growth.

對團隊主管你可以預期他們做到更多，Expect more from managers that report from you

By default, mistakes are not their team’s fault but theirs

一般情況下，出錯時不是團隊的錯誤，而是團隊主管的錯。

Share your honest opinions on things with them privately

對於事情，可以私下對團隊主管分享你真實的想法

By default, always give them the trust needed to make decisions

同樣，一般情況下，永遠都要給予主管足夠的信任，讓他們可以執行決策

They are accountable for the outcomes

畢竟他們需要對結果負起責任

Responsible for all failures

不過，是對所有的失敗要負責

But not responsible for the success

但對好的成果則不是他們的功勞

Success is the team’s achievement

好的成果是團隊的成就

They should also, whenever possible, give spotlights to their team instead of taking it for themselves

團隊主管也應該在情況允許時，把鎂光燈集中在團隊上，而非他們自己

The deal is simple: They get more authority; the team gets more ways to shine

這個交換很單純：主管得到更多的權限與影響力、而團隊得到更多發光發熱的機會。

What a cheerful ending 😬

真是個正向的結尾

Anyway… I hope this article is useful to some 🙏

總之，我希望這篇文章可以幫上大家。

There are many more things that I obviously miss – so feel free to send me questions via twitter or if you have ideas on improving this article, please send me pull-requests!

還有很多事情是我明顯漏掉的，所以如果有問題或對這篇文章有改善的地方想提出，可以用 twitter 聯繫我。對我提出一個 pull request！

Btw if you like the article, I’d appreciate if you’d share it

另外，如果你喜歡這篇文章，可以盡量分享，我會很感激。

PS: My team is hiring

P.S. 我的團隊在招人。