Srinivas Narayanan ex VP Engineering/Head of AI Applied Research Meta/Facebook chats with Amit Somani, Managing Partner Prime Venture Partners.

Listen to the podcast to learn about

02:10 - True Meaning of “Move fast and Break Things”
08:00 - When & How to Reward Failure
15:00 - Goals, Accountability & Shipping Velocity
25:30 - Dealing with Failure When You Haven't Failed Before
27:00 - “Hiring is an engineering problem, not a recruiting problem”

Read the complete transcript below

Amit Somani 01:00

Welcome to the Prime Venture partners podcast. I’m your host Amit Somani. And I have with me a friend and a former colleague Srinivas Narayanan, who was a VP engineering at META, formerly Facebook, where he spent the last 13, 14 years leading various engineering organizations in AI, AR/VR and various consumer products. He is now going to be an advisor to Prime Venture Partners. Welcome to the show Srinivas.

Srinivas Narayanan 01:25

Thanks, Amit. I’m very excited to be here and talk with you about engineering culture.

Amit Somani 01:30

Absolutely. Thank you for introducing the topic and I can’t think of a better person and we have not had an engineering leader on our podcast surprisingly for a couple of years now. So really looking forward to exploring this. Let me just go right into it Srinivas, which is one of the things that Mark Zuckerberg is famous for talking about is “move fast and break things”. And I know you did a recent talk for us where you talk about the difference between audacity and fearlessness and recklessness. So can you elaborate for our listeners, many of who are early stage entrepreneurs? What does that really mean in practice?

Srinivas Narayanan 02:00

Yeah, Facebook is famously known for this, but I think it’s sometimes also miss interpreted. So let’s break it into two parts. One is the move fast piece. The break things piece, I don’t think we use it anymore, but I’ll talk about why we used it in the early days too. The move fast is really about clearing all hurdles and really optimizing for having impact and not getting bogged down by bureaucracy or just lack of quick decision making. It’s really about focus on what’s the best way to have impact and sometimes it gets interpreted as really short term impact, which is a little bit unfortunate, but the real principle behind moving fast is just really, clear all hurdles run as fast as you can, and don’t get bogged down by bureaucracy and other things. I think that’s it and it’s really helped the company quite a bit.

And there’s always a focus on how we have an impact and what’s the most useful and the biggest impactful thing we can do at any point in time. The break things piece, I think it was really meant to inspire fearlessness and not recklessness and what I mean by that is you want to have an engineering culture where people are encouraged to take big risks and they’re not afraid to fail and that’s really what it is meant to. Otherwise you end up with cultures that I think get too conservative. They’re in a rut, they don’t really try to innovate and they don’t try to really think big, but whenever you think big, there’s always a huge risk of failure, right?

And I think that’s okay. I think you have to accept that risk and also have to find ways to reward people who take the risk, but fail and that’s the harder part. It’s easy to say that we want to encourage people to think big and be bold and be fearless. But with that comes a lot of risk and as long as you are working on things to reward people for taking the risk, that’s the sort of culture that you want, encouraging people to be fearless.

Amit Somani 03:50

Great. I have a lot of follow on questions. One is on this notion of clear all hurdles. Now, obviously when you have such a large company as META/Facebook, you have hundreds, if not thousands of engineers in various teams, so doesn’t it become completely chaotic because everybody has five hurdles to clear. And how do you then prioritize at a company level or perhaps even at an organization level, let’s say in your AR/VR team or your AI team.

Srinivas Narayanan 04:15

Yeah, no, I think one thing I like about Facebook, what we do well is very clear goals. So every six months I would say all teams at all levels in the organization set very clear goals on what they want to accomplish. And those goals are communicated, I think they’re fairly transparent, everybody knows what your goals are. And that allows, I think, people to march in unison. So once you know what your goals are, and you don’t know not just what your goals are, you also know what your teams you collaborate with, what their goals are. And I think there is a common energy that all these goals ladder up towards something that even at Mark’s level, that they’re not 50 completely random goals, but they all add towards something bigger at a company level and I think that structure is really important.

