Thread by @schrockn

1/ Another (belated) tweetstorm on the @software_daily FB engineering podcast series. This time starring my friend @tomocchino. It aired about a month ago. See original here: softwareengineeringdaily.com/2019/07/18/fac…

2/ Tom is the director of the React, Relay, web core teams, among others, and is an extraordinarily talented manager. The output and happiness of his teams speaks for itself. @the_prion covered a bunch of topics in interview. I'll select a few to comment on.

3/ Jeff asked Tom about FB's hard pivot to mobile starting in 2011, a perpetual series theme. This is a long section but one quote stands out:

"But when the company shifted to mobile, engineering-wise, we almost became a different engineering organization"

4/ My commentary: You might dismiss the mobile shift as “oh big deal it’s just a new iOS app”. Not just a frontend rewrite, but a total rearchitecture of the entire site, and required an organizational transformation, because underlying realities changed in a big way.

5/ Jeff asks about FB vs other cultures, especially w/r/t to infra teams: Tom notes that fb OSS infra projects were always built to solve specific problems. And that they were always embedded within our product monorepo.

6/ That means product always developed against the latest rev of infra projects. This means, say, the React team has to actively manage breaking changes in real time and rewrite product code. They live the consequences of their decisions in real time. Powerful dynamic.

7/ That means the React team is always continually testing their new ideas against real product code, which the the team is empowered to change, because of the shared ownership model within the monorepo. This can be chaotic but, if that is managed, the upside is huge.

8/ Jeff notes that problems at FB/GOOG et all are often leading indicators of problems that will hit others. Tom points to the work his team has done to scale the number of engineers in a codebase.

9/ Tom mentions some excellent keywords: declarative, immutable, functional. Embracing these concepts has technical benefits (e.g. easier to async and multiple cores) but real super power is guarantees they provide. These make it easier to add engineers to codebase safely.

10/ Jeff: “What’s the 10 year vision for React” Tom: Empowering both beginners and experts to build amazing frontends on any platform. React Native and ReactVR provide baselines on those platforms respectively. “Learn Once. Write Anywhere.” without papering over platform diffs.

11/ Jeff: “What was your biggest mistake as a manager?” Tom: “Not trusting the people I support enough early on.” He micromanaged in order to ensure quality of execution.

12/ My editorial comment here: I really like the term “Eyes on. Hands off.” to describe this mode of operation. Managers usually need to ensure *some* level of technical execution. Tom doesn't. React team is like the Golden State Warriors of JS :-).

13/ Tom continues: Actually, successful management has nothing to do with (micromanaging). Successful management is about providing support, encouragement, constraints, expectations, etc.

14/ Now for the part of the podcast that will be truly jaw-dropping for most managers out there. It's about FB's engineering mobility values and their recruiting infrastructure. Jeff starts by asking how engineering mobility has worked as company scaled.

15/ Tom insists that cross team mobility still a thing and has been institutionalized. Engineers encouraged to do "hack-a-months" on other teams. When people do move managers don't freak out generally. Why? One reason: "Because there is an endless supply of new engineers"

16/ Editorial comment: This is a statement totally alien to most software companies. This is a luxury of FB having tons of money and a super sophisticated, centralized recruiting machine, with tons and tons of tooling to support it.

17/ Check this out: When Tom needs an engineer he can enter in a new position in a tool and it gets filled by internal applicants or by bootcamp graduates. Often this gets resolved in <1 week.

18/ Another editorial comment: This also a function being part of a growing company. There are lots of non-zero-sum relationships internally. So wars over talent less frequent. One team winning doesn't mean another is losing.

19/ Tom also frames an engineer or manager moving as an opportunity to grow other people, expand their responsibilities etc. This mobility also keeps the organization interconnected and coherent. People maintain practices and relationships after they move.

20/ Jeff: Someone said about you: “Tom is good at making a group at a big company feel like a small company. Why is that important?“ Tom: "People do their best work when they don't feel like a cog in the machine." Really important for people to have friendships within team.

21/ Tom: You have to understand how your work connects to company but you also have to like coming to work. "I want them to think about going to bed on Sunday actually looking forward to get into the office on Monday morning."

22/ Jeff: What you're saying is that you want to cater to an engineer's strengths rather than coping with their weaknesses. But work still has to get done, even if undesirable work or work that might not be a strength. How do you cope with that?

23/ Answer so good will just quote verbatim. Tom: "It hasn’t been a struggle thus far, and I think the reason for that is because if you create an environment where the people you support know that you have their back, they will have yours."

24/ Tom (cont) "The people that I support recognize that if I come to them with a crisis where this really needs to be staffed or we really need to work on that, they will find ways to make sure that that work gets done even if it's not their number one choice."

25/ There were a *ton* of other gems in the interview, but wanted to limit this tweetstorm to be shorter than last ones. But I think you get a sense just how talented @tomocchino is and some of the unique properties of FB management culture and org infrastructure.