Part 1 is here: blog.sina.com.cn/s/blog_70c9335b010125l7.html OR nonoidea.posterous.com/10-lessons-i-learned-at-facebook-part-1-of-3

中文版回来的. 再等等 :)

4

Listen to the data but don't just rely on it

To decide a product direction, you need imagination, passion, and strong nerve. But not data. However, you will need to rely on the data to keep your team on the course. And the data can help tweak the product from what it is at first to what it needs to be at last. Here is a story. We didn't have strong confidence that we would be successful by going all-in on machine learning. But we knew we had to do it because it's the right way, if not the only way. We wanted something that is smarter and more scalable than rules engine. It's like in the movie Lord of Ring in which Frodo knows the road to Mordor is dark and dangerous, but that's the way he has to take. Not a perfect analogy, but that's kinda like how we were thinking when betting on the machine learning approach for payment fraud detection and action. The same imagination was taken on the customer service tools for user-reporting(external tool) and ops-reviewing(internal tool) fraud suspects. The key words here were "automation" and "feedback". We wanted most of things to be automated, and only had to eye-examine cases when really had to. And review tools were built to focus on the feedback from the operational support (also known as customer support) team so we could train the machine to be more accurate and smarter. 

But you need to listen to the data. Without data, it's only your hunch that's working, and you can be wrong, very wrong. Data can help validate your hypothesises, filter out the wrong guesses, and find the best alternative from the many. At a time, we thought the linkage tools (people sharing cookies, credit cards) should yield great results. It turned out that it's only true to certain degree depending on the fraud characteristics. In certain period, the stolen/sold credit card cases were dominant. That's when linkage analysis would be helpful, not when hacked accounts were more common. The hunch didn't fit the then reality. It was lucky that we realized this early and didn't spend more resource on this direction when it wasn't a major problem for us. In this case, we listened to the data and dropped a project.

Just want to mention A/B test a bit. A/B test doesn't tell you which product to build; it tells you which variation of a defined product might be more successful.

5

Avoid the time suckers 

When I started as an engineer at Facebook, I really enjoyed the days and nights mostly immersed in coding. However, when I grew more senior and took more lead on projects, I couldn't just spend time on coding. It's sometimes more important to decide what the product should look like.  PMs were involved in most of these decisions, but engineers had strong influence and many times final say. Engineers were actually EXPECTED to define what they should do (a popular way of saying this - write your own job description). So I spent a lot of time on other things, which are also important questions every engineer might want to ask themselves. Such as, figuring out what additional features should/could be added, and sometimes more importantly, what features to drop; what tests we should run or stop; whether we are focusing on the most important issues - be it better user interface, less failure rate, a faster response time, etc. It all took energy and non-coding time. And I found time well spent on these issues.

What's time not well spent? 

There are many time suckers. I will only pick the top two in my mind. 

Emails. Not every email stands equal. I learned to use filters to distinguish the important ones from the others. 

Two tips I'd like to share here. 

1) I have a tested filtering system (I cannot say it's absolutely good, but it works for me); I reply to important and urgent emails right away, and flag these (especially from my team, PM, partners, and managers) that I can wait until the end of the day to process. I make sure I read, and respond if necessary, all the flagged emails before I go to bed. For a lot of FYI-only emails, the filters put them rest in peace in the right place and I take a peek at them once in a while - like the social emails asking what's the best winery to visit in Napa. They are usually great threads, but I don't have to jump onboard. 

2) I have a personal email policy which I inform all the people I work with closely. This is how it reads "p.s: experimenting a personal email policy, and only checking emails every 3 hours; pls call/sms/aim me for urgent issues." Actually, it's more for others to set their expectations on getting my response than for me to be disciplined. I actually checked emails more frequently than once every 3 hours. But I felt much less impulsive to check or reply emails because I knew they would have called me if it were for an urgent matter.

Meetings. Meetings are popular time suckers, just like emails. You don't and shouldn't attend every meeting. And it's perfectly fine to skip meetings if the perceived value (to you or others) is trivial. If you want to be more polite to the host, send him/her an email and ask whether you can be MIA. Usually the answer is yes if you have already thought about sending such an email. Many times I ask my PM to attend in lieu of me. Of course, I ask him first whether he thinks he should attend, and encourage him to skip if the answer is no. I really try a lot to ask my team to create and attend meetings carefully, and I ask them once in a while whether they think of their time spent on meetings. We combine meetings that could be consolidated. Here is one example. In the early days, we saw a lot of (kinda) random requests from the support team. It's not very efficient to spend time on discussing these ideas in a scattered way. So we figured a way to set up weekly office hours to take (non-urgent) questions in a more concentrated manner. 

One thing that usually gets neglected is to consciously think about what things you SHOULD NOT do and STOP DOING THEM. Such as discussions you should avoid, features you should drop, people you should not spend time with, etc. One simple question I ask myself often is whether it matters to my goals. If you know what you are doing and what you want, you will have a feeling on the answer. Go for it. 

6

Affinity is effective for reducing people tension

There is always coopetition between the engineering team and the support team. There is always a wish that engineers can solve all problems. But the truth is that not every problem can or should be solved in a technical fashion. There are insights from the customer support and operational folks that even the best engineers cannot obtain, because engineers are simply not in the field reviewing fraud cases. It's true that a lot of data was logged but the insight couldn't always be easily derived from raw data. Since we hired really good people (many from top schools) in the user support team, they had deeper views than one would expect from mundane user support organizations elsewhere. The tension would build in fighting for the direction of solutions, when the two groups of smart people diverge in their opinions.

There is also coopetition between related engineering teams. The brotherhood exists in deeply connected teams, like the anti-spam, security and the anti-fraud team (my team), etc. These teams try to learn from each other and share experience and technology as much as possible. But sometimes we made independent efforts on slightly different but similar problems, and we tried to sell each other our solutions and ways of thinking.

I found the key to keep the coopetition in a healthy state was to increase affinity among the people, which inspired mutual trust. I spent a great deal of my time building relationships with related teams. I had bi-weekly or monthly 1-1s with these team leaders. The frequency depends on how close we were on the problems in concern. Either I or someone from my team would regularly attend selected teams'  meetings. I have arranged teams across different functions (engineering, ops, data, IT) to sit together when they were sprinting on shared projects - this worked really well in bringing people together. I had frequent lunches with a selected set of people to chat about work, life or anything. I also did 1-1s in long walks to get people more opened up. The relationship comes really handy when you want the people from different teams to hold tight at the most challenging moment in a crazy project. 

In #1-#3, I shares my thoughts on the following points:

#1 Set high expectation and measure it

#2 Hold on to your vision, but be flexible on the details

#3 ONLY work with the best people

In #7-#10, I shares my thoughts on the following points:

#7 Delegate and validate

#8 Feedback is a continuous process, not a once or twice a year event

#9 You can do more than what you think you can

#10 Don't over-design or prematurely optimize