You want to all march in unison and once that structure is set and every six months, all these goals are reviewed that allows people to go together in sync. And that allows people to help each other and that allows people to look out for each other because you want to be something part of bigger than what yourself is. And I think having awareness of what the entire company is trying to do allows people to do that. And also what’s another nice thing about knowing what the highest level goals are is sometimes you realize that holy shit, I may be marching in the wrong direction because I thought this is my goal and I’m marching here. But when you hear all the other things that are going on in the company, you might actually realize that, Maybe I should adjust myself because doing X is probably better than doing Y . So I think it also goes back to transparency, which is having a really open, transparent culture about what is important for the company. I think it’s a fantastic thing.

Amit Somani 05:50

Yeah. So I want to ask about, let’s say particularly in an engineering context, I’m a bright engineer at Facebook or one of the startups that are tuned in and listening in, or even an engineering manager, but not a co-founder. The engineering risk I want to take, or the engineering audacity, I want to show may or may not necessarily align with the business risk or the market risk or the consumer risk or whatever, right? How do you align that? The company is saying, look, I want to serve all customers and be bold and dominate the Metaverse. But now I’m like my engineer doing something on whatever. So is there any thought on that?

Srinivas Narayanan 06:20

Yeah, I mean, it’s a great question, but I think my answer to this would be, you have to find a way to articulate why what you’re trying to do matters for the company. I think that’s important at all levels in the organization, whether you’re a new engineer, whether you are an experienced engineer, a manager, you can’t isolate yourself and say, “I want to do what I want to do.” That’s not helpful for anybody.

You have to find a way to say, “Hey, here’s what I want to do. And here is why it’s important for the business.” And it can be an engineering goal. You may be trying to do something that enables all the other engineers around you to move faster by building better tools or better platforms or whatever. That’s a great thing for the company, but you have to be able to articulate it that way.

And that’s I think really important. When everybody understands why you are doing something, I think that’s also tolerance for that. Like, “Hey, maybe we understand it’s risky, but we understand the upside if it goes really well.” And automatically, I think you get a little bit more leeway for failing. Whereas if you do something, but you don’t try to articulate why it’s important, you might really create a thought around, “Oh, this person is just doing whatever they want to do.” You don’t want that. I think you really want to try to articulate why it’s important.

Amit Somani 07:30

Wonderful. Let’s talk about failure because that is really the other side of this coin. You can be very audacious and fearless and align with the company’s overall mission, but yet there is this fear of survival and you want to not be the one to rock the boat too much and so forth. So can you talk about a few examples at, at all levels of the org of how do you reward failure or encourage failure or whatever?

Srinivas Narayanan 08:00

Sure. Yeah, I think that’s sort of… I’ll give you maybe one early example when I was… This was one of my very first projects at Facebook and we were launching user names and it’s like, you go to Facebook.com/amit. You go to your profile page, we didn’t used to have that for people. So it was one of the first projects I built, it was just a couple of people. One of the funny things about that project was we had, I think quite a number of people, I forget maybe 250 million users or something like that at that time. And we had no idea how many people were going to show up if we launched something. If you’re going to say, “Hey, come and claim your username on Facebook.” We had no idea how many people were going to come. Of course we thought a lot of people would come, but… And the site could have crashed if too many people showed up.

We just weren’t prepared to have the extra resources to support a lot more people coming in and logging into the site. And when we were planning for how to roll this out, we were talking with Mark and I remember telling him that, “Hey, there’s a pretty good chance that we might bring the whole site down if we do this.” And he just looked at it and was like, “Yeah, I’m willing to take that risk.” That was pretty amazing to hear that when in my early days, and I don’t think he was asking me to be reckless. And I think what he was saying is, “Hey, I think there is a certain amount of risk I’m willing to tolerate here as long as you do the planning and the preparation and all that.” I think the risk of this happening is you maybe there, but he’s willing to do it and what he’s getting in return is a faster launch, right?

