Engineering management at Facebook

His thoughts on internal tools and support are very insightful. It's why I am typically sad when a company outsources its support.<p>When a company does its own support with internal personnel, it has a vested interest in making the customers happy and also serving them as efficiently as possible.<p>When a company outsources its technical support, there is no real incentive for the outsource partner to let the company know how the processes and tools can be improved and automated. In fact, quite the opposite. If doubling the business means double the support costs, that works out great for the outsourcing partner.<p>Perhaps it's still possible to outsource the support work, but still care deeply about the details of how that work is done, and how the process can be improved/automated with systems. I haven't seen it work that way, however.

I spent a few years at Apple writing internal tools.<p>IMHO, this is the way to have an effect on a company completely disproportionate to any other activity I know of. The tools I wrote at Apple have enabled projects which, AFAIK, are completely unheard-of at any other tech company.<p>That said, don't expect a payoff proportionate to the effect of the tool.<p>From a company owner's perspective, however, excellent tools can provide an advantage that is difficult for competitors to match. That's worth an awful lot.

I like much of the advice, but the style and presentation of the message is, like so many things I've seen associated with Facebook, lacking any sense of humility. There's no "we did this because it worked for us and we're sharing in hopes that it may help others." Instead it's "Other people think this. They are wrong." Or "A commonly held belief is X. It is false."<p>This hubris has certainly been a powerful ally to Facebook's founder, but like so many other powerful people, companies, governments and organizations that came before them, I can't help but think it will ultimately lead to demise (unless tempered).

So the problem of "hiring the best" is solved by making hiring your top priority. Likewise the problems of development are solved by making tools your top priority. Presumably along with everything else that is a top priority, like making something insanely great.<p>I'm sorry, I just sensitive to how many times I've seen "top priority" in somebody's management presentation, as if it solves something.<p>That said, I mostly agree with the gist of what he's saying here.

With all due respect to Facebook and many great engineers at Facebook, if you look at quality of Facebook API ( documentation, bugs, reliability, compatibility), I don't think they followed "hiring the best" in the division working on Facebook API.

"You will begin to get the (objectively) best candidates"<p>If "it's [everyone's] job to say no-hire" when they're "not sure" about a candidate, I'd like to know what is done to avoid systemic bias in hiring decisions.<p>Anyone here from FB able to comment? How diverse is the work force, especially compared to applicants?

The processes section intrigues. As the "CTO" in a 4-person startup, I'm constantly juggling between getting $hit done and documenting what the heck I did to get $hit done. Seems to be a fine balance.

He's wrong. You should not focus on tools, focus on people and ideas. The people will then make the tools (and throw them away when they cause too much friction) as needed.<p>But Facebook is still young, they're still learning. Unfortunately they don't seem to be learning from the past, which means they get to repeat everyone else's mistakes.

A number of good responses about writing good tools. That's a no brainer.<p>It's scary to how many project managers I've had to explain why I have allocated 20% of my project planning to writing a new tool. They see it as wasted time because they don't think that we will be redoing the task again... when it's something sales try and sell with every project?!<p>The biggest thing that struck me were the strong statements about technical managers. I think the sentiment is correct, technically experienced managers are great. But it reads like you expect all technical managers to be up to date on their coding? Or just be competent at writing pseudo-code? Hopefully it is the latter!

impressive insights.