鲍里斯·切尔尼（Claude Code 的创始人）谈他的职业成长之路

可能那只是开玩笑的。

Maybe it was tongue in cheek.

我也不确定。

I'm not sure.

你说过，这是我学到的，在VP评审时总是提供三个选项，因为80%的情况下，他们只会选中间那个。

You said, This was when I learned to always present three options in VP reviews, since 80% of the time, they'll just pick the middle option.

然后括号里写着，你的VP选了中间那个选项。

And then it says, your VP picked the middle option in parentheses.

这背后的想法是什么？

What's the thinking behind that?

这非常

This is very

开玩笑的，但当时在Meta这可能确实有点道理。

much tongue in cheek, but maybe this was actually kind of true at Meta at the time.

我觉得那些离工作很远的决策者，他们想知道你做了功课，找到了合适的选项和权衡，并且你真的做了工作，但他们也想在决策中贡献点什么。

I think decision makers that are far away from the work want to know that you did the due diligence of finding the right options and the right trade offs and that you did the work, but they also want to contribute somehow to the decision.

所以中间那个选项就是比较容易做到这一点的方式。

So the middle option is kind of the easy way to do that.

这有点开玩笑，因为我觉得不是所有领导都这样。

It's a little tongue in cheek because I think not all leaders are like this.

很多领导会自己去做功课。

A lot of leaders will do the work themselves.

他们对团队的信任程度各不相同。

They trust their teams more or less.

运营方式有很多种。

There's so many different ways to operate.

但那时候，我记得我们有一个不太懂技术的领导，这样做是为了帮她做决定。

But at the time, I remember we had a pretty nontechnical leader and this was the way to help her make decisions.

我觉得在你职业生涯的这个阶段，你离高层管理最近。

I think at this point in your career, you had the most proximity you've had to senior management.

你说过你曾经向一位高级总监汇报，并且参与了很多大规模的范围讨论。

You said you were reporting to a senior director at some point and you were involved in a lot of huge scoping conversations.

我很好奇，向这么高层级的人汇报，会带来哪些后续影响呢？

I'm curious what's the downstream effects of reporting to someone so senior like that?

对，我觉得这要看工程师个人，也要看公司情况。

Yeah, I think it kind of depends on the engineer and it depends on the company.

比如，我现在在Anthropic，我觉得在Anthropic这无所谓。

For example, now I'm at Anthropic, and I think at Anthropic it doesn't matter.

你向哪个层级汇报都不重要。

It doesn't matter which level you report to.

公司里一些最资深的人，汇报对象就是一线经理。

Some of the most senior people at the company report to line managers.

很多一线经理以前都是CTO之类的。

A lot of the line managers are ex CTOs and things like this.

所以其实真的无所谓。

So it actually doesn't matter.

所以我觉得这是一个非常具体的、关于公司文化的观察。

So I think this is a very meta specific cultural observation.

我觉得这里有两件事在同时发生。

I think there's sort of like two things going on.

第一，在Meta，作为工程师，你总是需要找到自己的职责范围。

So one is, at Meta, as an engineer, you always needed to find scope.

有些你可以自己找，有些你的经理、技术负责人，或者你身边一起工作的人会帮你找。

Some of this you can find yourself, and then some of it your manager helps you find, or your tech leader, or the people you surround yourself with.

而且，你知道，Meta的绩效评估过程是出了名的折磨人。

And, you know, like, the POC process is, like, grueling, like, famously grueling at Meta.

所以你必须不断地谈论你的影响力，而职责范围是其中最大的因素。

And so you just have to constantly talk about your impact, like, scope is, like, the biggest contributor to that.

如果你有足够的职责范围并且执行得好，那就是影响力。

Like, if you have enough scope and you execute it well, that's impact.

这就是公式。

That's the formula.

我觉得另一部分是，在Meta，没有人有头衔。

I think the other part was at Meta, no one had titles.

所以即使是最资深的工程师，他们的头衔也只是软件工程师，这一点我其实非常喜欢。

So even the most senior engineers, their title was software engineer, which I actually really love.

你知道，贝尔实验室就是这样，比如技术人员，Anthropic 也是这样。

Know, like, Bell Labs had this with, like, a member of technical staff, and this is true at Anthropic, too.

实际上，这里更进一步。

Actually go even further.

在这里，每个人的头衔都是技术人员。

Here, everyone's title is member of technical staff.

不管你是工程师、产品经理还是设计师，都没关系。

It doesn't even matter if you're an engineer or a PM or a designer.

头衔都一样。

It's all the same title.

我真的很喜欢这一点，因为回到之前说的，做自己职责之外的事，做那些应该做的事，不管别人期望你做什么，只要是好事就去做，我觉得这种文化正好促成了这一点。

And I actually really love it because back to this point of working outside your lane and doing stuff that just should be done and, you know, like are just good things to do regardless of what you are personally expected to do, I think this kind of culture just sets that up.

我明白，无头衔制度确实有很多好处。

I mean, see a lot of the benefits of the no titles.

不过我也能想到一种情况，也许只有大公司才会这样，就是你联系公司里的某个人，说，嘿，我想跟你合作做这个项目。

I could also see a case though where, and maybe this is only true for big companies, where you reach out to someone across the company and you say, Hey, I'd like to, do this collaboration.

如果你的头衔是总监之类的，那对方就能很快明白该多重视你，或者该怎么跟你打交道，如果你是设计师或其他角色的话。

And if your title said director or whatever, it's a shortcut for them to understand how seriously to take you or how to interact with you if you're a designer or some other role.

现在Anthropic规模也大了不少。

Now Anthropic has got a bit bigger at this point.

你有没有遇到这种情况？

Do you see any of that?

大家可能都认识你，所以你可能不太会碰到。

People probably all know you, so maybe you don't see it as much.

对，我觉得这确实是缺点。

Yeah, I think this is definitely the downside.

但我觉得好处更多，就是你必须去赢得信任。

I think the upside outweighs it, which is you have to earn trust.

我觉得这是真的。

And I think this is true.

不管你在哪家公司，都得靠自己赢得信任。

Regardless of what company you're at, you've got to earn it.

而且，就算你以前做过很厉害的事，也不代表你就应该得到尊重。

And just because you did a cool thing before, it doesn't mean that you should deserve respect.

当然，每个人都值得被尊重。

Well, everyone deserves respect.

但这不代表你在新公司、新环境里就应该拥有权威。

It doesn't mean that you should deserve authority at a new company in a new setting.

所以我觉得，即使是有经理头衔的人，也得靠自己赢得这些。

So I think even for people coming in with manager titles, you kind of have to earn it.

而且某种程度上，有经理头衔反而更难赢得这种信任。

And in some ways, having a manager title makes it a little bit harder to earn this kind of trust.

所以作为个人贡献者，无论如何都得这么做。

So as an IC, you got to do it either way.

我觉得没有头衔反而让这件事变得更容易一些。

I think just the lack of titles makes it a little easier.

在你职业生涯的这个阶段，你越来越像技术负责人或者Uber的技术负责人了。

At this point in your career, were becoming more and more of a tech lead or Uber tech lead.

我记得你有几个故事，是为数百名工程师规划工作范围。

I think you had a few stories where you scoped out work for hundreds of engineers.

我就在想，如果工作量这么大，而你只有一个人，你怎么做得到呢？

And I was just thinking about how do you do that if there's so much to scope and you're one person?

你是如何为领导层处理如此大规模的范围规划请求的？

How do you go about doing such massive scoping requests for leadership?

