（转载）10 lessons I learned at Facebook

原文： http://blog.sina.com.cn/s/blog_70c9335b010125l7.html

A quick briefing about myself - I joined Facebook in early 2007 and have been through many challenging projects. A lot of problems were new and unseen. A lot were above the scale history has ever seen. A lot of hard times but also great times. By the time I left, I was managing the risk engineering team that was in charge of payment fraud and customer service tools. Right now, I am doing some angel investment work for fun, while preparing to start up my own company. See more of my background and interest at linkedin.com/in/hwang123. There are a lot of things I learned during the last few years at Facebook. I am going to share the most interesting 10 lessons in 3 posts. 

 

Before we start, here is the disclaimer :)

1- Everything here was derived from my belief and practice from my 4.5 years at Facebook. It worked fine for me within the Facebook culture. That doesn't mean it will work for you. All seeds need the right soil.

2- I would not try to convince you this is the best practice. It's not. 

3- The reason I wanted to write this was because I wanted to share. It helped me distill my life experience. It simply reflects what I felt, and what I want to share with you, in a genuine way.

4- A lot of these may not be new or useful at all to some of you, but I hope some do. 

 

OK, let the lessons unfold. 

 

1 Hold on to your vision, but be flexible on the details

As a leader, you will have to rely on yourself on the vision (at least for the scope of the work you are charged for), and these who work with or for you will rely on you for the vision. What is a vision? It's a depiction of the end state. It is where you want the team to land. It is the new life after effort. It is the north star, the direction. Here is an example. When I started the payment risk team, we only had rules engine. Rules were human written. A rule is a simple logic with very limited variables in it, such as "if registered < 30 days AND spending > $100 AND first_time_spending is TRUE AND user is from Indonesia, then reject the transction." Humans cannot deal with more than 10 variables, effectively. We wanted to be much more scalable. We wanted to automate a lot of things machines can do better than humans. So we set a vision that we would want to replace majority of rules to be machine learned models. The vision allowed us to add a research engineer who has a PhD in machine learning and another engineer who had similar hands-on experience before joining Facebook. The bet was bold, but the future needed it.

 

But you need to be flexible on the details. There are ALWAYS multiple ways to reach a destination. You need to learn to give your team enough wiggle room, as long as the team is heading towards the right direction at the right speed. Another story. There was a time I was more fascinated with decision trees than regressions. But the engineer who was experimenting on the algorithms told me there's only negligible difference in a selected set of algorithms. I could have insisted my preference (which was my then true belief) but I trusted the person and left it to him to pick the right algorithm. There were also interesting times working with designers, who had their nitpicky taste on font/color/margin/etc. I usually let them have their ways as long as the main purpose of the feature was well served. We wanted to pick the right fight, the fight that matters for the victory of the war, not one battle. 

 

2 ONLY work with the best people

Great people only want to work with great people. They become better by being together. A-players have very low tolerance on B-players. What defines "best people?" My understanding is that someone who can quickly utilize what s/he knows and learns what s/he doesn't to get things done to an extent that exceeds expectations. It's their basic instinct to beat expectations, their own expectations. For them, good enough is never good enough.

 

There are many benefits of having only the best people in place. 1) It makes you much more willing to delegate. From my experience, great people don't trust unfamiliar people. They need to know you are as good as or even better than them, before accepting your help. Otherwise, they'd rather burn themselves to do the work. But if you have proved to them, they would trust you a lot and are much more willing to delegate. A great team with effective delegation can do way more. 2) They set examples for each other, and by doing so raise the performance bar. It's amazing peer pressure. If it's utilized properly, it creates benign cycles in the company. 3) Great people challenge each other. I remembered one director of engineering challenged us that if we could finish the code changes to enable site translations by a certain date, he would dye his hair blue. Challenges like that make "boring" work more like a game. It's fun to be part of a game. Of course there were more serious challenges, and great people just love challenges (either challenging others or getting challenged) 4) Great people learn a great deal from each other. I would not have been in Facebook for more than 4 years if there were not much to learn. For inexperienced people, this is even more true. We have hired very smart graduates who were motivated to prove their awesomeness. They didn't want to come to a company to have a comfortable and not challenged life. They wanted to learn a great deal to nourish their experience, to accomplish missions impossible and advance their career paths. They want to prove yes, they can. They want to be with great people to make all this possible. 

 