I could have spent a lot more time being… Dotting Is, crossing Ts and being everything is perfect and it would have taken a few more months, but he’s like, “Yeah, I don’t think that risk is worth it. I would rather take the risk of something going down, but if you’re going to get this in front of people, a couple of months earlier, I’m willing to take that.” I think that’s a very informed decision making, but he did that on the spot. And I think that was like… It was pretty awesome to see that and we launched it and thankfully nothing happened. Nothing bad happened and we planned quite a bit actually, but we did it pretty fast and it was great. That’s one example. I’ve seen other examples, but really, for example, we were… The team was building two different versions of how to write and compile PHP.

And we didn’t know which one was going to work and both approaches sounded reasonable. And one of them, eventually we knew was not going to work and only one of them was going to succeed, but we didn’t know which one was going to work and which one was going to succeed. So we let two teams actually run in parallel, both extremely aware of what the other team was doing because ultimately one had to succeed. And then I think after a while people realized which track was going to go better, but the team that didn’t work out was rewarded because that risk was absolutely important for the company to take. He could have easily said, “Oh, your approach didn’t work and therefore you’re not going to get rewarded,” but we did exactly the opposite. Failure was celebrated because there was so much learning along the way and it really paved the path for the other approach to succeed.

So I think you have to do this in a thoughtful way where there is good reason for taking the risk. The other thing I would say is communication is extremely important for these types of projects, right? You want to separate out failure due to being bold and taking something that’s inherently risky versus failure due to just pure execution. We don’t want poor execution and I don’t think you want to tolerate that and I think… But inherently risky things need to be tolerated and for that, you need really, really good communication. You need people who communicate, why you’re doing it. What is the risk? What are the milestones? Am I going on the right path? Should I pivot? Should I stop the project? And constant communication. What lessons did I learn? Now all these things are really important and I think I would put a lot more emphasis on great communication for projects.

Amit Somani 11:40

Yeah. I think you’ve emphasized this and we’ll come back to this when we talk a little bit about hiring, but what this tells me, and I think you’ve shared this earlier as well, that engineers have a lot more degrees of freedom and a lot more freedom in general in a culture like that. But obviously that has to be balanced with some accountability and responsibility. So can you talk about some of those at least non-conventional things or how do you balance those two?

Srinivas Narayanan 12:05

Yeah. No, I think this is one of the things I love about Facebook culture and I think it was fantastic to see it in the early days when I was there and surprisingly, it has helped to a very large extent, even as the company scaled over the years. Eventually the company is not, I would say, very process driven, right? Engineers and people in general have enormous amounts of freedom to accomplish their goals. What people are held accountable to is, like I said, every six months people plan and you communicate what your goals are. Once you communicate what your goals are, you have a lot of freedom on how you want to achieve them and how you want to achieve your goals. Nobody’s going to come and tell you what to do or how to achieve them as long as you achieve them.

So that gives you an enormous amount of freedom to achieve what you want to do, to do what you want. But with that comes responsibility and the accountability that “Hey, I’m committing to these goals, right?” And of course if things change, you can of course change things, but there is a certain amount of commitment and accountability that comes with the goals, but a lot of freedom in the… In how you accomplish that. And I think that creates a certain bottom up culture and a lot of ownership over things and people feel incredibly excited because as they have more ownership over their ideas, they have the freedom to change things, there’s nobody telling them what to do.

In fact, they are telling, “Here’s the high-level framework and here’s what I’m going to achieve and how I’m going to do it.” So I think that creates a fantastic culture. And often I think decision making happens at the right level. So in many other organizations, I think one principle for me is to also make sure that you are pushing decision making at the right level. The people who have the most knowledge about certain things should be the ones who are empowered to make the decisions about them.

Amit Somani 13:45

So the question that is coming into my mind is a lot of the classic engineering organizations, dare I say, or classic org companies you also want predictability and reliability and repeatability. So I’m just trying to figure out beyond the six month goal alignment, how do you get that on a regular basis right? Because you’re checking in code, things are going live, there’s a hundred experiments or a thousand experiments running every day. So how does this not borderline into, again, chaos?

Srinivas Narayanan 14:15