是的，那段时间简直疯狂。

Yeah, this was a totally insane time.

我和Tina Schuchman合作了很多。

I worked a lot with Tina Schuchman.

她现在在微软，但当时她是我的经理，之后Yifei接任了我的经理。

She's now at Microsoft, but she was she was my manager at the time, and then Yifei, who's who's my manager after.

那时候，Facebook群组获得了更多的投资。

And there was a lot more investment going into Facebook groups at the time.

所以我觉得我加入的时候，这个组织大概有一百五到两百人。

So I think the org was maybe a 150 or 200 people when I joined.

等我离开去Instagram的时候，我觉得大概有六百到八百人，差不多那样。

And by the time I left to Instagram, I think it was like 600 or 800 people, something like that.

所以扎克伯格有一种感觉，Facebook应用应该完全围绕社区，他就是希望我们越来越快地实现这个目标。

So there's this feeling from Zach that Facebook app should be all about communities, and he just wanted us to go like faster and faster to make that a reality.

作为高管，你最大的办法就是把合适的人放在决策位置上，然后给他们资源。

And as an executive, your biggest way to do that is to put the right people in charge of decisions and then to give them resources.

在Meta的情况下，就是工程师。

And so in the case of Meta, just engineers.

这个不需要GPU。

You don't need GPUs for this.

你需要工程师来做事情。

You need engineers to do stuff.

所以我们向扎克伯格提出了这个项目，叫做“社区作为新组织”。

And so we pitched this project to to Zach, and it was called Communities as the New Organizations.

那是内部的名字。

That was, like, the internal name.

然后他就给了很多人手来做这个。

And he just, like, a a bunch of headcount to go towards this.

所以我们只需要弄清楚这些人要做什么。

And so we just had to figure out what these people will do.

对他来说，我理解。

And for him, I get it.

就是说，如果事情重要，你就得派很多人去做。

It's like if the thing is important, you gotta put a bunch of people on it.

现在回想起来，我会做得不一样，我会派更少的人，因为重要的是解决用户的问题，打造出色的产品。

In hindsight, what I would have done differently is I would have put way less people on it because what matters is solving people's problems and building awesome product.

而且这实际上需要自下而上，你得随着新产品线找到市场契合点，慢慢加大投入。

And this actually has to kind of be bottoms up, you kind of want to slowly dial this up as you find product market fit for new product lines.

你不能一下子全上。

You can't just do it all at once.

对，我们当时就得把这些事情都规划好。

And yeah, we just had to scope out all this stuff.

有段时间，我每周都得写一份范围文档，比如，好，我们要安排30个工程师做这个。

There were weeks where I had to do a scoping doc for, Okay, we're going to put 30 engineers on this.

这里有三个技术方案。

Here's three technical options.

我们选这个。

We're going to pick this one.

下一个项目，我们安排20个工程师做这个。

Next project, we're going to put 20 engineers on this.

这里有三个方案。

Here's three options.

我们选这个。

We're going to pick this one.

下一个项目，我们要做的是。

Next project, we're going to do.

就这样一遍又一遍地做，只是为了对这件事不是完全离谱有点信心。

And just doing this over and over again, just to have some sort of confidence that this thing isn't totally crazy.

我们做了一些基础的技术规划，大致按项目规模匹配了工程师人数。

We did some baseline technical scoping, roughly matching the number of engineers to the project.

其实这里面有些挺有意思的东西。

And there's actually some pretty fun stuff.

我记得有一阵子我们想在数据模型层面把Facebook群组和页面合并，那是一次非常棘手的迁移。

I remember we were trying to merge Facebook groups and pages at some point, like, in the in the data model side, and this was the this, like, very gnarly migration.

要完全做完的话，你知道，得花好几年，而且大概需要几百个工程师，因为你得在数据模型、产品层、完整性系统、广告系统等各个层面都做。

It it would have been you know, to fully do it, this is, many years and, like, probably hundreds of engineers to fully do it because you have to do it across, like, the data model or the product layer, integrity systems, ad systems.

有各种乱七八糟的东西都得合并。

There's just all sorts of stuff that has to get merged.

那时候，Joseph Carver刚加入，我想他是从Profile或者Events那边来的，就是另一个组织，跟群组团队合并来推动这件事。

And at the time, Joseph Carver, he just joined I think he came from either Profile or Events, like a different org that joined forces with groups to make this happen.

他当时在做这个，但他在一个决定上有点纠结。

And he was working on it, but he was kind of struggling with a with a decision at the time.

而且我觉得他当时级别比我还高。

And I think he was even more senior than I was.

但他就是一直没在数据模型上做决定。

But he just, like, wasn't making the decision on the data model.

所以我就拉了一帮人，然后我说，行吧。

And so I just took a bunch of people and I was like, alright.

整个组织的所有技术负责人，我们那天要花接下来的三个小时，基本上就是玩一个游戏，来做架构设计。

All the tech leads across the entire org, we're gonna spend the next three hours on this day, and we're gonna do this essentially game where we get to do architecture.

然后我把大家分成了两个队。

And so I split everyone up into two teams.

我记得是蓝队和绿队，还是什么来着，我忘了。

I think it was blue team and green team, or I forget what these were.

我们把这个怎么合并数据模型的问题抛给了大家。

And we gave everyone this problem of how do you merge these data models?

这是需求。

Here are the requirements.

然后每个人有三小时在白板上，他们必须提出一个设计方案。

And then everyone had three hours in a whiteboard, they had to come up with a design.

有趣的是，开始的时候我们完全不知道怎么做，因为这个问题看起来太疯狂了。

And what was cool is that going into it, we had no idea how we would do this because it just seemed too crazy of a problem.

但结束的时候，我们得到了两个80%相同的设计方案。

But going out of it, we had two designs that were 80% the same.

所以很明显我们可以执行什么，而那20%有差异的地方，风险点也非常清楚。

So it was really obvious what we could execute on, and then the 20% where the differences were, it was very obvious where the risk was.

所以我们可以通过一些技术预研来提前处理一点风险，同时也能马上开始执行，因为我们完全清楚自己有什么。

And so we could kind of front load a little bit of that risk with a little bit of technical spikes, but also we can just start execution right away because we knew exactly what we had

需要做什么。

to do.

对，我看到那个的时候真的觉得很有意思。

Yeah, that was really interesting when I saw that.

那就像是一场技术设计竞赛，所有资深工程师参加，你把人们分到不同的房间去设计方案，我从来没听说过这样的事。

It was like a technical design competition with all the senior engineers, and you just put people in separate rooms to come up with I've never heard anything like that.

你当时在组织里提出这个设计竞赛的想法时，大家是兴奋呢，还是觉得这想法有点疯狂？

When you proposed that idea for this design competition within the org, were people excited about it or was it kind of a crazy idea?

对，确实有点

Yeah, it was

疯狂。

sort of crazy.

我是说，这种事情，你就得直接去做。

I mean, this sort of thing, you just have to kind of do it.

所以我就直接跟大家说，嘿，我们要搞这个。

So I just kind of told everyone, Hey, we're doing this.

然后我就把它加到每个人的日程上。

And then I just put it on everyone's calendar.

而且看起来挺有意思的。

And it just seems fun.

所以作为工程师，你会想参加的。

So as an engineer, you would want to do it.

但我觉得这种事情，有时候需要大家达成共识，有时候就得直接行动。

But I think this is the sort of thing where sometimes you need consensus and sometimes you just have to act.

在这种情况下，因为方向不明确，行动就显得特别重要。

