Oracle 裁员，与其哀怨，不若放下

放上五六年写的两篇旧文。应景 Oracle 最近大 (can) 刀 (wu) 阔 (ren) 斧 (dao) 的裁员，我也有读者不幸中招。《原则》的作者 Ray Dalio 说：

Sometimes terrible things happen to all of us in life. They can ruin us, or they can profoundly improve us depending on how we handle them.

我很喜欢的公众号作者李一诺说：

你要相信，无论发生什么，一切都会过去的啊。

所以，看开一些，福祸相倚，坏运气降临的时候，正是抛开过去的包袱，迎接新的挑战的契机。

该让谁升职？该裁掉谁

昨天中午和一位老朋友一起吃饭，期间聊起一个话题：一个team里两个同事，相同的职位，不同的工作内容，都好几年没有升职了，但两人的绩效一直都不错，客观上都存在升职的压力。两人的优缺点一对比，半斤八两，现在到了财年末升职加薪季，只有一个升职名额，究竟该升谁？

这是个让人纠结的问题。如果我是manager，我首先会问问自己是否已经尽了最大的努力去争取更多的升职名额？没有的话，赶紧争取去。

如果再无争取的余地，那么抉择起来就会很痛苦，提升谁都会让我对另一位感到愧疚。这时只好将这个问题换个问法，看看答案是什么：如果两个人同时向你提出辞职，你只能全力挽留一个，该留谁？

如果我是manager，我要留的那个人就是我该提升的人。因为很纠结的时候，就说明提拔谁都有充分的理由，那么，就找一个一旦离开，对团队伤害最小的人。使用这种方式去选择也可以将manager自身的情感因素降至最低。

跟纠结该让谁升职这样『愉悦的忧伤』相比，裁人估计是每个manager唯恐避之不及的事情。我经手过几次裁人，那感觉虐心。

第一次是我即将当manager的时候，就赶上全公司layoff，每个团队都要裁人，尽管最终决定是我的前任所做，但我基本上全程参与。被裁的员工四十多岁，那年是他孩子的高考年（印象中）。当时谈话的过程简直就是煎熬，相信我，你绝对不愿意经历。（后来看了 "up in the air"，才知道有专门帮人裁人的职位，可见裁人是多么让人痛苦的一件事）

第二次是我创业的公司经历了疯狂扩张之后的战略收缩，我裁掉了包括实习生在内的好几个同事。创业的征程中大家情同手足，裁人就像壮士断腕，悲壮而哀伤。我记得跟一个设计师聊的时候，刚一开口，她的眼泪就哗啦啦地流，两道不断加深的泪痕就像割着我心头的两把刀，左一刀，右一刀。我们聊了好久好久，那天晚上，我梦醒时，枕巾都是湿的。

第三次是我的公司发展受阻，战略转型，不得不裁掉一半的团队以维持生计 —— 这次裁人的对象是我花费无数心血一手培育和打造的开发团队。我用梦想和未来将他们招入，却亲手当着每个人的面将这梦想撕碎。若非亲历，你无法想象那种憋在心里让人无法呼吸的苦。那整整一天我都在跟不同的人喝咖啡。跟每个人谈话的时候我都想如果对方把滚烫的咖啡直接泼我脸上，我可能要好受得多。

就我的经验和经历，裁人分几种情况：

• 分摊式裁人：一般公司从财务角度和保持活力的角度会进行分摊式裁人，就像有机体的新陈代谢。每个team头上都被摊派一到多人。分摊式裁人是大公司的惯用手法，很多公司每年都有3-5%的裁人计划。
• 运动式裁人：一般发生在高层更迭的时候。在大公司呆久了，你会发现上头的那些人和官场上的人很像，拉帮结派，树立山头，新官上任三把火等等。外企的人都熟悉reorg，说好听点叫优化组织结构，说难听点是党同伐异，使用的手段跟咱们的反右，文革差不太多（当然温柔得多）。运动式裁人一般倒霉的是老板们，普通员工反而压力不大。当然，有时候阎王打架，小鬼也免不了遭殃。
• 系统性裁人：大公司部门林立，总有做得好的，做得不好的。做得不好的部门就像待观察的肿瘤，一旦进一步恶化，就必须动手术部分或整体切除，这就是系统性裁人；另一种系统性裁人的情况是公司战略转型，那些不在战略规划内的部门就像包袱一样，无情地被甩出去。