Maybe there’s a few different things you’re asking, right? One is predictability. I mean the predictability, I’m not sure that’s that useful. Predictability in what, right. If you’re going to commit to your goals and you can set goals at whatever granularity you want. You can set it quarterly, you can set it at a half yearly, if you’re able to achieve this and as long as they’re big, they’re bold, they’re audacious. And if you look back three months and say, “Hey, yeah, we achieved this and we feel really good about it.” It doesn’t matter whether you got done in one week or half a week or this or that. I think instead of having predictability at day to day basis, I think what you are getting is audacious goals at maybe a quarterly level or at a half level.

So I value that a lot more, more than the day to day predictability of is this specific thing, this task getting done in one week versus that? I think what I find is that thinking about it in a higher level, elevates the entire organization, right? You’re not getting stuck in with the mundane details of this small thing getting done and is that person checking and all that. You empower all the people in your team to know how to do it and you don’t worry about it and you elevate your thinking and like, are we accomplishing something higher than all of… At a higher level?

Amit Somani 15:25

Let me interrupt, right? Because, see there is engineering, but you’re also collaborating with other teams, could be legal, could be PR, could be product management, could be marketing. So they’re also dependent on you. They’re not writing code, they’re not shipping code. Now of course you could say, “Hey, look, we’ll launch user names in July of 2022 and that’s all there is to it, right?” But you’re building up to that. So maybe talk a little bit about cross org collaboration in this context.

Srinivas Narayanan 15:55

Yeah. So when I talk about goal setting, it’s actually important to realize that those are not just engineering goals, right? Those are goals for the entire team. And those are very cross-functional teams. They have product managers, designers, user researchers, analytics, all other functions. And so that’s the team that is collectively committing towards those goals and all functions are actually coming together to accomplish them. It’s not just one function saying this is the goal and all of that and that’s what allows everybody to move together.

Amit Somani 16:25

Great. Maybe talk a little bit about what are some of the tools, and I know you said not a very process oriented company, but best principles beyond goal setting, like next level down that help, right? Either at an engineering level or OKRs or whatever, right? Saying these are specific tools that you would love to have if you went to a different company or started a new one right? Saying these things I definitely want to have with me.

Srinivas Narayanan 16:45

Like I said I think the process and tools are like… I wouldn’t say they’re that standardized, the process is sort of up to each person. The things that I think help us quite a bit is continuous pushes, right? Code is released to production all the time. I think that’s an absolutely amazing thing to have. So which is the train is leaving all the time and you just figure out which train you want to get on. And so that enables the move fast culture quite a bit, which is you commit something into your code base, it’s going live. And of course you can put gatekeepers and things that make sure that if it’s not ready for public consumption, you can prevent all that. But the code is still checked in and it’s going live. And I think that’s an amazing culture that I think you should… I would encourage people to have, which is just constant velocity of shipping all the time.

Other thing, I think it’s a subtle one, but what enables this is to break your work into small chunks, small shippable chunks. Don’t take, if like there’s a feature that’s going to take… And it doesn’t mean every feature is going to take only one day to finish, right? Somethings are going to take years or something they’re going to take maybe months to do, break it into meaningful chunks so that you are always building something towards and incrementally building up to something. That allows the constant velocity and you’re always committing something and I think that’s a very, very helpful and healthy thing to do.

So that’s on the quality side. I mean, good review culture. I think people always look for code reviews and really constructive feedback and I think that’s a part of the culture. I think that sort of helps set the quality bar. What else would I do? I mean, like I said, it’s not process driven, but people have, sometimes have monthly goals, sometimes people have weekly goals, they have ad hoc scrums, et cetera. So those are all just up to each team and figure out whatever makes… Works for them.

Amit Somani 18:30

How about tools, right? I know you have mentioned somewhere else. I saw that there’s a big culture of inventing tools or writing things up, but again, trying to translate it to younger startups, they may not have that luxury. So either tools that you would recommend or any guiding principles on how they should think about inventing their own tools so to speak?

Srinivas Narayanan 18:55