And in this case, because the path wasn't clear, it was important to act.

但同时，我也不知道该怎么推进。

But at the same time, I didn't know how to proceed.

所以我们得把大家聚在一起，达成共识。

So we had to get everyone together to build consensus.

所以我觉得作为领导者，你总是在这两者之间权衡。

And so I think it's like as a leader, you're always juggling these two things.

经历了那次之后，现在要管理几百个工程师，还要快速做规划，你有没有什么建议给那些需要快速做规划的技术负责人？

After that experience, just being given hundreds of engineers and scoping things out, do you have any tips for someone who's a tech lead who needs to do quick scoping?

有没有什么对你特别有效的方法？

Anything that worked well for you?

我觉得我见过最大的问题就是，大家花太多时间，陷得太深，纠结于细节。

I think I think the biggest failure mode that I've seen is people just taking too long and getting too into the weeds.

细节总是无穷无尽的。

There's always an infinite number of details.

先从宏观层面开始。

Just start with a high level.

大多数技术评估，你可以在三十分钟内完成，非常粗略地。

Most technical scoping you can do within thirty minutes, very, very roughly.

如果你不熟悉系统，现在你可以直接用代码搜索工具，在代码库里跑一下，然后问它涉及哪些系统。

And if you don't know the systems, nowadays, you would just use quad code, run-in the code base, and just ask it what are all the systems involved?

它们其实可以帮你直接搞定。

They can actually just do this for you.

这又是一个完全颠覆性的变化。

And this is another just totally insane change.

我以前做这些事的时候，根本没想到现在AI能帮我做这些。

When I was doing this stuff, I never would have expected that AI could do this for me now.

但现在它确实能了。

But now it does.

不过我觉得以前我最大的建议就是，一定要限定时间。

In the past, I think that would have been my biggest advice though, is just time box it.

大概花个三十分钟，最多几个小时，如果你需要翻代码什么的。

Spend maybe thirty minutes, maybe like couple hours max if you have to dig through code and stuff.

一定要去找专家，列一个专家名单。

Definitely reach out to experts and just make a list of experts.

跟他们每个人都聊聊。

Talk to all of them.

把你的设计方案给他们看。

Run the design by them.

不要只是问他们意见。

Don't just ask them for input.

先给他们一个初步方案，这样他们才能真正给你反馈，你也有个讨论的基础。

Give them a straw man, Then they can actually give you feedback on it, and it's something to go off of.

继续聊你的职业经历，我觉得让你升到高级员工或IC7的，是Facebook上的公开群组。

Continuing with your career story, I think the thing that got you promoted to senior staff or IC7 was public groups on Facebook.

我很好奇你参与那个项目的背后故事，以及当时有没有什么有趣的事情发生。

I'm curious the story behind your involvement in that and anything interesting that happened at that point.

公共群组是其中一个

Public groups was one of

这些项目来自那次范围界定，目的是让 Facebook 群组更侧重于社区。

these projects that came out of this scoping for making Facebook groups more about communities.

我们当时想做一个非常小的改动，表面看起来很简单，但背后却非常复杂。

There was this one very narrow change that we wanted to make that seemed so simple on the surface, but it was so complex under it.

跟没经历过的人解释这件事，真的很好笑。

It's just funny explaining this to anyone that wasn't there.

他们会说，等等，这不就是改一行代码的事吗？

They're like, Wait, this is a one line change.

我说，不是的。

I'm like, No, it's not.

要把它做出来真的非常难。

It was very difficult to pull it off.

所以这个改动就是，要参与一个公开的Facebook群组，你不再需要先加入。

And so the change was, in order to participate in a public Facebook group, you no longer have to join first.

所以你的意思是，你可以直接查看，基本上对所有群组都有阅读权限，或者说公开群组。

So you're saying you can just view, like you have read access for all groups essentially, or public groups.

对所有群组有阅读权限，对某些群组还有评论权限。

Read access for all groups, and for some groups, comment access.

你可以不用先加入就能评论。

You can comment without joining first.

有意思。

Interesting.

而且关键在于，这看起来像是一行代码的改动，实际上也确实是一行代码的改动。

And this is the thing, it feels like a one mind change, and it actually was a one mind change.

但后面牵扯出的各种问题特别棘手。

But there's all these downstream implications that were so tricky.

比如，在数据模型里，数据库里基本上有一个字段叫“群组成员”。

So one is, you know, in the data model, there's essentially a field in the database that was like group member.

然后我们进行了一场非常激烈的技术讨论，比如那些在群里评论的人，他们算不算群成员？

And we had this, like, really intense technical debate about, like, these people that are commenting in a group, are they group members?

而且模型也变了，以前要加入Facebook群组，需要管理员批准你。

And the model also changed where before to join a Facebook group, an admin had to approve you.

所以这有点像一种信任投票，觉得你可以加入这个群。

So there's kind of a vote of confidence that you can be in this group.

后来我们换成了这个模式，加入公开的Facebook群组，基本上就是按一下关注。

And then after we switched to this model where to join a public Facebook group, just essentially press like follow.

我们其实反复讨论过，应该是加入还是关注？

And we actually went back and forth, should it be join or follow?

就是说，用什么动词来描述这个动作更合适？

Like, what's the right verb to describe this?

但基本上就是关注，因为没有什么双向的动作。

But it was essentially follow because there's no reciprocal action.

如果你关注了一个群，你算是成员吗？

If you follow a group, are you a member?

那这些人是不是也应该存在数据库的同一个地方？

Should you be stored in that same part of the database?

然后我们就这个问题来回争论了好一阵子。

And we just went back and forth on this for a while.

我记得当时有个特别资深的工程师，叫鲍勃。

And I remember at the time there was this really senior engineer, Bob.

他当时算是整个组织里最资深的工程师了。

He was kind of the most senior engineer in org at the time.

他非常坚持认为这两者不应该是同一个东西。

And he felt very strongly that it should not be the same thing.

他逼我们逼得挺紧的，即使要迁移数据会带来一大堆工程上的工作量，也要把它们分开。

And he kind of pushed us pretty hard, even though it would be a ton of engineering work to migrate stuff, to make it a different thing.

所以我们最后还是做了这个工作，因为他其实是Facebook群组早期的工程师之一，所以他对这块特别了解，而且他态度非常坚决。

And so we did this work because he was actually one of the early engineers on Facebook group, so he knew it really well and he felt pretty strongly.

还有一堆下游的改动，比如审核机制，以及管理员需要新的管理工具来处理大量的垃圾信息等等。

There's a bunch of these other downstream changes around moderation and different new admin tooling that admins would need to handle the influx of spam and things like this.

我记得当时在想，如果任何人都能评论，评论区肯定会被垃圾信息淹没。

And I remember at the time thinking, if anyone can make a comment, the comments are just going be filled up with spam.

我很难说服别人相信这一点。

And I had a hard time convincing people of this.

所以后来我建了一个蒙特卡洛模拟，来展示这种情况会怎么发展。

And so at some point I built this Monte Carlo visualization of how this would work.

那其实就是一个很简单的草稿模型，比如一条评论进来，它有好坏的概率，然后评论实际会怎样。

And it was just this really simple scratch pad of, know, a comment comes in, there's a certain probability of it being good or bad, and then what actually happens to comments.

我觉得这个模拟确实挺有效地说服了诚信团队，让他们参与进来帮忙。

And I think that actually did a pretty good job of convincing the integrity teams to jump in and help with this.

所以当时，页面诚信团队就加入了，他们帮忙做了评论排名，因为把垃圾评论排到后面是让人们看不到这些评论的主要技术手段。

