> doesn't say who did

No one does that, ever, at Facebook: public praise; never, ever public shaming. When the website goes down, the nameless engineer(s) who pushed the related merge request(s) are _thanked_ for making themselves available to the SRE/Release/Production/Security team who investigated, and that’s it. No one gets blamed, at least not publicly.

If what they did is unacceptable, people “leave the company” but there are only two options to leave:

- Fast – if something intentionally unacceptable happened; and

- Slow – and no one will know why, unless the person leaving wants them to. Most employees can find a job under a week so having an “unscheduled” departure isn’t a reliable sign of trouble.

That lack of detail is so characteristic of an internal document that I didn’t even notice. I would find it even _less_ likely for someone would be named in a public note — unless it’s the author. The press is deemed feral with Facebook no matter the circumstances, so sharing employees’ name is a _very_ unlikely outcome.

> He's not even answering the question he puts as heading.

Actually, he is: “Who knew about this work, and who signed off on it?” is asking for a head. He’s offering his.

But that’s not Facebook’s typical approach, and I realise that your dissatisfaction is probably because of the most important and least documented aspect of the company. Facebook is built for scale, and scale mandates reliable delegation. Let’s talk about that for a bit.

Delegation is more important at Facebook than anything: doing something you could delegate is somewhat a fireable offence because you are not as impactful as you could be; it’s also not giving others the opportunity to learn. That’s so ingrained that Mark literally couldn’t understand why he had to show up to Congress: surely all of their questions could be answered by people who knew about all this? The public perception, the likelihood that low-ranking employees risked public shaming, etc. all that was foreign to him. Mark is proudest of one thing: he answers fewer and fewer questions at the All Hands: it means that he manages delegation up to clarifying company-wide values.

The internal conversation when anything wrong has happened (think: “website went down”, “female nipple breastfeeding banned”, “account of a transgender person blocked because of lack of matching ID”) is framed in a strict delegation structure of responsibility:

- The person who _de facto_ made the decision, who had the context, who wrote the pull-request, who clicked “Against ToS”, etc. most likely doesn’t have enough seniority to be blamed for what happened. Blaming people for doing things goes against the company culture that promotes being bold as much as humanly possible.

- However, individual contributors have guidelines: someone had checked that they understand those before they started working. Those guidelines are notoriously clear, short, simple to decide, very extensible and open-ended. Think of military training, if you are familiar with that. The initial training phase, known as “Bootcamp”, hammer those guidelines. I suspect that the name is as a homage to the compelling simplicity of military instruction. The _All Hands_ is another opportunity for the same. That’s why new employees attend more often: experienced employees have heard the argument around delegation and the value enforcement become predictable.

For code, there are exactly two:

- Were all the test (on the PR page) green when you pushed?

- Were you available (on IRC) to respond to questions from the Reliability team when your code was scheduled to be released?

Note how Being insightful, Providing a solution, Understanding the detail of the tests, etc. — none of that is there: Green & IRC, that’s it.

For debating corporate values, there are also two rules:

- No physical threats or insults.

- Don’t talk to the press or publicly about internal debates.

There were some changes debated when someone tagged “All lives matter” on a wall because “Being a dick” would be too vague, and “Don’t be racist” could lead to unwanted consequences — but being told that this particular tag was not OK was deemed enough instruction. That’s because a core part of most guidelines is: If you don’t know, escalate. (By the way: writing on walls is perfectly fine and encouraged.)

You get the gist: there is a surprisingly thorough effort to make those rules simple, atomic, easy to tell.

The evaluation is: Did the individual decision-maker follow those guidelines? By design, telling if they did should be instant and non-controversial. If they have not, said-person gets told-off because the rules are dead-easy to follow therefore they really should.

I have never seen Facebook executives as angry as when they are pushed around with “Who did that?” questions when they were explicitely too senior to have been the one making the call. Their response was always very curt: “Whomever did that followed the guidelines. They report to me. Talk to me.” The problem was escalated. Therefore there isn’t anyone “below”: only the person in change counts and can be blamed.

That strong sense of delegation has some _intended_ positive consequences: as soon as the Release team tells an engineer that her code has a bug, she knows that the team is now in charge. She can’t suffer blame (unless the code was pushed without green tests). However candid she is about how the codebase is messy, or the integration tool is not helpful, all that is acceptable feedback and will be taken into consideration (if relevant, in due course). She won’t carry the blame. More generally, if you tag your manager on anything not explicitly covered by the guidelines: boom, you are out of trouble.