I mean the classic engineering tools, I don’t think I need to specify things, I think people have talked about it publicly from code reviews to task management, whatever it is. I don’t think there’s any magic there. The thing that, culturally, that I think is really helpful for us has been one that always looks at how we can improve our engineering velocity, right? What is causing people to move slowly? And you want to always be thinking about, there’s always something that could go faster. There is something that people are doing in a manual way that can be improved and I think that culture about constantly thinking about how can I improve the velocity overall for engineers and building systems or tools to help them in those I think have been incredibly helpful. So I always look at what’s slowing you down and what can I do to invest in improving the overall productivity of people.

I think that mindset is really important more than anything else. And I think that each company is different and I think that’s one thing about engineering culture, right? Which is it’s the quote from Peter Thiel that comes to my mind, right? “All happy companies are different and all failed companies are the same.” So all happy companies are different and I think the set of tools that one company needs is going to be different from what somebody else needs, but this approach towards always thinking about how can I improve productivity I think that’s the mindset I encourage everybody to have.

Amit Somani 20:15

I think that’s lovely because I think that just breaks through all the clutter in terms of prioritization, trade offs, et cetera, right? Which is optimizing for velocity and speed of shipping things. That’s it. So it just becomes simpler.

That leads me to my next question, that you have a strong mindset in engineering of, “Always be improving,” right? Kaizen. Can you talk a little bit about that at again, an org level, individual level?

Srinivas Narayanan 20:45

Yeah. I mean, I think this is… There is a culture of being self-critical and always improving that I think is really, really important both as an individual and I think also as an organization. I think what personally for me also, that’s one of the things I’ve learned, which is you have to be your toughest critic. If other people are starting to point out things in you, that’s a good learning experience for you. If you are critical about yourself, you’re automatically setting a bar that’s high enough. And I think it enables the entire organization to have a really, really high bar. So I think this approach of… Thought of being self critical, always being improving enables everybody to think that, “Hey, things always can be better, no matter how well you’re doing things can always be better.” Right?

And I think that allows… What it accomplishes I think is that it just raises the ambition for everybody. Even if you think you’re doing well, if you feel like you’re doing better, you’re constantly upping your game, right? And I think that the constant improvement process and improvement cycle has been… It’s been really critical for the culture, and I think, like I said, it permeates everything that we do. We talked about investing in tools to make engineering productivity better. That also comes from the same mindset that things can always be better. But even another thing, like I said, one in goal setting, right? People are encouraged to have goals that they meet only half the time or 50% of the goals. That’s the classic saying in Facebook, which is that you set goals so that you meet 50% of them. And that sounds odd at first, why would I have goals and I only hit half of them, right?

But again, the intent there is that you’re encouraging people to be bold enough that if you’re hitting all your goals, you’re not being ambitious enough, right? You have to fail a little bit to make sure that you actually said ambitious goals. And again, if you’re hitting all the goals, then there’s always… People look at you and say, “Maybe you should be more ambitious next time.” So this constant, things should be better, this mindset has been… Is really important. And I think that leads down into another one, which is also being bold. And we talked about being bold and fearless, but there’s also boldness in the ambition of what you want to accomplish, right? I think one of the things that stood out for me is when I joined Facebook had probably one and a hundred million users or something like that, but right from day one, there was always this, we want to have everybody in the world be on Facebook.

That was the ambition, right? And that was clear. And for an early person who joined the company who was a little bit cynical, I was a little bit cynical. I was like, “Yeah, yeah, yeah right.” But guess what? We have 3 billion people now, and it’s amazing to see what that level of ambition does to you. And even in terms of revenue, when I joined, we weren’t making much money, then I think and why maybe we were valued… The revenues were small, but we were valued at probably 4 or 5 billion dollars or something like that. But people said, “Hey, we’re going to be a trillion Dollar company one day.” And again in the early days when you first joined, it’s like, you were kind of cynical, but look at what’s happened in 10, 15 years.

Amit Somani 23:45

