前言

那一天，人类终於回想起了，曾经一度被他们所支配的恐怖，还有背囚禁於鸟笼中的那份屈辱那一天。
— 《进击的巨人》，谏山创

好其实跟进击的巨人完全没有关系（殴飞）。

这篇基本上完全是给leader看的，如果你是那种觉得效率与工程文化至上，觉得去了解每个团队成员或跟他们闲聊是浪费时间的人，那建议你可以看看这篇文章。因为或许你与过去的讲者一样，都在建立一种culture of fear的文化。

演讲摘要

讲者利用自己的经验来讲解leadership。当她成为leader时建立的文化是culture of fear，直到後来慢慢学习改进才变成culture of trust，以下就是她自己的一些个人经验。

1. 速度
   身为leader你要让自己变成没耐心的人，这里主要讲的是那些会拖慢团队效率的事情。因为工程师们很享受做出自己看得到或感受得到的东西，如果有流程会拖慢他们速度，他们就会觉得很不爽。例如发布新的feature，如果部属流程太过繁琐或太过手动，你就要想办法帮助他自动化让他们不要一直浪费时间在这些琐碎的事情上。

2. 架构（Structure）
   好的架构是你要让大家可以快速获取需要的讯息。相信大家都可以理解好的code structure可以让你快速读懂程序逻辑，而不好的则会让你花了很多时间研究还是看不懂在写什麽毛。不过这里讲到，架构的产生通常是根据一系列的失败与修正之後获得的结果，所以在此资讯透明变得很重要，不然大家无法得知自己这个流程的核心价值是什麽，就变成盲从而已。

   她这里提到了个有趣的点，当初她在Four Square公司里建立career ladder的标准时，尝试去写的比较模糊，为了让大家不要那麽有压力，不要为了做某些事情而作。但最後却导致大家更有压力，因为大家不知道要怎麽做比较好。所以讲者重新修正了这套标准，给了比较实在的范例（如果有兴趣的人可以看看这里。）

   所以为了产生好的架构，必须要不断从失败学习，去review与改进你的流程。而建立架构与流程的重点在what而不是how。因为人非常不擅长follow太过detail的步骤，你写太detail反而会让大家不知所措。相对的机器其实很擅长follow明确的步骤，所以如果真的可以写出细部的how，那想必也能够自动化。

3. 连结性（Relatedness）
   你在是IC role的时候可能不觉得这件事很重要，也不喜欢跟人家合作。但如果你身为一个leader，只在乎技术这种效率至上的想法是不行的，因为大家都是人，建立信任关系能够提昇团队的成长与效率。而要达成这件事，你就必须让每个人觉得他们是像「人」一样被对待，也不需要对於犯的错误感到羞愧，也不需要担心问错问题，这样一来团队才能发挥最大价值。

   另外关於建立安全的环境，一个很简单的方法是，勇於承认自己的错误。让大家理解犯错是可以的，每个人都会犯错，所以没有必要对於自己的错误感到羞愧。

4. 一对一（one-on-one）
   1-1重点不只是询问进度，讨论工作上的事情，更是你拉近与团队成员关系重要的一环。即使你真的很不想做，你可以就练习「假装」你在意这些东西，通常开始假装後，你就真的会开始在意这些事情了。

5. 冲突
   无论你是对於冲突的态度是喜欢或是不喜欢，都必须练习拥抱冲突。因为冲突是激发不同思维重要的一环。当然你也不能让冲突太过凶猛（aggressive），不然大家会不敢有任何冲突，那就会造成反效果。而实际上要做这件事，最简单的是把冲突换成好奇，与其直接拒绝别人的意见，不如多问一些细节，进而了解别人是怎麽想的，就不会让整个冲突本身看起来很火爆，而且也能达到相同的目的。