And so at the time, the pages integrity team jumped in and they helped with a comment ranking, because ranking spam comments lower was the main technical mechanism to make it so people don't see these comments.

所以让用户参与进来，会带来一堆相当棘手的下游影响。

So there's a bunch of these pretty gnarly downstream implications of letting people participate.

还有我们正在做的数据模型迁移。

There's also this data model migration that we're doing.

所以为了完成这一切，我们得组建一个大团队来实现。

And so to do all this, we had to staff a big team to make this happen.

于是我们聘请了一位新总监，亚曼，他招了一批

And so we hired a new director, Yaman, who hired a bunch

的

of

工程师。

engineers.

还有不少内部调动，比如组织里一些最资深的工程师，有亨利·朗、乔·奇塔姆，还有其他几位工程师，他们都在做这个项目。

There's a bunch of internal transfers, so some of the most senior engineers from the org, there was Henry Long, Joe Cheetham, there was a few other engineers, and they were all working on this.

我和他们同级。

And I was the same level as them.

我当时是IC6，他们也是。

I was an IC6 at the time and so were they.

我记得当时有种冒充者综合征，要指导他们、给他们分配工作，但心里清楚我们其实是同一级别。

And I remember just feeling this imposter syndrome of having to direct them and point them at work, knowing in my mind that we're the same level.

虽然级别是保密的，但通过小道消息什么的，你还是能知道谁是什么级别。

Even though levels are hidden, you know through rumors and stuff who's what.

现在回想起来，我觉得这种冒名顶替综合征是多余的，因为级别根本不重要。

In hindsight, I think this was misplaced impostor syndrome because levels don't matter at all.

这是我现在的看法。

This is my current view.

有些级别很低的人，表现可能远超预期，给你带来惊人的成果。

Some people that are very junior can shoot way higher than that and just give you amazing results.

有些级别很高的人，也可能表现得很糟糕。

Some people that are very senior can give you terrible results.

所以级别其实没那么重要。

And so the level actually doesn't matter that much.

但当时，我记得自己确实一直在纠结这个，而且进入这个角色确实有点难。

But at the time, I remember just really thinking about this, and was just kind of hard to step into this role.

最后，我还是做到了。

And eventually, did it.

而且挺有意思的。

And it's funny.

最后，让我升到IC7的，其实是推翻鲍勃做的那个决定，因为他想搞一个大迁移，我们做了。

Eventually, the thing that got me the promo to IC7 was reversing this decision that Bob did, because he wanted to do this big migration and we did it.

然后就是，天哪，工作量太大了。

And it was just like, dude, it was so much work.

花了六个月或者一年时间，就为了迁移成百上千个调用点，确保做对。

It six was months or a year of work or something just migrating just hundreds and hundreds and hundreds of call sites to do this correctly.

然后从技术上讲，我觉得我们实际上就是在每个调用点加了个ifelse。

And then technically, I felt like actually what we did is we essentially just added an ifelse at every single one of these call sites.

在这个过程中，我们审查了所有调用点。

In the process, audited all the call sites.

我们大概知道是安全的，但实际上并没有改变逻辑。

We kind of knew that it was safe, but we didn't actually change the logic.

所以我们真正学到的是，member确实是建模关注者和群组成员的正确字段。

And so actually what we've learned is that, yes, member is the right field to model both followers and group members.

这个决定是对的。

This was the right decision.

所以我让当初做这个迁移的那个工程师，又把它给撤销了。

And so I pushed the same engineer that did this to then undo it.

让这个工程师来做这件事是对的，因为他愿意接受，而且能做好，这显示了他的成熟。

It was the right thing to push this engineer because it showed maturity on his part that he said yes and was able to do it.

他技术上也最有经验，所以他能做得最好。

He also had the most context technically so he could do it the best.

我觉得对Bob来说，他对我作为技术领导的感觉更好了，因为他知道我愿意收回成命，也愿意对资深同事的决定提出异议。

And I think for Bob, it made he felt better about me as a technical leader because he knew that I willing to pull back, to push back on decisions that even senior folks make.

最后，这样做是对的。

And in the end, this was the right thing.

我们撤销了那次迁移。

We reversed the migration.

撤销也花了不少时间。

It also took a long time to do it.

但最后，这让所有在这个基础设施上开发的人都能顺利工作，大家不用再老是纠结该用这个字段还是那个字段。

But in the end, it made it so everyone building on this infra could do it, and everyone wasn't always constantly bumping into this, should I use this field or this field?

我对那部分很好奇，因为你跟Bob或者资深技术负责人有强烈的技术分歧。

I'm curious about that part because you had a strong technical disagreement with Bob or senior TL.

但最终的结果似乎是关系反而加强了。

But the outcome at the end is actually it seems like it strengthened the relationship.

他在你的晋升中成了你的支持者。

He was a champion for you in your promotion.

所以我很好奇，你会怎么建议在强烈的技术分歧中不伤害关系呢？

So I'm curious, how would you recommend going about strong technical disagreement in a way that doesn't hurt the relationship?

我觉得最重要的是你得先赢得这个资格。

I think the biggest thing is you have to earn it.

你得先赢得信任。

You just have to earn trust.

这可能就像我一开始做的那样简单，就是先表达不同意见，然后承诺执行，并且表现出我愿意这么做，如果别人觉得是个好主意，而且我尊重他们，我就愿意去执行。

And it could be as simple as what I did at the beginning, is just disagreeing and committing and showing that I'm willing to do that and I'm willing to just execute if someone else thinks it's a good idea and I look up to them.

但你也得展现出你良好的技术判断力。

But also, you have to show that you have good technical judgment.

但除非你已经建立了信任，否则你没法真正做到这一点。

But you can't really do that until you're on trust.

所以先花时间建立信任。

So take the time to get that trust first.

然后，

Then on

关于冒名顶替综合征，带领那些同样非常强的工程师时，你有什么克服冒名顶替综合征的建议吗？

the imposter syndrome, leading those engineers that were also very strong, do you have any advice for overcoming imposter syndrome?

对，别想太多。

Yeah, just don't overthink it.

其实在任何层级，没人真正知道自己在做什么。

No one really knows what they're doing at any level.

没人真正知道。

No one really knows.

我们都在摸索着前进。

We're all just trying to figure it out.

说起来容易做起来难。

It's easier said than done.

有没有那么一个时刻，你突然觉得，其实我能行，或者这也没什么大不了的？

Was there an moment where you realize, Actually, maybe I do got this or this isn't that big of a deal?

说实话，我觉得没有。

I don't think so really.

没有一个特定的时刻。

There wasn't a single moment.

它是随着时间慢慢消失的。

It kind of goes away over time.

我觉得不管在哪个层级，你都应该有一点冒名顶替综合征。

I think at every level, it doesn't matter what level you're at, you should always feel a little bit of imposter syndrome.

因为如果没有，那就说明你没有在逼自己。

Because if you don't, then you're not pushing yourself hard enough.

在这个

At this

职业阶段，你越来越像技术负责人，因此写的代码越来越少。

point in your career, you were more and more of a tech lead and therefore you were writing less and less code.

你提到，尤其是在Meta，有些其他职能团队人手不足，而你把这看作是工程师的机会。

And you mentioned that at Meta especially, there's cases where other functions are understaffed and you view that as an opportunity for engineers.

也就是说，要更有产品思维，也许还能帮忙分担一些产品经理的工作。

So to be more product minded and maybe help out with the PM opportunities.

