I recently left my job of 10 years at PayPal (5 as an engineer, 5 as an engineering manager) to join Meta. One month into my new role seems like a great time to check-in and reflect on the past.
I want to take this time to update my fellow confidants, friends, and the world, on why this job is 100x better (with a caveat that I’m still in a honeymoon phase and have recency bias). I’m going to only talk about four key areas that are most salient for me right now: engineering tools, management expectations and accountability, human-first relationships, and an early emphasis on scaling.
All of what you’re about to read is my personal opinion and doesn’t reflect the opinions of any company that I’ve ever worked for.
If any of this is of interest to you, you should consider applying – we’re hiring!
| Focus area | PayPal (10 years experience) | Meta (1 month experience) |
|---|---|---|
| 1. Engineering Tools | Lacking UI/UX and user-first design. Onboarding doesn’t involve using all tools you that you may use in your engineering career, extreme lack of early and structured on-the-job training as you start your career – this mostly left up to your manager and team (8,000 engineers/8 people on a team = 1,000 managers and different ways of doing things). Networking is done via an opt-in bot, inner-sourcing is challenging because all teams have different quality and engineering standards and poor documentation (there are some bright spots though, I’m looking at you: PayPal Credit). Tools don’t always work, the Jupyter Notebooks environment and other environments lack documentation and ease of access control (role requesting isn’t obvious and usually takes days to get access to something). | Extremely solid tools that focus on customers (engineers/TPMs/EMs). Bootcamp is focused on getting you on-the-job experience using all of the custom-built and performant tools Meta has to offer. You have a senior engineer mentor who crafts your practice bootcamp work based on your designation (front-end/back-end, AR/VR, Data Science, etc). You start networking and building a “everyone owns everything” culture from the very beginning. I worked with several teams during bootcamp that I may never work with again, and my interactions with them were extremely warm and welcoming. Tools just work, and even when there is an Incident it’s clearly noted that you may be impacted while using an internal tool. Most tools have been custom-made by a strong engineering culture – I haven’t had to use ServiceNow or Jira which is music to my ears and a massive reduction of ::eyeblood:: |
| 2. Management Expectations and Accountability | Every team (sometime as the director level, but even down to each manager) makes up their own rules, no consistent detailed management expectations. Considerations around performance and potential ratings may be put out org-level, but that criteria may be modified by each team. Some teams are more pragmatic than others here. Engineers do have a career ladder guide, but it isn’t specific and leaves room for squishiness and lacks concrete expectations. Promotion panels are inconsistent and allow for people to move organizations where the promotion process is more lax in hopes of a easier path to promotion. Meaningful action is usually not taking as a result of feedback. If it is, it’s not clearly tied back to consistent feedback over the years. This is usually a one-and-done email without follow-through. That may be because most of the feedback requires a cross-functional culture shift and is challenging to do. | Constant focus on manager culture, expectations that are detailed for all managers. There were several onboarding sessions both virtual meetings and with amazing videos that explain company values, manager expectations, and a world-class system in place for collaboration for work tasks/stories and code/pull requests. There is a focus from the start on documentation of one’s career and impact as an engineer and manager. Having concrete expectations and a focus on documentation gives the keys to people for their own career, instead of allowing for bias and inconsistent process. It seems like engineering managers want to manage where, from what I’ve seen, they tend to come from a strong engineering background. Feedback is taken seriously and publicly discussed for additional rounds of feedback from top-to-bottom. Trends in feedback are discussed with meaningful action plans and cross-functional changes seem to be easier because of the focus on extreme ownership, integrity in follow-through culture. |
| 3. Human-first relationships | Transactional (pun intended) relationships most of the time – lacked cultural emphasis on being a community. No culture onboarding other than pointing at “one team” principles on some slides. When you provide feedback on tools, teams don’t have a consistent way to follow-up and lack follow-through. Most internal tools lack decent instrumentation to gather internal customer experience, so decisions on features are not made with data. The security team does security first and cares about people second. Extremely high friction in logging into machines, using 2FA on your phone constantly, firewalls/VPN issues during rollouts without testing with a smaller cohort of people – simple engineering principles aren’t followed across engineering teams, even if they are security-related. | People honestly want to get to know you before they dive into the technical details – we build a community as we’re building products. Onboarding programs put extreme emphasis on this. Recognition has multiple avenues and isn’t a “thank you” email most of the time. Engineering teams that build internal products have open feedback, UX is consistent everywhere, and there are ways to provide feature requests that is consistent across the company. Feedback-is-a-gift culture cannot be undervalued. Data is everywhere, instrumented natively, easy to query and understand – mostly with custom-built tools that shine and have scaled to meet the needs of thousands of teams. Security is intrinsic and thoughtful, it seems like attention to LEAN principles like churn/waste and productivity was at the highest level when designing the authentication, authorization, configuration, testing systems, rollout, and experimentation systems. More on this at Life at Facebook as an Engineering Manager and this post from Akila Narain on Leadership at Meta. |
| 4. An early emphasis on scaling | Capacity planning is old-school, not dynamic, and has taken many years to build internal systems, instead of leveraging native and more performant software in the wild (e.g. k8 autoscaling). We would constantly see resource exhaustion and need to work with legacy tools to improve scale out as products grew and the volume increased. There were clunky methods of dogfooding and ramping new features. Scaling of internal tools also seemed to be lacking. The internally developed systems may handle the engineering team that worked on it, but usually couldn’t scale to handle 8,000+ people which was done in a big-bang fashion, lacked decent documentation/education, and didn’t have feedback baked in – making it seem like either over-confidence or oversight. Searching for documentation requires a PhD in research – the tools that support search are left up to hackathons and isolated teams to support without a consistent methodology to ensure they are helpful. | In most of the training, you’ll hear how early emphasis on scaling infrastructure and processes was critical to making the extreme strides to get to where engineers are in Disneyland everyday. From source control, to configuration, to ramping, to communication – a long-term vision has really helped scale out to support hundreds of teams. It’s easy to figure out who owns code and data assets with custom-built amazingness. During bootcamp you learn how to leverage the plethora of engineering tools you have at your disposal, including an amazing way to ship code to production that is years ahead of what I was used to. Documentation is everywhere, and if there’s one thing I’ll be looking to improve it’s more consistency in the way that’s done – however the search capabilities are not left up to a hackathon and a random team to support – they are world-class. I love how people can provide feedback on documentation and how that factors into search results where poor documentation is ranked lower. Check out Engineering at Meta for specific stories of scale like How we scale Live streaming for millions of viewers simultaneously |
I hope this has been a helpful summary of the key gradients that I see from company-to-company. This is what I’ve personally seen and isn’t what everyone sees. This doesn’t mean that I don’t value the teams, the people, and my time at PayPal, without that experience, and the amazing people I worked with, I wouldn’t be here today. This is a targeted look at culture and technology that I’ve experienced. I realize that I tend to have a more critical view of things than most, but I think it’s helpful to answer the question “How’s it going at Meta?” – because “stellar” just doesn’t cut it.
If any of this is of interest to you, you should consider applying – we’re hiring!