6. 会议
   开会的目的其实就是为了合作，因为我们相信多人协作会比个人作业带来更大的效益。但基於合作理由，我们必须要开会去协调与取得共识。或许很多人觉得开会很无聊，所以想尽办法让会议变得有效率，但其实更重要的是大家要好好利用会议的时间来讨论事情与了解彼此。如果开会的成员对於会议内容都没什麽意见，要码是会议根本就没有必要开，要码是大家没有好好利用会议来达成沟通的目的。身为一个leader，你必须要想办法在会议上让大家讨论问题，吸收大家的意见，了解大家的感受。并创造一个环境让大家能够畅所欲言的讨论。

最後她说到：同理心其实是个leadership的技能，是可以後天学习的。所以如果你是leader，花点时间锻链你的同理心，了解你自己的想法，也了解你团队的想法。

个人心得

作者Camille Fournier其实是着名的The Manager's Path一书的作者，书中讲述了不同阶段的leader所要做的事情的差异，算是Engineering Leadership近年来非常着名的一本书。只是我自己私心觉得作者的写作方式并不是那麽好的抓到重点，或许就跟这篇演讲一样，可能有很多点你会认同，但是看完之後可能不太会记得清楚讲了什麽。

以下就基於她讲的内容在附上一些自己的想法：

流程

其实公司大了自然会有很多繁文褥节，为了scale其实往往需要牺牲个人的效率。例如以前想要发布东西就随时发布，但现在还有复杂的发布流程，必须要有ticket附上release cycle，加各式各样的tag，跟写下发布的相依性，如果不在常规时间发布还要寄信写一堆报告。对於像我这种看着流程改变的人其实很容易适应，但是对於新人就会觉得这些事情很没必要。导致最後他们常常会东漏西漏少加tag或少写东西，必须要一直戳他们去补齐。

但也是完全可以理解为什麽大家会怎麽难接受这些流程，毕竟光是要「解释」发布流程就要花可能至少半小时看长长的文件。我都怀疑到底哪个新人看完会真的记得这些。

一方面我们希望让这些用户知道时代背景所以才能理解这些事情的重要性，但另一方面文章内容太长或者没有感触，大家也很难花时间去理解内容。而这中间的平衡要如何拿捏，我自己觉得还是个非常的困难Orz。

1-1

关於1-1我真的是有深刻的体悟，我去年带团队的时候也觉得1-1没什麽必要，反正成员不太多，我也可以掌握大家工作进度与状况，那好像有这个每一两周一次的sync-up好像没什麽必要。但在我听取某个前辈经验说1-1可以帮助大家设定目标後，我就发现1-1的好处真的是超级多。虽然到了最後「帮大家设定目标」这件事情并不是做的很好，不过我却从中获得了许多的启发与自我成长。

因为就像讲者说的，1-1还有一大部分重点是你要与你的成员建立连结，问问他们工作之外的事情，试着去了解别人的真实想法，知道他们在乎什麽不在乎什麽。而这其实会大大影响你跟他们沟通的方式。很多人事情做不好不是能力不好，只是他们的priority跟你的不同，所以你可以尝试使用对方的priority去跟他沟通，就有机会比较有效率些。

而同时1-1也是个很好的complain的地方，我都跟我的member说我很喜欢听你们抱怨事情，因为这代表你们对我的信任，也可以从抱怨中获得很多灵感来改进大家的工作方式。

拥抱冲突

其实对於冲突的态度我一直是能躲则躲，也是我的弱项之一。
还记得之前在准备面试的时候，有一类问题是关於解决冲突，我那时候就在想好像在S社一路顺遂没什麽可歌可泣的冲突。大部分都是在跟别的team吵架，但是对於我老板或team成员就真的想不太出来，不知道是真的都没有冲突还是如何。
但总得来说我就是个害怕冲突的人，通常在要开始吵架前我就会先自我放弃。有时候接受别人的意见目的不是因为真的接受，只是懒得跟别人吵架而已。即使在冲突中，也往往难以控制自己的情绪Orz，而忘了我们目的是为了找到共识，而不是要讲赢别人。
不过讲者讲了一个方式是把冲突换成好奇心，去理解别人是怎麽思考。这样或许对我来说是个蛮可以接受的思维方式，未来可以尝试看看。