我很好奇，你觉得什么时候应该往那个方向发展，而不是升级问题，比如说‘嘿，我们需要更多产品经理的支持’，然后自己多写点代码？

I'm curious, when would you say that you should go that direction as opposed to escalating and say, hey, we need more PM support and trying to write more code instead.

对，你得明白其中的权衡。

Yeah, you have to understand the trade offs.

我觉得这是很多人在推动事情时不太理解的一点。

I think this is the thing that I think a lot of people don't really get when they push for stuff.

一个很常见的失败模式是，工程师推动一个想法，然后因为没人支持、没人愿意投入资源，或者组织不理会、领导不理会而感到沮丧。

Think a very common failure mode is an engineer will push for an idea and then gets frustrated when no one else buys into it or wants to fund it, or the organization just doesn't listen or their leader doesn't listen.

但你要做的是理解其中的权衡。

But what you have to do is understand the tradeoffs.

无论你想说服谁，都要从他们的角度去考虑。

Whoever it is that you're trying to convince, think of it from their point of view.

他们关心什么？

What do they care about?

他们正在做什么项目？

What are the projects they're working on?

这件事的代价是什么？

What is this trade off against?

如果他们做了这件事，他们会觉得自己的工作成功吗？

If they do this thing, are they going to see their work as a success?

所以我觉得这真的很重要。

So I think that's really important.

有些组织有时候可能没有产品经理，因为项目可能不太吸引人，所以很难招到人，也许领导已经感受到了这种痛苦。

For some orgs at sometimes, they might not have PMs because it might just not be a very sexy project, and so it might be really hard to hire, and maybe the leader is already feeling that pain.

有些组织可能想招产品经理，但实际上那些产品经理有更重要的事情要去做。

Maybe for some orgs, they are trying to hire PMs, but there's actually just much more important things those PMs should go to.

而另一些组织呢，可能产品经理太多了。

For other orgs, they might actually have too many PMs.

所以如果你去问的话，那其实是正确的做法，因为他们可以从一个不太重要的项目上抽调一个产品经理，放到你的项目上，因为你的项目更重要。

And so actually if you ask, that's the right thing to do, because they could just take a PM off a less important project and put it on your project because it's more important.

所以我觉得，要了解自己所处的环境，理解决策者的想法，这一点非常重要。

So I think it's really important to be situationally aware, understand the context you're in, and understand how your decision makers think about it.

到了这里，差不多是你故事第一部分的结尾了。你把很多成功归功于那些支线任务，还有那些副业项目，或者你称之为“20%时间创意”的清单。

At this point, and this is kind of the end of that part one of your story, you credit a lot of your success to, again, the side quests and having these side projects or a running list of you called them 20% time ideas.

我很好奇，对于工程师来说，你有什么找到机会的建议吗？

And I'm curious, do you have any tips on how to find opportunities for engineers?

我记得大概有5100名工程师吧，具体数字我记不清了，他们都在做我规划出来的那些支线任务，这些任务是从不同地方衍生出来的。

I think at some point, was probably I forget the exact numbers, but there was probably 5,100 engineers or something like this that were just working on these side quests that I scoped out and spun out of various points.

所以几乎每周，我都会在跑步的时候或者写代码的时候，想到一些项目点子。

So pretty much every week, I would think of some project just on a run or something or maybe while I'm coding, I think of some idea.

我会先做个基本验证，然后找个我认识的工程师，问一句：嘿，你对这个感兴趣吗？

I'll just do some basic validation, then I'll just ping an engineer that I know and be like, Yo, are you interested in this?

然后我会把他们介绍给其他几个可能感兴趣的工程师。

And then I'll connect them with a couple other engineers that might be interested.

这样一来，事情很快就积累起来了。

And this kind of added up very quickly.

对我来说，我思考工作的一种方式是：我怎么能少做点？

I think for me, one way that I really think about my work is how can I do less of it?

作为工程师，我们的超能力就是自动化。

And as an engineer, our superpower to do this is automation.

最繁琐的事情你都可以自动化。

The most tedious stuff you can automate.

这对其他领域来说其实很难，但对我们来说，这是我们能做的了不起的事情。

And this is something that's really hard actually for other fields, but for us it's this incredible thing that we can do.

而且很多工程师出于各种原因并不这么做，但我们其实应该一直这么做。

And it's something a lot of engineers don't really do for whatever reason, but we should all be doing it all the time.

这太重要了。

It's so important.

这就是杠杆效应。

It's leverage.

就像是免费的杠杆。

It's like free leverage.

所以我经常做的一件事是，每次做代码审查时，如果我评论了某类问题，比如风格问题之类的，我真的有一个电子表格，我会记录那个问题，并附上那个拉取请求的链接。

And so a thing I often did was every time I did a code review, if I was commenting about a particular kind of issue, maybe like a stylistic issue or something, I literally had a spreadsheet where I would tally up that issue and I posted the link to that pull request.

然后每次代码审查我都会这么做。

And then I would do this for every code review.

当我对同类问题评论超过几次后，我就会为它写一条lint规则来自动化处理。

And then when I commented about the same kind of thing more than a few times, I would just write a lint rule for it to just automate that.

所以这算是杠杆效应的一个例子。

So this is kind of an example of leverage.

到后来，我自动化了大部分代码审查，因为我有一堆lint规则在帮我做这些工作。

And at some point, I automated most of my code reviews because I just had a flock of lint roles that were just doing all this work for me.

我觉得这其实挺类似的，因为所有这些支线任务都在改进生产环境和开发环境的基础设施，而这些正是我日常编码中拖慢我速度的东西。

And I think this is actually kind of similar because all these side quests, it was improving prod infra and dev infra, and these are things that slowed me down in my day to day coding.

这就是为什么我在做West编码时，这其实非常危险，因为作为工程师，你需要扎根于现实。

And this is why when I was doing West coding, this was actually very dangerous because as an engineer, you need to be anchored to reality.

你需要那种直觉。

You need that intuition.

如果你不再接触代码，很快就会失去这种直觉。

And if you're not in the code anymore, then you lose it very quickly.

那是一个非常危险的状态。

It's it's a very dangerous place to be in.

所以对我来说，当我经常接触代码时，从中涌现出了很多很棒的想法。

And so for me, when I was in the code a lot, there was all these really cool ideas that came out of it.

这些想法不仅对我有用，对整个工程团队都有帮助。

And it was leveraged not just for me, but for the whole eng team.

因为还是那个原则：如果你遇到了问题，很可能其他人也有同样的问题。

Because again, of this principle that if you have a problem, probably other people have it too.

而且，你知道，我以前参加过YC，YC教你的第一件事就是先为自己做东西。

And, you know, I did YC back in the day, and in YC they teach you that first you build for yourself.

你得做出很棒的东西。

You have to build awesome stuff.

你得做出人们喜欢的东西。

You have to build stuff people love.

但如果你想找一个市场来为之打造，那就从为自己打造开始。

But if you're trying to find a market to build for you, start by building for yourself.

这是个很好的指标。

And that's a pretty good indicator.

其他人很可能也有同样的问题。

Other people probably have that same problem.

你写过一句话，我觉得特别好。

There was a quote that you wrote that I thought was really good.

你说，更好的工程能力是工程师扩展人脉和提升影响力的最轻松方式。

You said, Better engineering is the easiest way to grow your network and gain influence as an engineer.

所以我完全能看出来，你的影响力范围远远超出了你写的代码，因为你把这么多好点子传递给了别人，并且指导他们。