The real debate becomes, and the real strength of Facebook decision making, the pride of the company: _Would the current guidelines have prevented this problem from happening?_ Naturally No: a problem has occurred. Therefore the question becomes the more difficult (and scalable): Should we change the guidelines?

That’s when the person in charge has to think very hard (usually based on previous bad things happening) about whether, and how to change the rules. When the motto was “Move fast, break things” it was explicitly to appeal to that process. The company can‘t anticipate all of its problems (it certainly has proven that no one could recently). Therefore, the best you can do is learn as much as you can from your mistake, learn fast, and try to break things early. That way is seen as the most reliable and scalable option to finding a solution before what you develop becomes really essential for a lof ot people.

One example of that: Community Guidelines. Because Facebook has done a ton of mistakes, cultural, automation, complexity, etc. around those, they were confident that changing them would not help with the current political crisis in some countries. Few people have had the opportunity to “fail convincingly”.

Most of the time, No, you shouldn’t edit the Guidelines because:

- the problem is rare;

- there is no modification of the rule that wouldn’t open to more problems;

- any addition would burden the guideline. Dead-simple guidelines allow for faster processing, more people spending time improving things at scale. Nuance is seductive, unless you place yourself in a dynamic scenario, with constrained resources, constrained training capacity, intelligent adversaries. Plus, everyone belongs to many groups, so all those guidelines add up — and they only work if everyone knows them exactly off the top of their head.

The only way out (and you’ve seen that a lot lately) is to automate as much as you can so that you can take one of the simple rules out and make room for more nuance. That’s why Facebook invested in AI so early: Google was actively using a lot of what they were building; Facebook didn’t have industrial uses of AI until much later. You see that a lot internally, a bit on some of the open-sourced project. That’s why some small improvements, seemingly minor removal of friction help a lot internally: they take guidelines from conscious to unconscious.

So, back to Schrage’s message. He talks a lot about guidelines. It’s more or less explicit, but sentences like:

> the relationship was less centrally managed

> Responsibility for these decisions

> I should have known of the decision to expand their mandate.

are about that framework of delegation. The last one is a confessed failure: the person who didn’t tell him is a report. Therefore that’s on Schrage. He’s not blaming anyone else with that sentence but falling on his own sword. He’s very explicit in the following sentence: Managers and Executives’ role at Facebook seems one half to set-up that system of guidelines, and another half to remind everyone constantly that the system is there.

> Mark has asked us to reevaluate how we work with communications consultants.

It does sound like someone is “pushing the problem into commission” to re-use a common trope. It’s not: Schrage should consider that re-thinking as a core part of his role. If his manager’s manager (Schrage reports to Sheryl) came back and asked that he fixes his work explicitly, that’s because of an obvious, problematic incident. Having the front page of the NYTimes describing Facebook’s execs as lizard-people is day-to-day stuff for Schrage (Ok, maybe not NYT, but _The Guardian_). He gladly shake it off as ”less than ideal coverage”. Being asked to review an interaction by the boss means: “You done f*cked up. Big time.”

Back to the rest of your comment:

> The idea that our work has been interpreted as anti-Semitic

She’s not referring to the angle that you quoted but to the idea that attacking Soros on the ground that he’s rich (something alas increasingly common nowadays from companies like Definers) smells of the 1930s. Yes, her indignation now (which sounds very authentic to me) echoes with the NYTimes’ quote (which makes her take seem far more calculated). I haven’t seen anything like that (I don’t go on the part of the internet where everyone wins Godwin points all the time). However, I expect that, if there ever were such an attack anywhere, Sheryl has seen it. She’s undoubtely still deeply offended by it. She’s surprisingly comfortable when facing a lot of attacks, but her religion is a sensitive point.

If she were as cold and calculating as the article make her, she would be more aware of how self-defeating the irony of it all, and probably have scrubbed that: she doesn’t need to paint herself a victim like that in that section of her comment.

Finally:

> I know this has been a distraction at a time when you’re all working hard to close out the year — and I am sorry.

That paragraph is transparently meant for employees. Specifically people in Ads, Partnerships and Comms: they work more closely with Sheryl and they have had to take care of a lot of issues before the end-of-year code freeze, the Holiday madness and I’ve heard of a major bug in Ads, plus tough conversations with a lot of brands about the Christmas Ad budget. Whether you appreciate the product or advertising as a business model, you can understand that those people had a shitty week.

On top of that, shit like the NYTimes article introduces a lot of internal drama that makes keeping people focused on fixing other things not ideal. She's empathic and motherly (because she knows it’s not the Boy-King or Schrage who are going to).

It should have been cut out for public consumption. I find it endearing that the Comms team left it in, but I can see how it can seem tone-death.