Wednesday, Aug 31, 2022 • 46min
BONUS: Comparing Company Cultures with Jay
Play Episode
Ever wondered how the culture of big companies like Meta, Microsoft and Amazon differ? Jay comes with a fairly unique perspective as he has now worked at all three of them. In his discussion with Pascal, he shares his views on the trade-offs that a company value like “Move Fast” brings along and how companies assign different weights to the value of making mistakes. Got feedback? Send it to us on Twitter (https://twitter.com/metatechpodhttps://twitter.com/metatechpod ), Instagram (https://instagram.com/metatechpodhttps://instagram.com/metatechpod ) and don’t forget to follow our host @passy (https://twitter.com/passyhttps://twitter.com/passy ). Fancy working with us? Check out https://www.metacareers.com/https://www.metacareers.com/ . Links: Power On: The Story of Xbox: https://www.youtube.com/watch?v=AJYsA1jXf60https://www.youtube.com/watch?v=AJYsA1jXf60 Timestamps: Intro 0:06 Jay Introduction 1:18 Business Engineering at Meta 2:43 Social Impact 5:35 Culture Shocks 8:24 The Value of Mistakes 14:15 Finding your Pace 16:14 Modes of Working in Different Teams 19:32 Expectations vs Reality 23:36 Workflows 30:02 Incidents 37:26 Internal Mobility 42:24 Outro 45:30 Bloopers 46:10
Read more
Talking about
Speakers
(2)
Pascal Hartig
Jay
Transcript
Verified
Pascal Hartig
00:06
Hello and welcome to a bonus episode of the
Meta
tech podcast and interview podcast by Meta
where we talk to engineers working are different technologies.Share
00:14
My name is Pascal and
the Office For National Statistics
has determined this episode to be deflationary asked this intro is a whopping 20% shorter than the average.Share
00:23
What exactly makes this episode of bonus episode you May ask and the only thing it really means is that we recorded the interview a short while ago and I'll be popping this into your feet while taking off some time this summer.
Share
00:35
There May also not be an episode in September but we will triumphantly return with a hopefully relaxed and ready host.
Share
00:42
That's me, that's me. Our interview is a little less techie this time but it is frankly the kind of discussion I wish I had had before joining the company Jay worked at
Microsoft
and Amazon
specifically AWS
before he joined Meta
which gives him the fairly rare ability to compare and contrast the cultures of those companies.Share
01:01
Every of those cultural decisions you make comes with trade offs.
Share
01:05
So it was fascinating to hear what in his view, you gain and lose when you establish something like move fast as a company value.
Share
01:13
I hope you enjoyed the discussion with Jay which starts now.
Share
01:18
Today I'm excited to be joined by software engineer and big tech veteran Jay. Welcome to the
Meta
tech podcast.Share
Jay
01:26
Thank you. Thank you. Happy to be here.
Share
Pascal Hartig
01:29
It's good to have you can we start like we always do here and just ask you to tell us a bit about yourself. So how long have you been at
Meta
now and what did you do before?Share
Jay
01:37
Yeah, yeah. So I've been a
Meta
for around six months now around and I worked as a software engineer almost all my career before Meta
, I was at Microsoft
for a little bit working on Azure
And AI
and then before Microsoft
I was in AWS
working on EC2 Elastic Compute Cloud
, which deals, you know, requesting capacity within the cloud and servers and all that fun stuff.Share
02:01
And now I'm here and not technically as a software engineer, I'm business slash partner engineer working with non-profits and social impact.
Share
Pascal Hartig
02:10
Well that sounds like quite a change then from your previous cloud experience?
Share
Jay
02:15
Right. Exactly. I was worried at first because you know, sometimes when you work in a more specialized field for an X amount of years, you kind of get comfortable. You want to work in there continuously just because you know, the area, you know, the product but at the same time, you know, taking a gamble and being thrown into a pond of something new.
Share
02:34
I think it's also really exciting and a great opportunity to learn such a vast variety of things in a short amount of time. So yeah, I thought it was a good opportunity and now I'm on social impact.
Share
Pascal Hartig
02:43
Cool, can you tell us a bit about this and specifically how does this differ from being a software engineer before and now being a, what is it called? Business solution engineer?
Share
Jay
02:54
Business engineer.
Share
Pascal Hartig
02:55
Business engineer. Just business engineer. Okay. Because I don't even know exactly what the job description behind that term is. Maybe you can enlighten me here a little.
Share
Jay
03:03
Yeah. And you know, to be honest, I don't know all of the, you know roles of a business engineer as well, especially because business engineering in general is not only a relatively new area, but if you look at different companies and their partner engineering / business engine rolls every single company has a different role and responsibility for that area of business engineering.
Share
03:25
So if you look at
Netflix
, if you look at Snapchat
, if you look at all these other companies, you know, some of them, some of the partner engineers, some of the business engineers might code 90% of the time and do something, you know, do the business side for 10%, but some engineers might just do the business side for 100%.Share
03:42
So it's really sometimes confusing to say because of how much of a variety there is between companies in terms of roles and responsibilities and even within
Meta
, a lot of teams definitely have variety there and you know, sometimes it's really hard to explain the role, but for me personally, I code around 50-60% of the time and then spend the rest on this realm of business side and that kind of means talking to external partners, understanding more about what they need in terms of the product and maybe you can kind of look at it, as a like a consulting kind of thing.Share
04:15
But I guess as a software engineer in my first few years of my career, it kind of felt very top down sometimes as in, you know, upper leadership would think about something, tell me oh Jay, you might be working on this or you might be working on this, whereas in a business engineering role here at
Meta
, I can decide, oh, I want to work on this, I see this gap in the product, I think there's an opportunity here and then I tell leadership and they say go for it and that kind of flexibility.Share
04:44
There is what driven me to the role and why I'm here now.
Share
Pascal Hartig
04:48
Yeah, we've discussed this quite a few times now on the podcast, how it can be a little overwhelming at first, when you come from a different environment where decisions are made for you top down, you're basically handed a nicely wrapped project coming with a ribbon at the top and that just doesn't really happen here.
Share
05:08
It's down to you to figure out what needs to be done and of course there are always exceptions. Sometimes there will be a big kind of company priority that is decided for you, but in most cases that still means a priority is set and how that translates into what your team does and what you want to do is still effectively up to you and you then are responsible for connecting the dots.
Share
Jay
05:34
Exactly.
Share
Pascal Hartig
05:35
Can we talk a little bit more about the area that you work in right now, because social impact still sounds a little nebulous to me. So potentially you could give us a few examples of partners businesses that you've worked with and what the kind of overall mission of your team is.
Share
Jay
05:49
Yeah, yeah, of course. So yeah, that's a great point. Social impact as a whole lot
Meta
is really big as, you know, and there are hundreds of teams there for me specifically, I work on the community and impact or g so there we work with specifically fundraising on Facebook
.Share
06:04
So when you see a lot of non profit organizations or type providers that support nonprofit organizations and charities create fundraisers on either their site or on
Facebook
and that's kind of what we work with.Share
06:16
And this is in relation to the fundraising tools, this might be in relation to the
UI
and the workflows you see on Facebook
to fundraise, but kind of like Giving Tuesday
, you think about that or you think about big fundraising events, women's history month times where we really want to raise money for charities is kind of Yeah, my, my role there.Share
06:36
I just want, we just want to make it easier for nonprofit organizations to raise money for their social causes through
Facebook
.Share
Pascal Hartig
06:42
That sounds really cool and I know that just some top line numbers are announced every now and then about the money that was donated on
Facebook
and was a staggering amount when you see this. So you really see the impact that this kind of big platform has bringing people together and then contributing to the course.Share
Jay
07:02
Yeah, exactly.
Share
07:03
You know, you were talking about numbers just throwing one out there. For example, our, our community in 2020 we made this public, we raised five billion for nonprofits just through
Facebook
and Instagram
tools. So tooling, so in here you can think about children's health, you can think about environmental causes, humanitarian causes.Share
07:23
And one notable example would be women's history month and there we saw women create twice as many fundraisers on
Facebook
and twice as many donations. And the fact that women are coming together to inspire other donors and promote these causes. Their, our platform is just a precedent of, you know, what our team, what fundraising team at Meta
.Share
07:44
And the tooling team can achieve in the future. So it's, it's really exciting.
Share
Pascal Hartig
07:49
Yeah, totally. I've done it a few times myself that I've set up a birthday fundraiser for a given course and I've also donated to others. It's kind of cool because you can see friends organizing one. And then of course it inspires you probably to do the same then once at the time of the year arrives.
Share
Jay
08:05
Yeah, yeah. We that's kind of you make a great point, that actually a focal point of our kind of drive and motive is to encourage engagement. We want to make donors more engaged in the product and make sure that they see their friends donate, so they donate and raise that kind of awareness between non-profits and just raising money in general.
Share
Pascal Hartig
08:25
Yeah. Fantastic.
Share
08:26
Okay. So I think now we've got a better idea of what you actually do that in the social impact organization. So now, I think the topic that we wanted to discuss a little more free form is just what you've seen between the different companies that you've worked at.
Share
08:39
So we now have basically
Microsoft
, we have Amazon
and we have Meta
here on the table. So I guess you're still here. So it can't be a total disaster on the Meta
side. But what have been the kind of biggest culture shocks that you've witnessed after joining?Share
Jay
08:56
Yeah. Yeah.
Share
08:57
This is a hard question, just because I would say there's a lot, especially looking at the differences between these companies, a lot of people are aware and a lot of people aren't aware, but I think each company leads their own stereotype in the sense that there are a lot of companies, like
AWS
there's a lot of companies like Meta
, there's, you know, a couple companies like Microsoft
, and basically, we're comparing the 33 kind of biggest examples in in tech, but you know, anecdotally from my side, I think one overarching thing theme and point that I saw while you know going through companies and experiencing the culture in each one would be the pacing, especially here at Meta
, I would say pacing is kind of an overarching thematic points in our workflows, whether it's development workflows, whether it's operational workflows, Meta's
kind of known externally that we have a fast kind of pace in terms of coding, even if you look at the interview process for software engineers were very were known to give two questions in a short amount of time and that's kind of why a lot of people might be deterred from joining Facebook
just because or Meta
of because of how fast the pace has to be and that really can be seen as maybe a representative of the company as a whole.Share
10:11
They think, oh, maybe
Meta
is too fast for me, maybe I won't be able to keep up with the pace and that is definitely what I thought when I at Microsoft
, which in comparison is kind of known to be more stable, slower iterations in general, make sure that nothing breaks, for example, Facebook
has a move fast pillar, one of the fundamental pillars is to move fast, it used to be break things, but now it's not, so just move fast.Share
Pascal Hartig
10:39
Yeah, but compared to
Microsoft
are kind of fundamental pillar, there is to make sure that we are slowly iterating on a very mature product for a lot of the text and I wonder how much this is also just informed by the history of the different companies when you, I've watched an excellent documentary which I can highly recommend about the history of the Xbox
and Microsoft
.Share
10:60
I can add a link to the this in the show notes even though it's a documentary commissioned by
Microsoft
, it is actually be pretty open and often really harsh at the history of the console and that was already a product that obviously was very different from their core is this model prior to this which was mostly about just kind of office software and obviously the Windows operating system and back in those days those were shipped on CD-ROM's
that had to be like almost perfect.Share
11:28
You couldn't just ship a day one patch or just iterate slowly as you're rolling out new product features.
Share
11:34
Now the thing had to actually work on the day that was marked in the calendar, potentially years in advance working up to this really release date and when you look at the history of
Facebook
, it was first a website and then became a mobile app and once we got actually to the mobile app, people were shocked how slow things were because now suddenly you had a release schedule that you had to kind of adhere to and you had apps stores that needed to get your application out So that was already a culture shift and a lot of work then went into making sure that we can still keep the release cycles as small as possible.Share
12:07
So that was always this cultural impulse to reduce the cycle time as much as possible. And I'm sure that just didn't exist in
Microsoft's
DNA at least not at first.Share
Jay
12:18
Yeah, that's that's an amazing point, you know, just looking at the history of the companies, so yeah, exactly, that's kind of what I think as well, definitely support that and just thinking about that, that's why I think it was so difficult for me to jump from one side of the spectrum, which is slower iterations, stable revisions to the complete other side of the spectrum where, you know, first few weeks of boot camp, which maybe we can talk about later or some people know, first few weeks of just my onboarding time, I ramp up time, I'm pushing out code to, you know, real life teams, teams that really need changes and it's going to their production code base and at
Microsoft
, it took me months just to push my first line of code.Share
13:01
So yes, definitely a culture shock there, but thankfully because there's such a good onboarding and ramp up time here and they really support you throughout that. I wasn't worried about breaking anything too much.
Share
Pascal Hartig
13:13
I was worried a little bit, but yeah, yeah, it's that is very interesting, just kind of hearing the different timelines waiting for a month to have something in production. Whereas here where I think most people aim for having a change in production within at least the first few days that the work here, if not the first one that you actually have a laptop in your hands.
Share
13:35
So that that is a very different change and yeah, actually sometimes things break because of this, luckily not as much anymore, but there were some kind of cases where people just touched the wrong follow and then suddenly I remember one case where a search bar suddenly had a wrong like placeholder label set in it because people wanted to do this on their little developer sandbox but roller dot prod.
Share
14:01
Well once that happened, once we obviously put some systems in place to make sure that this doesn't happen again. And of course the boot camper who of course this wasn't held responsible in any way for this. No, those are processes that fail in those cases and those need to be fixed.
Share
Jay
14:15
Yeah, yeah, and that that brings a great point. I think there are a lot of valuable pros to making a mistake.
Share
14:22
So the ability for us to work fast but also fall down and learn how to pick ourselves back up is something that I definitely learned here at
Meta
more than any other company that I've worked at previously and on the other side you can say at Microsoft
, I understood the importance of slowly iterating on a product and not, you know, diving too deep into one kind of rabbit hole but really staying on course and making sure that each decision decision is well versed and stable and stuff like that.Share
Pascal Hartig
14:52
Yeah. And at times it can actually be tricky to kind of take the foot off the gas a little because there will also be projects Herod
Meta
that do require this really thoughtful, thorough investigation and it goes a bit against the grain.Share
15:08
I've been in these situations where problems were just really tricky and sometimes the best way of addressing them is actually to be just heads down understanding the problem and building up this kind of knowledge base for yourself and that can sometimes take a month and usually all people around you will be shipping code left and right and you're just sitting there reading through code and writing little diagrams and talks about the future you're trying to understand so that they can sometimes be a conflict but if you talk to the right people and set the right expectations at least like in my work that I operate and people are very supportive of this kind of deep understanding And one recent change that was made to better facilitate these requirements is that we've actually moved our performance, I go from being bi annual to just an annual event because that means now suddenly you don't need to think about, Oh my God, am I really going to spend an entire month practically doing nothing and that's already 1/6 of my performance evaluation period now it's 12.
Share
16:11
So that actually sounds a lot less intimidating suddenly.
Share
Jay
16:15
Yeah, Yeah, exactly. I kind of want to focus on, you know, one thing you said that sometimes you do have to go deep and sometimes you do have to take your time, especially for example, you're put on a very mature ml product team, you know, within
Meta
then of course the changes there will be slower moving.Share
16:32
I think that statement that you mentioned is kind of representative of what I want to say to a lot of people and even to myself back then is the companies that, you know, like
Meta, Facebook
, Google
and all, you know, these companies that usually hear about in one in one line there so big that you know, to put an overarching statement as oh, Meta's
all of Meta's
team moves fast or you know, all the Microsoft
teams maybe move forward then I'm used to or you know, all of AWS
teams, it's publicly known that maybe sometimes like you hear stories about people working really hard or working long hours there, but I would say that just because of the companies and how big they are if you compare it like to something like the news, sometimes you just hear only the bad news and and that and the bad news in reality makes up say for example, just throwing a random number out there.Share
17:21
Five or 10% of maybe the actual news that actually happened that day. There's a lot of good news, but maybe those are kind of to the side and the bad news are the ones that make the headlines similarly. I think a lot of teams here at
Meta
and a lot of teams that all these other companies, you know, sometimes not all of them move fast.Share
17:40
There are slower teams, there are teams that will fit your pacing because you have the opportunity to sit in with multiple teams and find out, you know, what your paces in terms of the development workflow and I think
Meta
does a really good job of not pushing me too much to like fit their pace, but really understand what my pace is. Like.Share
18:00
What I, I didn't really understand what my pace was until I got to
Meta
and what I'm comfortable with because back at other companies, you know, there was like a general pace that I followed, but here they really push you to define your own pace and I think that's what's great about Meta
and you know, even all the other companies that will be bound to be a team just because of the company and how large it is for you to hopefully find, you know, what resonates with you.Share
18:25
Will it resonate 100% you know, will you be perfectly happy maybe? Or maybe not, but I would definitely say that a lot of things you hear might not be representative about, you know what you what your actual experience would be if you joined the company.
Share
Pascal Hartig
18:41
So yes, you make some excellent points and actually want to draw into them a little deeper, but just to emphasize one team, say red matter, I think I've given a whole lot of autonomy. This comes to how do you want to do your planning? How do you want to work?
Share
18:55
How do you want to ship your features, which frameworks do you want to use for building your
UI
? All of those decisions come down to the team and you can make the decision as a joiner to figure out which team, which workflow, which planning model and execution model works best for you and find one.Share
19:15
This is also why I want to on this podcast specifically want to cover a breadth of different teams and people, because you won't find two people who execute in the exact same way or operate in the same way, there will always be something different.
Share
19:32
So I wanted to ask you specifically what you've seen at
Microsoft
and at Amazon
, is that also the case, there is there such a difference between different teams? So is there a bit more homogeneous e between the different teams, how they work?Share
Jay
19:48
That is an absolutely great point. I think
Meta
sometimes is a special case just because of our family of apps, you know, we might sit right next to the Instagram
team that has been doing things differently for a while, maybe now it's a little bit more standardized and then, you know, a few buildings down, maybe we'll find the WhatsApp
team that, you know, has a totally different.Share
20:08
So I think
Meta
is a little bit particular and special, but maybe that's just an extreme case of the spectrum. I would say that Microsoft
and Amazon
are actually very close to that as well within AWS
.Share
20:19
I think there's so much variety and it's not just
Amazon
AWS
, it's even looking within AWS
between the different teams like Lambda
or you go into EC2
or you go into Fargate all these teams have such different development workflows that I've seen throughout my years there and even talking to a lot of the engineers, they're all of them have their own defined experience.Share
20:42
If I ask one person on the team, you know how their experience was like, and I asked the exact there appear that they've been working, you know, on the same team for years and years, they might give me a totally different story. So again, we see that kind of sense of individualism come into play.
Share
20:55
It's kind of what you make of the experience, but back to focusing more on your question, I would say that compared to
Meta
, you might see a little bit more kind of homogenous culture there, but instead of defining it as homogeneous, I would say just less variety than normal because you know, saying saying it's less homogeneous, you know like more homogeneous, Less homogeneous, it makes me feel like one thing, whereas I think all three companies are just so different, but Meta
being a little bit, especially because of all its family of apps a little bit more different than normal.Share
Pascal Hartig
21:26
Yeah, and that is specifically a topic that we've covered here a few times, just talking to engineers from
Instagram
from WhatsApp
from Messenger
, seeing how they work, it is distinctly different.Share
21:38
And I would actually say it has moved a little closer to something of a shared core more recently and that was driven by the desire to bring the apps closer together for this.
Share
21:49
You also need to bring the cultures of the different apps a little closer together, You can't just get away with saying like, oh yeah, we're just gonna build the same features and make them somehow interoperable without also making potentially some sacrifices in how you work, because now suddenly it might make sense for all of them to work in one source code repository and share the same code patterns that might previously be something where you took a lot of pride, like we're never going to use an external third party library and now suddenly that's part of the stack.
Share
22:18
Sorry?
Share
Jay
22:19
Yeah, yeah, that that's exactly a great point. I feel like, you know, you can try to merge things technically, but until you merge things culturally, if you try to merge things, maybe it'll work in the beginning, but long term wise, can it scale, can all these different even in code?
Share
22:35
I feel like there's a lot of culture, there can different code bases merge together when they're not culturally together. I wouldn't say so, especially for a kind of our scale and a company our size. So I think that's a great point.
Share
Pascal Hartig
22:48
Yeah. And I've not talked to anybody here on the podcast, works in hardware development, but as we were talking in the beginning about
Microsoft's
way of shipping software back in the days on CD-ROM's
, shipping hardware is actually kind of similar because there's also release date in the calendar and a lot of logistics lined up to support this day and you can't just decide a week after launch. Oh yeah, actually, I wish we could have upgraded the CPU
a little let's send out a patch for this, that's not possible.Share
23:17
So there will be teams here who will operate on very similar models that have a lot less room for error than me working on my dev tool that goes out on a weekly release and well, if there's a regression in there, we can still fix the next week.
Share
Jay
23:34
Yeah, exactly.
Share
Pascal Hartig
23:36
So you also talked a bit about the external perceptions of
Meta
. I'm curious if there was something that kind of stood out to you that you were expecting when you were joining and that was actually very different that you realized after you joined.Share
Jay
23:51
One of the hardest things for me was the culture here kind of biggest conflict for me in deciding whether to join or not.
Share
23:58
I've heard lots of cultural things, you know, there's also public perception especially I joined around January 2022 but years before then I've been considering metaphor a long, long time and throughout those years I've heard many things, both good and bad in reality I think for me as an engineer, so more on the technical side like what barred me from joining was I heard it was very, again pacing related, but I heard it was very promotion driven and if you do not move as fast you will be left behind.
Share
24:35
And you know those kinds of things you might have heard as well, especially software engineers and other engineers, they might kind of have in their mind when they first joined. And that was I would say like if I had like five reasons for me like you know, to reconsider joining or stuff like that.
Share
24:52
That reason in itself out waited all the other four, even if I combine them together because I was definitely worried about being left behind, I've never wanted to be left behind even when I was younger. So I was thinking, oh maybe you know, it's not kind of the culture for me, maybe I'm a slower kind of person.
Share
25:10
I like to really focus on the details and stuff like that. Sometimes I go in rabbit holes in the code base and you know, step through each met and then three hours later I realized I shouldn't have done that and make better use of my time.
Share
25:22
But things like that is kind of why I was worried to join because I was really, my whole kind of development work for for me is kind of flexibility, being able to do, being things that I want and being able to be curious in reality when I ended up joining and I was pre allocated, but hearing how boot camp goes, seeing how boot camp goes right, we should just quickly explain pre allocated in this case means that instead of choosing a team after you graduate boot camp, where it's normally the time for people then to sit with different teams and figure out which one they want to join in your case, you actually knew which team to join before you signed.
Share
Pascal Hartig
25:59
Your offer, I suppose.
Share
Jay
25:59
Yeah, thanks for that. I would say that being pre allocated or being able to know your team before you join is a little bit less common than, you know, joining without a team and going through boot camp.
Share
26:11
But yeah, either way and especially because I was pre allocated, I was worried that again, I wouldn't find a team that's right for me and this kind of goes back in a circle around to the point I made, I realized that a company is so big that despite the overarching culture, the dramatic points that you see a company is so big that there, especially a company like
Meta
, there are bound to be teams that will fit you like that will fit, you know what you're looking for and what you kind of envision yourself as an engineer.Share
26:44
Again, I don't think it will be perfect, but I still think that for example, if you had 20 things that you wanted, I would say, you know a lot of the things that you want, you can find in a team by sitting with them in boot camp or even being pre allocated, you get to have the opportunity to talk to HMS and understand, you know what you're really gonna be doing in your roles and responsibilities within the team.
Share
27:07
So I guess really for a focal point of all of this is clarity. Being able to understand what you're going to, you're going to be doing is just a huge integral point of of that.
Share
Pascal Hartig
27:19
Yeah, that is super interesting because it resonates a lot with me. My main concern before joining I think was quite similar and that I had the fear that quality wasn't valued back then at
Facebook
.Share
27:35
So specifically parts that I was always very interested in like performance and looking specifically at mobile apps in this case like scroll performance and reaction times and all of this. And it seemed to me like nobody really cared. I don't really know where this came from but it seemed to be a pretty common preconception of what I was here.
Share
27:55
And then I started just talking to a bunch of engineers who actually worked here and I learned that not only is this not seen as a distraction if you work on this night, there were entire teams working on this were metrics set up to improve these kind of things and rose to the level of the company level priority. Where was like it doesn't matter if we don't ship new features, we need to get the performance under control.
Share
28:19
And to me that was a real game changer that when I saw this doesn't just apply to now adding more hacks on top of hacks to making things faster.
Share
28:26
But no making sure that this works on an infrastructure level that we build frameworks that let people fall into this pit of success as they like to say here where entire new declarative models where build so you could write your software even if somebody who doesn't have all the performance background and it would be optimized for everybody.
Share
28:46
And that just changed everything for me because I could see not only was I wrong in thinking that this wasn't a priority. No, it was like a super high priority and the entire teams around it.
Share
Jay
28:57
Yeah, I would say a lot of the things that you might see online, like either
Reddit
or like you look at other social media sites that are saying, oh I wish, you know, Meta
had this in their tools or you know, I wish they had this in their API
or maybe their workflow was better or even in the hiring pipeline, I wish this hiring website was better.Share
29:17
A lot of the things by the time you hear it, I would say that someone at
Meta
has already thought it or might be even working on it.Share
29:26
I can I cannot say the same for can't say for all the things that, you know, you hear online, but I would say that if it's something for you to hear daily, I would, in my opinion, even in
AWS,
Microsoft
and the companies that I worked for that we probably already, you know, there's someone probably already on it, whether it's in their mind or they might be working on it.Share
29:47
So yeah, definitely agree with you on that point there, sometimes it might not seem like, you know, just because of how big of a company there is, there's a lot of things working in the background that we might not be able to see until we actually join, right? So yeah, just great point there.
Share
Pascal Hartig
30:03
And the other part I wanted to ask you about because I actually have a few colleagues who came over from Amazon for instance and that to me is one of the reasons why I think this discussion is super valuable.
Share
30:13
There's a lot of exchange and that goes on the direction or there are definitely people who joined
Microsoft
and Amazon
or Twitter
or whatever else they might be out there from Meta
, but also the other way around And one thing I've seen is that a lot of people joining from Amazon
joining my team in particular because as we've discussed, this might vary from team to team.Share
30:34
They were surprised, not only how quickly we land gifts. So that's our model of like pull requests but how we do this and that is something that I personally became to appreciate a lot more as I continued working here and that is on my team, we try to keep them always as small as possible.
Share
30:50
So like make sure that you can review a diff within ideally less than a minute. We all kind of know that once you need to review some change requests that is longer than 500 lines of code, Your eyes will just gloss over. It's like, yeah, it looks good to me too.
Share
31:06
So let's hit accept and see if something goes wrong. I trust the test suite but it's much easier to spot an obvious bug when all you look at at is maybe 10 lines of code. So okay, before I go on here, is that something that you've also seen or is that something that might only apply to my particular corner?
Share
Jay
31:24
Yeah. You know, and I just kept thinking about one of my 1st 23 gifts at
AWS
and it was like 5000 lines.Share
31:33
So I think like 10 to 12 pages, so you know, Yeah, I think it might be our corner now, but I still still agree with you that I think fast iteration, smaller gifts here is a really big point, but at the same time, I know that around the time I was leaving
Amazon
maybe there are a lot of engineers that were pushing for it, but we really, really wanted to focus better on that aspect. We didn't really want 20 page tips anymore.Share
31:59
We wanted those, you know, few liners and faster iterations instead just for all the myriad of reasons we know, which is like, you know slower, a smaller blast radius and faster, faster pipeline workflows and stuff like that.
Share
32:11
But you know, one tangential point to that is I think We were kind of mentioning it but
Meta
has definitively, in my opinion, the best development support for engineers. I feel like a lot of the things we do is like quote unquote survivalists.Share
32:28
So we don't have to worry a lot about things like maybe how we deploy certain lines of code or you know how we emerge in certain pull requests, whereas in other companies there were almost 20, of my development so that's just gone here at
Meta
.Share
32:42
It's like almost server list like as in like there's multiple teams internally that will help with that. So I think yeah, I just think that it's amazing being able to spend more time on kind of the actual product rather than focusing more on the infra behind how to deploy and things like that.
Share
Pascal Hartig
32:59
Yeah. And one thing that she certainly can also observe from the outside is that quite recently we've made some announcements about products that we are no longer pursuing or maybe just skipping and iteration and focusing on the next part. So that means a lot of projects right now are being deprived critized as we are trying to shift on the most important things.
Share
33:18
What didn't get prioritized was developer support.
Share
33:22
It is actually something that still explicitly being called out at something where we need to make drastic investments And the reason is that one of the ways how you can stay nimble is by ensuring that teams, especially small teams with the limited resources can still move quickly and iterate on things and ship stuff and you can't do this if you now say like, well I don't know but this kind of team, I don't see how they've contributed to the revenue top line numbers.
Share
33:48
So let's get rid of them.
Share
33:50
That's not how you do this, this might actually work in the short term. But in the long, medium to long run, you will definitely shoot yourself in the foot and people will start limping and you won't get anywhere.
Share
33:60
Yeah, just very quick on the small difference part because to me this obviously being a very specific aspect of how we work and yet I think there's actually some sort of broader principle in there where you can kind of see how we operate.
Share
34:17
And the reason why I like this is so one of the ways you can ship a lot of code quickly that might not actually add up to a full on feature is by gating it somehow behind the feature switch and what my team in particular does quite, we ship things behind a gatekeeper, a feature switch that we can open up later and quite often what you'll find is that behind this gatekeeper, this thing is completely broken.
Share
34:39
It doesn't work yet, but we can trust engineers to actually work iterative lee towards an end goal by first writing up a plan how they will get there and then we can just focus on the small lines that will ultimately get to something that approaches readiness.
Share
34:56
And that also means that in the meantime as we're building up towards a complete product, we can already do some little dog food and can do some testing, open it up to a special group of people who we trust won't complain all this, all that loudly as you do this. And to me that was actually kind of mind blowing how you can build software like this.
Share
35:14
That's the exact opposite model of building up a 3000 line diff that then somebody will need to dedicate an afternoon to, to review and probably still miss a bunch of big bugs because it's just too much to digest in one session. So yeah, to me that was a very foundational shift in how I would approach building software, but a very meaningful one.
Share
Jay
35:38
Yeah, definitely agree. I do see kind of that gate in a lot of other companies, but I would say here, they're very less hesitant to actually use that gate. So here like they have few to three lines of code and they don't mind putting it behind a gate. Whereas in other companies I spent, you know, we would put thousands and thousands of lines, the whole feature behind the gate once it's actually done.
Share
36:03
Yeah, I think that's great here that because we have faster iterations, we don't mind putting very small iterations behind the gate, which means in the end that there's better quality, we don't want to show things to people who might not want to see it and we want to show things to people as we scale up words that feature or that impact.
Share
Pascal Hartig
36:18
So yeah, just one thing I also noticed and again, this only works because we have teams that explicitly focus on building these tools, making sure not only that they are fast and reliable, but also very importantly that we have ways of cleaning this stuff up when it's no longer needed.
Share
36:38
So quite often I will just kind of get a body that's sensitive to me to review that just delete some old features which that hasn't really seen any other value than 100% for a few months. It's like, oh yeah, actually I don't need this anymore, let's get rid of it.
Share
36:52
And that is also a very important part because what I've seen in previous companies that have worked in is that we had tens of thousands of active features which is somewhere that led not only to sometimes broken experiences because he had this weird combinatorial explosion of different manifestations of a home screen that somebody could find themselves and it's like you don't have video support but you have like livestream support or something like this because there's an old hold out and that then breaks the entire, so all of these things can happen and we have a lot of investments here in processes and bots and tools to make sure that you hopefully don't end up in that situation.
Share
Jay
37:32
Yeah. And just thinking one example and which kind of goes along with the thing we mentioned like back, which is that I am a search bar kind of thing. I remember my first few weeks.
Share
Pascal Hartig
37:41
I quickly mentioned that is the label that we put into the search bar. I didn't mention it by name. So somebody shift a change that made the top search bar on Facebook.com. Say I'm a search bar and I was out there for a few minutes before somebody caught it and reverted the change. Okay, sorry, now back to you.
Share
Jay
37:59
Yeah, Yeah. And similarly my first few weeks as a new grad, I actually pushed a string that said like, oh, I'm a cool test string into the
AWS
like main site. So you went to the AWS
main site, you try to request some cloud, you know, hardware capacity stuff.Share
38:18
You'll see like I'm a cool string just on the front page and you know, that kind of just reminds me, reminds me of that if, you know, if I had, if I had a gate thing, you know to keep my code behind, especially as a new Grad or you know, if if I had some kind of more monitoring somewhere, whether it's a gate or something else, I would have definitely caught that.
Share
38:36
But I guess that's just one example in
AWS
. There are also fast iterations as well and there are mistakes like that. But at the same time after that I understood the importance of like multiple integration testing and you know how to set up certain canaries and all this like low level stuff just from one mistake.Share
38:54
So again, whether it's
Meta
, whether it's AWS
, whether it's Microsoft
, I think making mistakes throughout all those companies kind of made me learn the most and it's not to say please make mistakes, but in reality when you make a mistake, what more can you take out from it? What more can you learn? And yeah.Share
Pascal Hartig
39:13
Such a good point. And I would like to actually dedicate an entire episode just about our self review process because incidents here happen on a daily basis and we do this very liberally because whenever you create what we call here sf so that's like a full an incident report. You We'll have an entire tool that helps you actually understand. How did you get to this point?
Share
39:35
What were the contributing factors? What was the trigger? So used to be called the root cause for something but often by really spending some time and digging into a problem, you understand not who's the 40 human behind, it that is hardly ever the correct outcome of an analysis like this. But what were the processes behind it?
Share
39:55
What could we do better going forward where some kind of missing automation, better tests, better tools and that's normally how we approach it. So I've just recently had we had something in flipper, the debugging tool that I have where somebody else broke part of our connection mechanism and that was just a completely innocuous change that broke something and it took us quite a while to understand this.
Share
40:18
I retroactively then created a set for us just to make sure we can build some better automation for it to prevent this from happening again, so that we don't rely on every little line of code like this, that might look completely innocent to be mentally tested and studied by somebody who knows this, but that we have automation in place to catch these kind of things.
Share
Jay
40:43
Yeah, yeah. And just talking about kind of automation, development workflows, engineering workflows here, I met a but also different companies. I think one big reason or like at least one extra bonus that I thought was, oh, while I'm switching companies, I get to learn about the variety of different workflows and you know, what is it like a
Meta
workflow?Share
41:03
What's on
Microsoft
workflow? And in reality, I definitely did learn understand the differences and I got to learn so much from joining these companies. But I would also say looking back, I thought again, we're coming back to that kind of, you know, homogeneous structure. I thought that I said Microsoft
in the sense that, okay, that's the one entity.Share
41:23
But in reality, just like how we have the family of apps, you know,
Microsoft
has their own family of things that have like different heart, there's Xbox
team, there's your team and I realized that I didn't really, you know, that wasn't actually an extra bonus because even if I switched a team in different organs, different divisions within whatever company, it'd be a totally new development workflow, new engineers, you know, new product.Share
41:47
And I do have to say yes, there were benefits to being able to join different companies, understand how they do things. But I would also say in reality staying even within
AWS
, which is like my first company and switching teams there, I would have learned just as much about a different product there.Share
42:06
I think that's one kind of point, I think in retrospective. But yeah, it's not to say like, oh, because I switched, I know so many different workflows now, but as in the world is so big and the company is so big that no matter what, where I went really, even if it's within the company, I would have learned a lot.
Share
Pascal Hartig
42:24
Absolutely. And we've had an entire episode here, just about internal mobility with Sash who just shows a few different areas how completely differently people work here.
Share
42:35
So yeah, I mean, please don't ever get bored here and instead look around for maybe a different team managers will be actually helping you in that case to make the transition as smooth as possible. My team is actually a great example of this because we've had a ton of people who come from various different parts of the company and then also tend to sometimes leave and go to a different place.
Share
Jay
42:57
Yeah, I do have to say one quick note about that is I think other, I feel like compared to other companies
Meta
here really even sometimes promotes you to look, you know, within the company to another team. If you aren't happy with your role, sometimes it's kind of on the hush.Share
43:12
Oh maybe I'm looking internally to switch back in my previous companies. That's kind of sometimes what happened. I had no idea it was gonna happen and suddenly 23 engineers would leave to another team which is fine.
Share
43:22
But here, I feel like there's much more transparency if I knew that an engineer wasn't happy with their role, you know, they tell me, oh, I was kind of looking at this team and that is an anecdote, but at the same time, I guess that's also a representation of how much clarity there is and how much of a culture, I guess difference in culture there is here where you know, there's like specific months where you can like try look and feel the development workflows of another another team and understand how they do things and you know, if it matches you better.
Share
43:50
A lot of times I hear managers promote that they want you to really be happy with your role at the company, whether it's on their team or someone else's team.
Share
Pascal Hartig
43:59
So exactly, my manager actually asked me quite recently if I would be interested in taking on hacker month somewhere else and that was not trying to tell me that she wants to get rid of me, but just because I have been on that or have been on the team now for quite a long time and sometimes just getting a bunch of fresh ideas and changing up things a little can be really interesting and so the second month model here means that you work with a different team normally for a month can be a bit short, it can be a bit longer so it's not that rigid in its description and then by the end of it you can choose, do you want to maybe join the new team?
Share
44:32
Do you want to remain with the old one? And that's completely up to you in that case.
Share
Jay
44:38
Yeah, which is great in the sense that I feel like a good balance of being specialized in the area, being comfortable understanding your expertise but also being thrown in a new pond of new information and a new product.
Share
44:50
You just learned so much through both of those. So the fact that at
Meta
, they like to promote both, they would love for you to be really good at a product but they would also love for you to understand your interest more and define the kind of how you envision yourself as an engineer at the company.Share
Pascal Hartig
45:05
So being able to have that duality here and also integrate that is just you know something I haven't seen any any other company, this might be a good night to wrap things up on Jay, thank you so much for this really exploring discussion about different company methodologies and cultures. Thanks so much for joining me.
Share
Jay
45:25
Of course. Thank you for having me. It was, it was great speaking to you.
Share
Pascal Hartig
45:28
Amazing. Thank you.
Share
45:31
And that was my interview with Jay. I know that we have some listeners from those companies that we talked about and I'm super curious if what we discussed resonates with you, so we might be off for the rest of the summer but we still want to hear from you. I'm @passy on
Twitter
when the door open and the podcast is at Meta
Tech Podcast on Twitter
and on Instagram
.Share
45:49
If you would like to get a first hand experience on how to break up your feature into many teeny tiny dips check out medical race dot com and that's it for another episode of the
Meta
tech podcast.Share
45:60
Until next time.
Share
46:10
I hope my
Macbook
is not going to die here. I'm just going to pause because everything is is getting, if I drop out suddenly then I will hopefully reconnect shortly after.Share
Add podcast
🇮🇹 Made with love & passion in Italy. 🌎 Enjoyed everywhere
Build n. 1.38.1
Pascal Hartig
Jay