我经手的裁人，第一次是分摊式裁人；后两次是系统性裁人。

分摊式裁人执行起来真的很痛苦，需要把自己的感情放在一边，揣着良心选人。当刀架在我脖子上，不得不裁时，我一般会选择团队里年龄偏大，相对高薪低能，没有成长空间的员工。这对被裁的人很不公平，但是是没有办法的办法，毕竟manager要为公司和团队负责。

我的level够不上运动式裁人，最多在运动中作为执行者做个分摊式裁人。所以没什么经验。

系统性裁人执行起来讲究快刀斩乱麻，工作重心要放在重构留下来的人的信心和帮助被裁的人找到新工作。由于被裁的人并非能力不行，所以manager在安抚完留下来的人之后，应该尽可能发动自己的关系网，帮助被裁的人找到新的工作。这么做并非必须，但相信我，不管结果如何，只要你努力了，你会收获一份份信任和感激。

那么，对于员工来说，如何应对升职与加薪的迷局？点下面的链接延伸阅读（我在medium上写的，英文，慎入）：Programmer’s dilemma

Programmer’s dilemma

Recently I interviewed tens of candidates for a kernel programmer’s position. These candidates are from big, good companies, which are famous for chips or embedded OS/systems. Many of them claimed they have at least 10 years on-job experience on kernel. Their resumes look fairly shiny — all kinds of related projects, buzz words and awards…

But most of them cannot answer a really basic question: When we call the standard malloc function, what happens in kernel?

Don’t be astonished. When I ask one of the candidate to write a simple LRU cache framework based on glib hash functions, he firstly claimed he had never used glib — that’s what I expected — I showed the glib hash api page and explained the APIs to him in detail, then after almost an hour he wrote only a few lines of messy code.

I don’t know if the situation is similar in other countries, but in China, or more specifically, in Beijing, this is reality. “Senior” programmers who worked for big, famous foreign companies for years cannot justify themselves in simple, fundamental problems.

Why did this happen?

The more I think about it, the more I believe it is caused not only by themselves but also by the companies they worked for. These companies usually provide stable stack of code, which has no significant changes for years. The technologies around the code wraps up people’s skills, so that they just need to follow the existing path, rather than to be creative. If you happened to work for such kind of code for a long period and did not reach to the outer world a lot, one day you will find yourself to be in a pathetic position — they called you “EXPERT” inside the team or company, yet you cannot find an equally good job in the market unfortunately.

This is so called “Expert Trap”. From day to day, we programmers dreamed of being an expert inside the team/company; however, when that day really comes we trapped ourselves. The more we dig into existing code, the deeper we trapped into it. We gradually lose our ability to write complete projects from scratch, because the existing code is so stable (so big/so profitable). What’s the worse, if our major work is just to maintain the existing code with little feature development, after a while, no matter how much code we’ve read and studies, we will find we cannot write code — even if the problem is as simple as a graduate school assignment. This is the programmer’s dilemma:we make our living by coding, but the big companies who fed us tend to destroy our ability to make a living.

How to get away from this dilemma?

For personal —

First of all, Do your own personal projects. You need to “sharpen your saw” continuously. If the job itself cannot help you do so, pick up the problems you want to concur and conquer it in your personal time. By doing so, most likely you will learn new things. If you publish your personal projects, say in github, you may get chances to know people who may pull you away from your existing position.

Do not stay in a same team for more than two years. Force yourself to move around, even if in the same organization, same company, you will face new challenges and new technologies. Try to do job interviews every 18 months. You don’t need to change your job, but you can see what does the market require and how you fit into it.

For team/company —

Give pressures and challenges to the employees. Rotate the jobs, let the “experts” have chance to broaden their skills. Start new projects, feed the warriors with battles.

Hold hackathon periodically. This will help to build a culture that embrace innovation and creation. People will be motivated by their peers — “gee, that bustard can write such a beautiful framework for 24 hours, I gotta work hard”