So I could totally see you had Your scope of influence was so much further than just the code you're writing because you're passing people all these great ideas and overseeing them.

这种杠杆作用真的很惊人。

Leverage is really insane.

绝对是的，对。

Absolutely, yeah.

而且这其实也是一个例子，说明要具备情境意识，或者说对局势的敏感度。

And it's also just an example of being contextually was it situationally aware?

因为当时我遇到的情况是，工程师在绩效评估周期里被考核。

Because I met at the time engineers were evaluated in the performance cycle.

我们看的是项目影响、人员。

We looked at project impacts, people.

你还记得其他的吗？

Do you remember the others?

方向。

Direction.

方向。

Direction.

还有工程卓越。

And edge excellence.

对，工程卓越。

And eng excellence, yeah.

很多工程师在工程卓越方面都挺挣扎的。

And the eng excellence is a thing that a lot of engineers struggled with.

所以就有个人过来跟你说，嘿，如果你想做到工程卓越，这儿有个项目。

So was one of the people that came along and was like, Hey, if you want to do eng excellence, here's a project.

大家本来就有动力去做，所以他们会把这看作一个机会。

And people are already incentivized to do it, so they see it as an opportunity.

我觉得这对我来说是个机会，可以磨练我跟人合作的技巧，就是无论在什么情况下，你永远都不该直接命令别人做什么。

And I think this is just like, I don't know, I think it was a chance for me to kind of hone my skills about working with people where you never ever want to tell anyone what to do in any context.

不管是私人场合还是工作场合，没人喜欢被人指挥。

In a personal context, in a work context, everyone hates being told what to do.

但如果你了解一个人想要什么，那你就能带着合适的机会去找对的人，他们就会把它看作一个机会。

But if you understand what a person wants, then you can go to the right person with a right opportunity and they see it as an opportunity.

这样对每个人来说总是更好。

And this just always works better for everyone.

当我想到这些20%时间项目时，我是说，最上面是找想法，然后才是真正去执行，找人来干，不管是自己还是别人。

When I think about these 20% time ideas, I mean there's the top of funnel finding the ideas, and then there's actually executing on them, getting someone to do it, or whether it's yourself or someone else.

我感兴趣的是最上面那部分。

The thing I'm interested in is the top of funnel.

作为工程师，你怎么找到这么多有影响力的副线任务的想法？

How do you source so many ideas as an engineer for these side quests that are impactful?

就是常识。

Just common sense.

我不知道，也许是直觉吧。

I don't know, maybe spidey sense.

不知道。

Don't know

对的，就是那种蜘蛛感应。

the right Spidey sense.

怎么说？

How so?

能举个具体的例子吗？

What's a concrete example?

一个很具体的例子就是，想想 lint 规则，这个挺好的。

A really concrete example is think lint rules are a good one.

还有一个例子，就是有很多次我们遇到 SEV，因为 Facebook 群组没有用非常大的 ASOC 集合来测试。

Maybe another one is there were all these cases where we had SEVs because Facebook groups were not being tested with very large sets of ASOCs.

所以，比如说，ASOC 有点像 Facebook 里说的数据库行。

And so, for example, an ASO kind of like this is kind of like a Facebook way of saying, like, you know, rows in a database.

你可以想象一个有一千万成员的 Facebook 群组。

So you could imagine, like, a Facebook group with, 10,000,000 members.

从来没有人测试过这种情况。

Like, no one's ever tested this.

这根本没有单元测试。

There's no, like, unit test for this.

只有在生产环境里才能看到问题。

You only see it in production.

当我纵观整个组织时，我开始看到类似的情况。

And when I looked across the org, I started seeing similar cases of this.

比如，一个有两千万粉丝的账号，很多东西都会出问题。

There's, for example, like, you have a profile with, like, 20,000,000 followers, a lot of stuff breaks.

但显然，没有人用自动化方式测试这个，因为写一个包含这么多数据的单元测试挺麻烦的。

But, obviously, like, no one tests this in an automated way just because it's kind of annoying to write a unit test with this much data.

所以有很多这样的例子，然后我向工程师提议，建立一种为大数据集编写单元测试的方法。

And so there there's a bunch of instances of this, then I pitched an engineer to build a way to write unit tests for large datasets.

比如，一个非常大的对象，像有很多成员的群组，有很多粉丝的账号，有很多参与者的活动。

So, you know, like a really big object, like a group with a lot of members, a profile with a lot of followers, an event with a lot of attendees.

我觉得这个基础设施现在还在用，并且避免了很多问题。

And I think this infra still exists, and prevents a lot of issues.

这件事是可以把控范围的，然后他拉了一帮其他工程师来帮忙干活。

And this is something where you can scope it, then he brought in a bunch of other engineers to do the work and help him out with it.

所以我觉得，就想想你每天实际遇到的问题吧。

So I guess just think about the problems that you actually hit day to day.

明白了，好的。

Got it, okay.

所以，想想这些问题，如果你反复遇到同一个问题，那就是时候自动化了，这也是一个很好的、更高级的工程项目。

So think about the problems and if you're experiencing that problem repeatedly then it's time for automation and that's a great, better engineering project.

对，没错，就是这样。

Yeah, exactly, exactly.

如果你两三次都碰到同样的问题，你大概应该四处看看，是不是其他人也遇到这个问题了。

If you hit the same problem two or three times, you should probably look around and see if other people are hitting that problem too.

你在Meta职业生涯的最后一段，是你

The last leg of your career at Meta is where you

拿到E8晋升的时候。

got the E8 promo.

我知道你换了部门。

I know that you moved orgs.

所以你在Facebook群组里完成了所有的晋升，然后你转到了Instagram。

So you did all of your growth in Facebook groups and then you moved to Instagram.

我很好奇，你转到Instagram部门背后的故事是什么？

I'm curious, what's the story behind you moving orgs to Instagram?

那时候，我正在谈恋爱。

At the time, I was dating.

我和我妻子当时还在约会。

My wife and I were still dating.

她住在伯克利，我住在旧金山，后来有一天她说，我找到了梦想中的工作。

And she was living in Berkeley, I was living in SF, and at some point she's like, I found my dream job.

我说，太好了，真棒。

And I was like, Sweet, awesome.

然后她说，我们得搬家了。

And then she's like, We're gonna have to move.

我当时就说，好，没问题。

And I was like, Okay, great.

那时候我们才交往了大概三个月。

We've been dating like three months at the time.

我们当时也在考虑，要不要继续在一起。

And we were kind of deciding like, should we like keep dating?

她说，如果你想继续在一起，我们就得搬家。

So she was like, yeah, we'd have to move if you want to like keep dating.

我说，好，我愿意。

And I was like, yeah, okay, I do.

那就这么定了。

Let's do it.

结果那份工作是在日本的乡下。

And then so the job ended up being in like rural Japan.

那地方挺偏的，算是荒郊野外吧。

It was sort of, like, middle of nowhere.

我当时在想，这到底该怎么弄呢？

And I was trying to figure out, like, how do I do it?

因为我真的很喜欢我当时做的工作。

Because I really like the work that I was doing.

所以一开始，我跟Facebook群组的领导层谈了谈，想试着在日本那边给Facebook群组设个办公室。

And so first, I talked to, like, Facebook groups leadership and tried to set up, like, a Japan office out there for for Facebook groups.

但这事儿因为一堆组织上的规矩，没怎么成。

That didn't really work for, you know, a bunch of kinda organizational rules.

然后我又试着跟VR部门那边弄，其实都快成了，但后来赞助这事的人走了，好像是去了YouTube还是哪儿。