Absolutely. One of the things we advise and we work very closely with our startups at Prime is imagine yourself at a 50 X or a 100 X scale of where you are today. Just imagine it for a day or two, and then work backwards towards product, engineering, culture, process, whatever right? Principles. And almost everybody who starts with like, “No, I just need to get to X number of users or Y million dollars of revenue.” And they say, “If I’m at hundred million ARR none of this shit is going to work.” And so what does that mean? Obviously you’re not prematurely scaling things up, but it just makes you think very differently. So I think that is wonderful. So give me some examples Srinivas of where you had your most growth just for this principle of being self-critical or Kaizen, just maybe one example and then we can move on from this topic.

Srinivas Narayanan 24:35

Yeah. I think probably one where I’ve personally grown quite a bit is actually when things weren’t going well. And in hindsight I’ve done a lot of things, but there were moments when, during my career, when I thought I was failing and I was… We had goals and we weren’t hitting the goals and it was a really hard problem that we were trying to solve and it just wasn’t working. And I think what I learned is that one I didn’t acknowledge the problem early enough. I pretended like the problem was going to go away, that it was just going… We work hard and it will just kind of happen. And I didn’t acknowledge the seriousness of the problem early enough. And what happened as a result is that I didn’t get help fast enough and I think that’s one of the things that I’ve learned over time is that sometimes the set of problems you’re solving, you cannot solve on your own and they’re way bigger than yourself.

And in any company, that’s probably true. If you’re working on hard enough problems, big enough problems, they’re going to be bigger than yourself. And don’t try to be a hero. Don’t try to say, “Okay, I’m going to solve this problem.” You’ve got to ask for all the help that you need, right? And that’s what is important. And I think my lessons, like I said earlier, were one, I wasn’t critical enough of myself. I thought it wasn’t a big enough problem. I didn’t acknowledge it. Two. I didn’t ask for help early enough. I thought I’ll find a way to solve it myself because I wasn’t used to failure and I think this happens for a lot of people. A lot of people become successful, the first time you handle… You run into failure is like, you kind of… It’s hard to… It’s hard to acknowledge it. And I think really stepping back and saying, “Shit, I need a lot of help.” And I think that’s really important.

Amit Somani 26:20

Great. So as we get towards the end of the podcast here, I love this quote that you had shared earlier, which is that, “Hiring is an engineering problem, not a recruiting problem.” Can you elaborate a bit on that? And in general, how do you hire? Because for all these things, you said freedom, responsibility, accountability, audaciousness, hiring is the core jet fuel that is going to make that happen.

Srinivas Narayanan 26:45

Yeah. I mean, I think every startup and every company is going to go through this, right? Which is how you get the talent you need to really build the things that you want. And what I mean by hiring is an engineering problem, not a recruiting problem is that you can’t just throw hiring to a recruiting team and say, “Go solve this for me.” You have to look at it as an engineering problem and you have to completely partner with your recruiting team and HR team and all that. And what I mean by an engineering problem is that really look at it as an engineering problem. You’re trying to hire somebody and people these days are very familiar with growth funnels. If you’re trying to acquire customers, you probably are building growth funnels. You’re probably trying to analyze the growth funnel.

You’re trying to analyze what step in the growth funnel is working, what’s not working. Look at the hiring also as a growth problem. You’re just not bringing customers, you’re bringing engineers into your… Engineers or any other function into your company. And that’s also a process. That’s also a funnel. Are you getting enough people at the top of the funnel? If not, you need to work on your branding. You need to work on your engineering presence. Are you getting people in, but are they not failing? Then you’re not maybe attracting the right people. So really looking at it as an engineering problem as a funnel, and where in the funnel are you failing? And finding ways to optimize that, I think it’s a really important thing to do. And Facebook has been doing that. I’m sure other companies also do that. But I think for startups it’s really, the rigor in thinking about this as an engineering problem, I think is very helpful.

Amit Somani 28:05

Talk about the interview process itself, right? Whether nuances, because you obviously worked at multiple startups, multiple companies, larger, smaller ones.

Srinivas Narayanan 28:15