You don't want B-players but how to not have them. First, hire slow. Be very stubborn in holding your hiring bar. I have seen many times in the hiring discussion meetings where candidates with fancy resumes don't get hired because one of the interviewers thinks this guy doesn't impress him. In other cases, candidates with all hire recommendations don't get hired because everyone thinks s/he just barely meets the bar. In hiring, most of times, you want to be risk averse. (Wanna also mention that we also hired people without all-hire recommendations but there were always one or two strong advocates from interviewers - you will want to take risk on trusting your employees.) Second, fire fast. Having B-players in place is like taking small poison. A bit a day; gradually but eventually you will die from it. You need to put the B-players into the exit track as soon as you can (in certain cases, the law limits what you can do). I had seen a case of slow firing, and the negative impact to the rest of team was no kidding.

 

3 Set high expectation and measure it

As a leader, you need to set your expectation high but still realistic. High enough so your team doesn't get bored. Realistic so they don't get burned too badly. You want to create an experience for them so when they look back at the end of the journey, they could say: hell, I didn't know I could do this. This is awesome. In Facebook, like most other Silicon Valley high tech companies, expectation is also linked to compensation, so it's very important to set up the expectation clearly ahead of it. 

 

And you need to find an undisputable way to measure it. I spent a lot of time working with the team to figure out what are the top 3-5 goals for the coming quarter and what the metrics should be to measure the goals. Thus we have measurable goals. The goals are assigned to or grabbed by individual engineers or a group of engineers and their partners in other functions. In this way, we not only have a list of 3-5 top metrics we can always rely on to quickly tell how we are doing, but also know who is behind each goal. The team success is well linked to individual performance. For example, the biggest achievement of my team was to reduce the dispute rate of credit card payments by 75% in 1 year's time through multiple measurable goals in each quarter. 

 

One thing to emphasize - you still have to be realistic. Having a 10X revenue boost when you only have a 10% market share is probably not realistic. Steve Jobs is really good at pushing his teams beyond their potentials but they got burned badly (even though they were really proud of what they had achieved). 99.9% leaders are not Mr. Jobs, and they don't need to be him. You can still achieve a lot by running a sustainable team while realizing your team's true limit.

 

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. 

 

7 Delegate and validate

It's easy to understand the importance of delegation. Because simply, you cannot do everything yourself. More crucially, you may not be the best person to do it anyway... Actually, being comfortable with delegation was my strength. Maybe too comfortable to call it a strength… There was a good lesson I learned from my former manager. A project lacked progress and I gave too much free-run to the person who was assigned the task. The person was good but he wasn't experienced enough to handle the issue, which involved technical difficulties as well as communication challenges. My boss brought up a great point that I would need to validate my confidence on the person to back the delegation. There is a balance to be maintained here, just like in everything, anything. 

 

If you give an important task to another person, 

1) you should either already have the confidence that he/she can (learn quickly to) do it, or 

2) you should check with him/her now and then, especially at the beginning, to make sure they will get the shit done above a quality bar.

 

Here is what I tried to do to implement this strategy. I asked these whom I delegated important tasks to give me their plan, and the immediate next milestone, which we could check in a few days. The confidence is built up gradually until a point when much less validation is required. Be careful on the other extreme to have checks too frequently. That could be deemed as lack of confidence. It's as bad as, if not worse than, blind delegation.

 

Don't think I did well on this one, but this is a great lesson to share. 

 

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

Feedback is meant to make people better, not to give them a hard time. It's there to give them a chance to see how they view of themselves and learn how others perceive about them. Your view cannot be more than 180 degrees in front of yourself. You need a mirror to tell more, and feedback serves as such a mirror. At Facebook, the official 360 degree feedback is done twice a year, which is tied to compensation. But gradually, the system has morphed into a continuous feedback sharing process. I practiced a quarterly lightweight feedback session, in which I asked the extended working group to give my team members written feedback. I collect the feedback, syndicate, and deliver to my team in 1-1s. If people have to wait half a year to receive feedback, it's already too late. Often, the stories that back the feedback may be already forgotten. To make it worse, if feedback cycle is tied to the compensation, people naturally (and understandably) get distracted from the feedback and focus on the compensation. 

 