Then I tried to do this with the VR org, and it was actually working, but then the person that was sponsoring it left to go to, I think, like, YouTube or something.

那时候，Will Bailey联系了我，他在Instagram东京办公室。

And then at the time, Will Bailey reached out, and he was in the Instagram Tokyo office.

他是Instagram那边落地团队的一员。

He was part of this, like, landing team for for Instagram.

他就跟我说，嘿。

And he was like, hey.

我有点想把办公室扩大。

I kinda wanna grow this office.

你想参与进来吗？

Do you wanna be part of that?

我说，好啊。

And I was like, yeah.

那我们就干吧。

Let's let's do it.

其实我什么都不懂。

And I didn't know anything.

我当时连Instagram都没装。

I I didn't even have Instagram installed at the time.

我从来没用过。

I'd never used it in my life.

所以我说好之后，马上下了Instagram，然后大概下个星期就搬过去了。

And so I I said yes, then I immediately downloaded Instagram, and then, like, I moved, like, I think, like, next week or something.

所以基本上，其实我觉得我在美国就待了几个星期。

So pretty much or actually, I think it was like a few weeks that I had in The US.

但我很快就搬走了。

But I moved out pretty quickly.

而且我真的很喜欢Instagram的文化。

And I actually really fell in love with the Instagram culture.

它和Facebook的文化很不一样。

It was very different than Facebook culture.

它非常注重打造出色的产品，注重发布人们不用的东西，注重从数据角度思考问题，同时也从人性和体验的角度去思考。

A big emphasis on building awesome products, on shipping stuff that people don't use, on thinking about things not just from a data point of view, but also from a human point of view and an experience point of view.

你可以从应用本身和投入其中的工艺中看到这一点。

And you can see this in the app and in the craft that goes into it.

这两家公司的工程、产品和设计文化完全不同。

It's just completely different engineering and product and design cultures between the two companies.

所以我在那个团队学到了很多，那是一段非常有趣的旅程。

So I learned so much being on that team, was such a fun journey.

你提到了“卸载”这部分。

You mentioned the unshipped part.

那是什么？

What is that?

卸载功能的意思是，如果你只是给应用添加功能，对一小部分用户来说很酷，但实际上对大多数不使用该功能的用户来说是不好的。

Unshipping is the idea that if you just add features to an app, it's cool for some small percent of users, but it's actually bad for most users that don't use the feature.

所以你可以想象一个应用，你只往里面添加功能，随着时间的推移，功能会积累起来，越来越多。

And so you can think of an app where you only add features to it, and over time the features accumulate and they add up.

如果每个功能只有大约10%的人使用，那么普通用户会看到一堆他们不用的功能，所以看起来杂乱无章，让人困惑。

And if every feature is used by like 10% of people, the average user sees a bunch of features that they don't use, and so it seems cluttered and confusing.

当他们打开应用时，不知道该怎么办。

And when they open the app, they don't know what to do.

对于软件来说，从根本上讲，屏幕的大小是有限的。

With software, fundamentally, the screen is of limited size.

这就是有限的资源。

That's the limited real estate.

这是一个有限的资源，所有不同的功能都在争夺它。

It's a limited resource that all the different features are competing for.

所以增加一个功能，就会夺走用户可能使用的另一个功能的机会。

And so by adding a feature that's taking the opportunity away from a different feature the person could have used.

所以“去功能化”就是你必须设定一个使用门槛，如果一个功能达不到这个门槛，就直接删掉它。

And so unshipping is the idea that you have to meet some sort of usage bar, and if a feature doesn't meet that bar, then we just delete the feature.

虽然一小部分用户会不高兴，但对大多数用户来说其实是很好的，而且平均来看，对所有人都是非常好的。

And a small percent of users are going to be pissed, but it's actually great for the majority of users, and on average, it's really great for everyone.

在你职业生涯的这个阶段，你不仅仅是换了部门。

At this point in your career, you didn't just move orgs.

你跨越了半个世界，去Instagram工作。

You moved across the world to work at Instagram.

我觉得当你是一个资深技术负责人，在原来的部门有很高的信誉时，做事或者影响别人会容易得多，因为大家会说，哦，我认识Boris，我知道他过去的工作。

And I think when you're such a senior tech lead with a lot of credibility in your existing org, it's much easier to get things done or at least influence others because they say, oh, I know Boris, and I know his past work.

但我很好奇，你在Instagram，离大家那么远，是怎么建立起信誉的？

But I'm curious, how did you build up credibility at Instagram when you were so far away from everyone else?

我觉得早期很多功劳要归功于Nam，就是Nam Guian，他现在还是Instagram的活动副总裁，还有Jeff Huang，他当时是我的主管，现在已经是副总裁了。

I think a lot of the credit early on, this goes to Nam, who was Nam Guian, he was the he's still the VP of events at Instagram and and Jeff Huang, who was my director at the time, but now he's a VP.

Will，我觉得这些人帮我们建立了很多联系。

Will, I think there was a lot of connections made by these people.

比如说，Nam就跟我说，嘿，你真的很喜欢做代码质量和减少技术债务，这在Meta我们叫更好的工程实践。

So for example, Nam was like, hey, you really like working on code quality and tech debt reduction, which we call, you know, better engineering at at Meta.

然后他就帮我联系了做这方面工作的人。

And he kinda connected me with the people working on it.

就是像Lucas Camera和Gabe，还有一堆其他在做这些事情的人。

This was, like, Lucas Camera and Gabe and a bunch of this bunch of these other folks that that were working on this stuff.

所以这些联系真的很有用。

So so those connections were really useful.

然后我觉得很大一部分就是我得重新赢得信任。

And then I think a lot of it was I just had to earn the trust again.

说实话，这是一件很健康的事情。

And honestly, this is a healthy thing to do.

我觉得这是Meta工程文化中非常棒的一点，就是没有头衔。

And I think this is one of the really awesome things about meta engineering culture, that there are not titles.

所以你得不断地重新赢得别人的信任。

And so you kind of have to constantly re earn your trust.

即使我以前是个优秀的工程师，在Instagram上也不一定优秀。

And even if I was a great engineer in the past, I may not have been a great engineer at Instagram.

如果我不优秀，那我就不配拥有影响力。

And if I wasn't, then I don't deserve influence.

我不配拥有一个大家愿意听的大嗓门。

I don't deserve to have a really loud voice that people listen to.

所以我必须和其他人一样，去赢得这份信任。

So I had to earn it along with everyone else.

所以最初几周，我花了很多时间见人、梳理组织结构、明确目标，还写了很多代码来熟悉代码库。

And so my first few weeks, I spent a lot of time meeting people, mapping out the org, mapping out goals, writing a lot of code so I can get to know the code base.

但在日本就完全不同了，因为东京时间下午4点，也就是东京时间早上9点，相当于纽约时间晚上7点。

But then in Japan it was totally different because like 4PM Tokyo time was like, it was like 9AM Tokyo time, it was like 7PM New York time.

就是完全没有时区重叠。

There was just like no time zone over.

确实挺辛苦的。

It was rough.

但这也很好，因为我觉得在那之前的几年里，我开了太多会、写了太多文档，都没怎么写代码。

But it was also great because I think in the few years before I was doing so many meetings and docs and all this stuff, I just wasn't coding.

所以我开始觉得很不开心，因为作为工程师，我们就是写代码的，这就是我们的工作。

So I just started to feel pretty unhappy because like as an engineer, we code, that's what we do.