One thing I think that we put a lot of energy into is the actual interview process and the interview questions and the interviewers, perhaps most importantly, which is that there is a whole amount of training that happens to people before they can interview anybody else. And this is really important because interviewing is a skill just like anything else, right? And it’s a skill that can be improved. It doesn’t necessarily come naturally to everybody and it’s not something that is taught. And so you, you have to again, look at it as a skill to build on skill, to learn skill, to improve on. And that’s the way we do it. We train people. And then once we train people, the first time they interview, we actually do what’s called shadowing, reverse shadowing. So somebody observes how you interview somebody who’s been more experienced and they give you feedback and say, “Hey this part could have been better.”

And that’s super helpful for people. And the last thing we do is centralized decision making for recruiting, all engineering recruiting decisions go through a central committee and the committee reviews all the packets. And I think this happens at Google also, and probably other companies too, but that committee looks at the interview packets, they read the interview feedback and they also give feedback of the interviewers and then say, “Hey, there isn’t enough here for me to help make a decision. So maybe you need to focus on how you write better feedback so that we know which packet we are looking at.” So I think it’s just really helpful, that rigor in thinking about interview processes, rigor in writing feedback, writing high quality feedback, I think is very helpful.

Amit Somani 29:40

Wonderful. And you know, the last thing that I would say there is how do you get people oriented to the “Facebook way” in terms of post the interviewing, right? Post the offer, committee, everything’s done? Any tips and best practices, particularly from an engineering or a new hire point of view?

Srinivas Narayanan 30:00

Yeah. Facebook did this, and still does this called bootcamp. It’s very famous and Boz, who’s the CTO now, he started it. And I was in one of the first few batches of it who went through it. So it’s basically a four to six week program aimed at assimilating and onboarding new people who joined the company. And the goal really is to give people a broad exposure to what this company is about. Engineering, not just engineering, actually, everybody goes through it, all people, but in engineering, it’s four to six weeks. You get a broad overview of all the different systems, the company culture, the products that we build. It helps you understand how things work for this place. What’s important, what gets valued, how to be impactful. It helps you build relationships with other people. It also helps you build a holistic sense for what the mission for the company is and what products are because it’s, in large organizations especially, it’s very easy to get siloed into your own world and you lose the big picture.

You go and work on something and that’s important, but you don’t know how all that fits into something bigger. And I think that going through this own onboarding process also really helps understand how what you’re doing fits into the larger picture. And I think that’s always helpful because when you have a bigger picture, it helps you do things that are more useful and more impactful for the company. So it’s a four to six week process. It’s also aimed at being very hands on and actually one of the things that I did in the first day, I shipped code into production.

Amit Somani 31:20

Wow.

Srinivas Narayanan 31:21

The very first day. And so that also instills in you a sense of what move fast really means. And you know, these days, I’m not sure it’s one day anymore, but that sense of, Hey, you are here to actually have impact that impact means doing something and getting it in front of people that gets reinforced. And maybe it’s a week now, instead of a few days or a day. But that again is important. You want to reinforce the things that, the cultural elements about your company that you want all new people to carry forward with.

Amit Somani 31:50

Great. So Srinivas as we wrap up here, any one big takeaway from your point of view for people, I mean there are lots of interesting insights.

Srinivas Narayanan 31:57

I mean, there’s lots that I think we talked about, which is about right from moving fast, to having a big, bold vision, freedom and responsibility, being self critical, having a strong desire to win. And maybe one more thing I’d leave people with, which is one of my favorite things also is focus. I think, especially for startups. I think there’s only one thing that you need to do and you always have to think about that one thing you can do better than anybody else. It’s easy to get distracted at any stage in a company trying to do too many things but I would lead with that thought. And Facebook is also I think one of the better companies at scale, even though we are a large company, there’s always a unifying mission towards everything that the company does and that creates focus for everybody. So I would leave people with that thought, which is always think about what is the one thing you can do better than anybody else who everybody in the world is going to remember you for.

Amit Somani 32:50

Thank you so much Srinivas. Pleasure to have you on the show.

Srinivas Narayanan 32:53

Thank you Amit, it was great being here.
 

Enjoyed the podcast? Please consider leaving a review on Apple Podcasts and subscribe wherever you are listening to this.

Follow Prime Venture Partners:

Twitter: https://twitter.com/Primevp_in

LinkedIn: https://www.linkedin.com/company/primevp/