In addition to the quarterly lightweight feedback, day to day feedback, which is usually pretty small, should be delivered immediately once it's available. The more remote the feedback is about, the less useful it is to the receiver. 

 

How to deliver the feedback is also important. People say that it's not what you say that matters, it's how you say it. I don't take it that far. I think they are equally important. I had some conflicting experience about whether to start a feedback conversation with questions like "how did you think about the meeting you hosted yesterday" and drill from there, or a more straight line "hey, let's talk about the meeting you held yesterday" and start talking about what my perception was. I always gave them a chance to reason their behavior, but emphasized what I perceived and why so. We usually agreed on the line "what people perceive is what they believe". This usually gave them a way to be willing to change. It's easy to agree on what was done, but the discussion was usually around how it was done, and how it could be done better. After they realize it's something they want to change, how to change it is much easier - smart people always know what to do, and I usually just help stimulate the brain-storming practice. Eventually we took away from the discussions about how it could be done better next time.

 

Four things I'd like to emphasize on delivering feedback, 

1) Feedback doesn't have to be negative. It could be a strength of the person you appreciate and love to see more of that. Something like "hey, I really love your weekly summary email with the key metrics at the top. Please keep them coming" will go a long way.

2) Feedback has to be backed by examples and rationale. It doesn't help to tell a person that he/she sucks, without an example and why. I always ask everyone when writing feedback to provide examples. A line like "I think he could make meetings transparent and shorter by having an agenda, like the weekly data review meeting on last Friday" is much better than "his meeting is too long". 

3) Feedback has to be actionable. In order for the feedback to be helpful, the feedback session should always end up with actionable items. Otherwise, it's just talking, no acting. The same example, "I think he could make meetings transparent and shorter by having an agenda sent ahead of time..." would be quite instructive and thus helpful.

4) (This is just my preference.) In my last 2 cycles I wrote feedback for my 15-ish coworkers, I shared most feedback directly with the people. It made my writing less emotional. Because I knew they would read it, I needed to make the feedback helpful, understandable, and backed with data. And they knew I wanted to be helpful by sharing the feedback and welcoming them to discuss it directly with me. 

 

9 You can do more than what you think you can

This is not a casual statement, I had a real story about it. We thought that bringing down a pretty nasty fraud rate to be below an allowed limit was really challenging. Now try to have a goal of making the fraud rate less than half of that limit. It was what we did, and it felt really good to us. 

 

Great people surprise themselves all the time. Just give them a really aggressive goal, with the right tools, appropriate help, adequate confidence, and reasonable time allowance. They will blow you off, and blow themselves off. #9 is repeated again and again by master Jobs :).

 

There is one necessary condition to make #9 practical - don't fear mistakes. Great people can only surpass themselves when they are not afraid of failures. One great quote I often share is "ask for forgiveness, not for permission." At Facebook, forgiveness for being bold was easily given. 

 

Caveat, echoing #7 - I don't mean you could just give anyone an aggressive goal and simply expect he/she can knock it off. You will need really great people to be able to do this, and it's your job (as a leader) to push them above their potential, while being helpful and encouraging. Facebook was abundant with great people.

 

10 Don't over-design or prematurely optimize

Some engineers cannot refrain from making their programs scale, well before the programs reach their prime time. I was one in my early days at Facebook. After going through several flops, I learned this lesson a hard way. No over-design or premature optimization. Do that only after you know the feature you are building is tested and going to hit the main street. One feature I built topped 2 million monthly active users (when there were about 40 million Facebook users), while I already built it in a way it could handle much more. It just made me feel good while building it, but really bad later on. 

 

This may not necessarily apply to infrastructure work. As the Friendster meltdown has shown, your infrastructure development has to predate your growth tipping point, otherwise be prepared for the tragedy. But still, I have seen infrastructure requirement evolving so fast and incremental changes might serve better, rather than over-designing a lot of things that are not needed. Remember, the data pattern you see when you have 100K users might be very different from when you have 100M. Or you might have a very different product by then. So make your own judgement. 

转载于:https://www.cnblogs.com/emotion164/archive/2012/03/02/2376896.html