这也是我们选择这份工作的原因。对我来说，写代码的时候，我和代码之间有一种情感上的联系。

That's the reason we picked this job For me, when I write code, have an emotional relationship with the code.

这是我一直在思考的事情。

It's something that I think about.

当我深入解决一个问题时，我甚至会梦到它。

When I'm really deep in a problem, I dream about it.

所以写代码对我来说真的太重要了。

So it's just so important for me to code.

而当我好几年都没这么做的时候，确实挺难受的。

And when I wasn't doing this for years, it was sort of rough.

我觉得自己开始有点倦怠了。

I think I was starting to burn out a bit.

其实，能待在这个时区算是种恩赐，因为我根本没法开会，要么别人还没醒，要么人家不想为了聊天而开晚上九点的会。

Actually, was a gift to be in this time zone where I literally couldn't do meetings because people weren't awake or didn't want to do 9PM meetings just to talk.

我不再参加任何一对一的会议了，而且到现在我也一直没恢复。

I didn't do any more one on ones, and this is actually still something I don't do.

所以我现在依然不参加任何定期的单独会谈。

So I still don't do any standing one on ones.

我就能花大量时间写代码。

And I just could spend a lot of time coding.

我意识到，当时在Instagram，我是少数几个写这么多代码的工程师之一。

And what I realized is I was one of a few engineers at Instagram at the time that was coding this much.

大家都会写代码，但不会写那么多，因为总有各种事情占满你的时间。

People code, but people don't code that much because there's all the stuff that fills up your time.

有会议、文档，还有其他各种杂事。

There's meetings and docs and all these other obligations.

而我却做了很多别人想做却没时间做的事。

And I was able to do a lot of stuff that I think everyone else wanted to do, but just didn't have time.

在那个组织里，这算是一种超能力。

This was kind of a superpower in that org.

很早的时候，NAM就把我介绍给了Joe Paymer，他现在还是我的好朋友和导师。

Pretty early on, NAM connected me with Joe Paymer, who's still a good friend and mentor.

他现在在谷歌工作。

He's at Google now.

我们开始聊起来，当时代码库是用Python写的，因为各种原因，情况有点糟糕。

And we just started talking about, at the time the codebase was written in Python, it was sort of rough for a lot of different reasons.

其实代码库应该迁移到Hack上，那是Facebook的主要单体代码库。

Really the codebase should have been moved over to Hack, which is the main Facebook monolith.

那里有所有的语言支持。

This is where all the language support is.

基础设施太多了。

There's so much infra.

HHVM 真的是一个非常出色的网络服务栈。

HHVM is just this absolutely phenomenal web serving stack.

在效率方面，没有其他东西能比得上它。

There's nothing else like it in terms of efficiency.

如果你用 GraphQL，你绝对得用它，因为它对这些东西优化得太好了。

If you're using GraphQL, you absolutely have to use it because it's just so optimized for this stuff.

而 Instagram 根本没有用这些，工程方面很受影响。

And Instagram just wasn't using any of this and engineering was suffering.

比如在很早的时候，你知道，就像 Mikey 在 Instagram 那会儿，最基本的决策原则就是做简单可行的事。

Like in the really early days, you know, like when Mikey was at Instagram, really basic decisions were The basic principle for decisions was do the simple thing that works.

这当时效果很好，但后来某个时候就不行了。

And this worked really well, but then at some point it stopped working.

当代码库有一千、两千个工程师在开发，而且多年的技术积累和产品层层叠加，你就得做出和刚开始时不同的决策了。

Once you get to like a thousand engineers, 2,000 engineers working the code base and many, many years of tech ed and products built on top of each other, you have to make slightly different decisions than you would have made at the start.

所以即使一开始用Python是完全正确的决定，但等到我去的时候，它已经不再合适了，作为工程师，这一点显而易见。

And so even if Python was absolutely the right decision at the beginning, it was not the right decision by the time I was there, this was painfully obvious as an engineer.

我觉得很多其他人也看到了这一点，但阻止他们的是把东西迁移过来所需的工作量。

And I think a lot of other people saw this, but what stopped them was just the amount of work it would have taken move the stuff over.

于是我就开始规划这件事，弄清楚需要做什么。

And so I just started scoping this and figuring out what it would take.

所以我一开始就去找那些最可能反对的人。

And so I started by finding the people that would disagree the most.

有一批基础设施的老前辈，他们觉得这个想法很糟糕，根本行不通。

And there's a bunch of these infra old timers that just thought this was a terrible idea and would never work.

所以我先去找他们谈了谈。

And so I went to talk to them first.

就像在纽约吃美食一样，我们买了一些啤酒，先了解他们作为人的一面，然后才讨论技术问题。

Like food in New York and we got a bunch of beer and just got to know them as people before we even talked about the technical problem.

你必须建立信任。

You have to build trust.

所以我得先了解他们作为人，这真的很有价值。

So I had to kind of get to know them as people and this was so valuable.

这些人现在很多还是我的朋友。

And this is still a lot of my friends today.

在建立了信任之后，我还发现其实有很多人也想做这件事，只是不敢说出来。

And after building this trust, I also learned there was a bunch of other people that actually did wanna do this and were kind of afraid to say it.

所以这些人也都冒出来了。

And so these people came out of the woodwork too.

最后我们开始规划这个项目，然后它就独立出来了。

And eventually we started scoping this, and this project spun out.

这个项目现在还在进行，有很多工程师在参与。

It's actually still going today, there's many engineers working on it.

但有趣的是，在Facebook，这种问题很少发生，因为组织非常以工程为导向。

But it's funny because at Facebook, think this kind of problem rarely happens because the org is so engineering driven.

在Instagram，有很多类似的问题，因为组织非常以产品为导向。

At Instagram, there were many problems of the shape because the org is very product driven.

所以其实没有太多时间去做那些工程驱动的项目。

So there isn't just a lot of time for those engineering driven initiatives.

这个项目，在

This project, at

某个时候，我是说，你把它搞起来了，算是那种自下而上的倡议。

some point, I mean, you got it off the ground, kind of this bottoms up initiative.

然后到了某个时候，它的优先级变得很高，需要有人亲自支持，而且那个人不能在日本。

And then at some point, it became high pry enough where it needed that in person support of someone that wasn't in Japan.

我知道Jake Bolam是你帮忙拉进项目的，他后来更像是主导角色，但他在地理位置上是靠近大家的，所以能帮忙推动项目。

I understand that Jake Bolam is someone that you helped onto the project and he kind of took more of a lead role but location based and close to everyone else so he can help shepherd it along.

我很好奇你对这个委派节点的看法。

I'm curious your thoughts on that point of delegation.

你什么时候决定把这么大的事情委派出去？

When do you decide when to delegate something so big?

你什么时候决定，哦，我还得继续参与？

When do you decide, oh, I need to still be around?

那你又是怎么处理这种权衡的呢？

And how do you navigate that trade off?

Jake 非常棒。

Jake is amazing.

我们是朋友。

We're friends.

每次我去西雅图，我们都会聚一聚，他是我认识的最优秀的工程师之一。

Every time I go to Seattle, we hang out and he's just one of the best engineers I know.

所以很明显，他是负责这个项目的最佳人选。

So it was obvious that he would be a good owner for this.

授权的规则和平时一样。

The same rules of delegation apply as always.

你知道，你永远不会把你自己不想做的事情交给别人。

So, you know, you delegate you never delegate the thing you don't wanna do.

这大概是最重要的一条规则了。

That's kind of the most important rule.