What Fascinates Laks Srini, Co-Founder and CTO of Zenefits?

Bobby: Hello everyone and welcome to another episode of the Loka podcast. On this episode, I talked to the co-founder and CTO of Zenefits, Laks Srini. Laks and Zenefits have had an amazing journey from him being  one of the two co-founders of Zenefits to getting into Y Combinator, to then becoming one of the fastest-growing SaaS companies of all time.

I learned a ton about growing engineering teams through hyper-growth phases, and I'm sure you will as well. Enjoy.

I'm here at Zenefits headquarters in San Francisco, looking out the window at another idyllic Northern California day. With me across the table here is my guest. Please go ahead and introduce yourself.

Laks: Hi, thanks for having me. I'm Laks Srini, co-founder at Zenefits. It's fun to be here.

Bobby: Terrific. Thank you. Thank you so much for taking the time.

The first thing I always like to do, especially when we're lucky enough to have a co-founder, is hear in their voice if they were explaining to someone who didn't know: What does benefits do?

Laks: Yeah. We, when we started Zenefits, we imagined it as, wouldn't it be cool if you hire somebody and completely paperlessly onboard them onto your company, set them up in payroll, set them up in health insurance, set them up with time tracking, vacation tracking, commuter benefits, 401k, and so on and so forth. And when changes happen, it automatically takes care of itself. When people leave, they automatically go away from all your systems. That's what we imagined because running entrepreneurs and people who start businesses do so because they have a dream. Once that dream becomes less than themselves, they have to hire people. And once they have to do that, they just end up doing a lot of administrative stuff. Which is probably not that much time, but it's definitely time that they spend. So our aim is to make that all go away.

Bobby: I think you have a really interesting journey of how you came to the starting line of Zenefits.

So before we dig into what happens after you started the company, I think it'd be useful context for our listeners of how you went from, let's say college to Zenefits.

Laks: So I went to college and did my masters in software engineering. It was a five year integrated course. Straight out of college I went to work for a hedge fund called DE Shaw. I started working for them in India. I was there from 2004 to 2011. So I got a nice ringside view of the buildup, the blowout, and the aftermath of the 2008 crisis.

I was there for a while because it was some of the smartest people I've ever worked with. Learned a lot of life lessons, like never play poker with a Russian bond trader. But it was a lot of fun. Everything we built there the show spun out into 2013 as a separate company.

So it's always fun to see that happen. But I've always wanted to do my own thing. And it got tired, making more money with money, which is what a hedge fund does. So one of my friends who had worked with at DE Shaw had gone to work for a startup called SigFig. So SigFig you can think of as a mint for brokerages. They connect all your different accounts, they pull them all together and they also do board advising. So I went to work there because it was in San Francisco, which is where you want to be if you ever think of starting a company. I think it's still true today. As true. It was 10 years ago.

Also it was in the financial space. I had this hangup that I built all this knowledge of how these things work and I didn't wanna lose all that so I was looking for something in the space and it was a small company and I could learn about how things run get paid to figure out how these things work is better than going and doing an MBA. And SigFig is where I met Parker, who was my co-founder at Zenefits. So when Parker left, he was thinking about starting a new company, he came and talked to me and then, I could see a straight line into why this was useful.

And also it was nice to make real things for real people and help some of the largest number of people who run businesses that are four and a half million small businesses in the US under the size of 20 employees. So if you could help them grow their businesses and run their businesses and make it easier, even if you made it a little easier to hire somebody, even if it made it a little easier to start a business, run a business, then we would've done a good job.

Bobby: That makes a lot of sense. So tell us a little bit about that process of being at SigFig. How do you go from SigFig to say being at Y Combinator?

Laks: Yeah. So Parker, Y Combinator matter was a very obvious thing for us. If you're doing anything that sells software to companies, it's a no-brainer. There are a hundred companies in your own batch. But also I think early days of Y Combinator was probably some of the most productive days of my life. We did not have anything built out when we got into Y Combinator. Parker had run Python, return a return, a small demo of a payroll sync. How do you like, get data from payroll and do and showed in this like website? So that's all we had. So we pretty much started from scratch. We launched in six weeks because we had to.

Bobby: So you had a demo before you even started the first week at Y Combinator?

Laks: Yeah. It was a demo of like, how do you go to payroll, get all the data, and then do some sort of the idea is like you use that to do insurance coding.

Okay. So it's as frictionless as possible. Yeah. And for most small companies, their system of report is payroll because they don't have any other systems. And even that is not up to date, hopefully. And sadly, yeah.

Bobby: Do you remember any of the other I know it's a while back, but in that in your class at Y Combinator, any of the other names that folks might know now have?

Laks: Yeah. I think Wefunder was in our batch. Airware that does software for drones. I don't know if you'd heard of it. It's a contracting marketplace. They're pretty cool. And there's a bunch of other companies, like really interesting GoldBelly, which delivers food from all over the US. So you can get a bagel from New York.

Bobby: Oh wow. For those that don't have much experience going through the Y Combinator process, if you were just trying to paint a visual picture of what that's is it like a, an NDA course where you are all these companies are going together into com lecture halls and hearing presentations?

Or how do you spend your, is it 12 weeks or so? 

Laks: It is roughly three months. Okay. 90 days or so. You start and then there's demo day at the end of it. You have group office hours every week. So you and a bunch of companies like get assigned partners and you talk about your problems or where you are.

And then you have dinners on every Tuesday. But that's what it used to be. Now the batches are much larger, so I think they separated and in our dinners, like we had people come and talk about stuff, and it’s great because I think part of it is when you hear these stories in a much more unfiltered way, you kinda get to realize, man, it's okay being a shit show. It's almost like being a prerequisite to being successful. So it just helps reset like some of the notions of what do you think successful companies like should look like, even if you have no idea what you're doing. So I think that was incredibly useful.

And our partners were great. We had Gary Tan, Jeff Ralston, and they were incredibly helpful.

Bobby: During the business hours of those 90 days, you are working with your co-founder on writing code or talking to customers?

Laks: Talking to customers, yeah. And writing code. Eat, sleep, exercise. That's pretty much it. Like you talk to customers, you continuously iterate and improve your product.

Bobby: Got it. Okay. So you get to demo. Talk a little bit about the growth of the team at large and then the engineering team from that point.

Laks: For most of YC it was just me and Parker. But before demo day, we'd hired our first marketing hire, Matt, who we knew from SigFig. He came on board as our VP of marketing. Yeah. Glenn, who was our engineer. Number two. He's now principal engineer. Glen and I had also worked together at SigFig before.

So those two came on board right before demo day. We had sold about 20 to 24 companies by demo day. So that was nice. And then by demo day we had built that insurance enrollment piece. So another thing why, I think that the time that we started Zenefits was incredibly interesting was we started ZF at late 2012, early, early 2013. And Obamacare/Affordable Care Act was going live January 1, 2014. So what the Affordable Care Act did was it normalized a lot of things and introduced a lot of rules about how insurance will be bought and sold by small companies and brokers and a whole bunch of things.

So it certainly changed the game where we could build a tax style help insurance. And brokers earn a lot of money. And at sifi, I'd never seen my broker and I at least the smaller companies, I don't think they add much value. I'd never seen my broker, even though open enrollment existed one month every year, my cost would go up.

I didn't even know it did. So we were, oh, what if we could be a broker? We can get a town money on the health insurance commissions, which is between $400 to $700 depending on which state carrier card per employee. So that's a lot of money. So if we could make that, we could offer the entire system of record for free. And that was, I think the business model genius that Parker came with.

Bobby: And so you guys, before you and Parker decided to incorporate, had that Obamacare announcement been made?

Laks: Yeah, the bill was the signed in 2009, 2010, I think. So it was gonna happen.

So there was a lot of noise around the broker community in terms of, Hey, commissions are gonna go down. We don't wanna work with these small businesses. They're not gonna make enough money. Yeah. And we're like, wait a minute, how much money do you guys make? It's like 500 to $700 if you're a SaaS company that said you're making $500 per employee per year, that's a amazing SaaS company.

Bobby: And another gold tip that you just mentioned there, but I hope folks heard it--you arrive at the beginning of Y Combinator with Parker having a demo that you mentioned, and then did you have any customers at that point before you started Y Combinator?

Laks: No.

Bobby: And then you, when you got the demo day, you said you had signed how many? 20, 24?

Laks: In 90 days we built, we launched, we signed up a bunch of customers. Which tells me that even with the maximal sales cycle of that 90 days, that there was a clear need. We were selling the smaller companies and the minute we launched it, like we knew that, listen, just take it all away from me. Help me take care of all these things. Let me run my business.

Bobby: How, so the sales process was fairly smooth. You explained what you did and they got it.

Laks: Yes. And by year one we were doing 1.3 million annual revenue run rate. Yeah. By year two we went from one to 20 million annual revenue run rate. And year three we went from 20 to 16.

Bobby: Got it. So in that demo day year for Y Combinator, you said you made a first, a couple of hires by the time you get to demo day.

Laks: Yeah. We had Two engineers in the very beginning, we ended the year with four engineers. Okay. We probably built eight products. So the health insurance piece was one. There was also this piece about benefits, flexible spending accounts, health savings accounts.

Yeah. So we added that set of products because they go very nicely with health insurance. Okay. And then we had added onboarding and payrolling. So if you just make changes in benefits, we'd automatically keep it updated in your payroll systems as well. Okay. It doesn't make sense to enter the same data in 14 different systems.

So we connect them all and make them feel like one. And then I think we launched time off and vacation tracking. We also did a bunch of stuff around contractors onboarding and paying them. So it was a lot of stuff that we did in the first year.

Bobby: So roughly eight products in that first year. And the engineering capacity that's delivering these eight products is you and how many engineers?

Laks: Me and the second so me and Glen were pretty much there from the beginning. Then our first our third engineer, if you called me and Glen joined us in August of that year. The fourth engineer joined us, fourth and fifth joined in December. So it was really three of us that, that were cranked out that first year products.

Bobby: And at what point in the timeline do you get the founder running from injuries?

Laks: So series A, we waited in December 2030.

Bobby: Okay. So then that allowed you to presumably scale the engineering team the following year.

Laks: Yeah, so the following year my plan was to have one engineer a month and we get to 12 engineers and 12 plus five. That's 17. This is a great plan project. This is what I'm gonna do. It all went over the window once we started selling really fast. So we went from five to maybe 25 by the end of year end. By the end of the following year. I think we went from 25 to. 30 or so by March of the following year. Uhhuh the year following that 2015. Yeah. From March, 2015 to October, 2015, we went from 30 to 215 engineers. Okay.

Bobby: So that was explosive. So let's break this down into those piece parts. So let's start with the five to 25-ish..

Laks: Yeah I call this like the room without a view part, which is four of us sitting in a single room. Everybody's next to each other, but even our first and second our third and fourth hires were.

People that I had worked with and mentored from DE Shaw and we had a bunch of really good people from India, so we had them working as international contractors. So we had to develop that working with remote DNA very early on. So I think that was incredibly helpful in what came later.

Bobby: Lemme just pause for a second. People heard that, so within your first four, or within the team being four or five people, you started to incorporate a remote developer?

Laks: Yeah, and because we were hiring from within network, I thinktTotal engineer at 12 or 13, we hired from the network. And then the second year is where we hired our first technical recruiter.

Bobby: So you hired you that was like a contractor recruiter?

Laks: No, we hired a full-time recruiter because we knew that the revenue was growing, so we needed to like staff up the team. Got it. So that's when we started hiring our first external.

Bobby: And do you even remember how you found that technical recruiter?

Laks: We interviewed a bunch of people and referrals through, we had an incredibly helpful investor network. Got it. So that, that helped through, that helped. And then the YC network is amazing in terms of like referrals and hiring people.

Bobby: So that's up to about 12, it was mostly kinda your internal network and people that you had worked with at DE Shaw and other places. And then that 12 onwards, it's this technical recruit that starts to…

Laks: Yeah. And then it was right 13 was probably our first person that none of us knew. And then it was a mix, like we were able to hire more people from the network and also like people who were extended networks, like because of referrals.

Bobby: And so how did the interview evaluation process change right at that 12, 13 cusp moment?

Laks: Yeah, so I think even from 12 to 25 30 it was still a much more, let's try and figure out fit. Let's see, like if they can do products, let's try and see if they have a product sensibility in the interview to see if they could actually own--ownership was huge for us. Like in the very beginning we had one person just develop entire systems.

They owned it then like we packed them and then like we had a team around it, right? So ownership is big. So if you just. Want to build something. Does somebody think critically about it? Can they ask questions? If they don't believe in something, will they not? Will they debate about it? They may be wrong, but at least like it's good to, because I think debates make products better.

I thought debates are not arguments for a reason. So that was the kind of thing. And then when we had to hyperscale there's no way you're gonna run this process. So we said, okay. What. Is the kind of person can we get right really fast and how would we use that? So we said, okay, let's optimize for raw intellectual software and problem solving capability.

Okay. Okay. If you wanna optimize for that, then what best then run our own like global programming competitions. So we had a bunch of ACM, ICPC programmers and a bunch of people in the company already. So they came up with the questions and like we partnered with Hacker Bank and ran these global programs for Zen Hacks.

We ran this for a couple of years. We invited the top 30 people to San Francisco, did a bunch of tech talks, and then interviewed them and probably gave offers to half of them and hired them. So that was like a fast way for us to hire. And it was also. We want the best talent no matter where they're in the world.

Rather than just competing with the talent here. That's also when we started thinking about, okay, we need to have, we can't just have San Francisco as our only base, like for engineering. We need to think about how we can have diverse locations. Diverse people.

So we set up an office in Vancouver, our engineering number three went to Vancouver is still running that office. Okay. Then we opened an office in Bangalore because some of us still had networks there. They were really strong people who didn't want to leave India. Yeah. So we had them in our Bangalore office so that we could add more muscle. So that's how we did that.

Bobby: Having gone through that process and used the programming test and things like hacker rank would you recommend using that methodology for evaluating?

Laks: It really depends on what one wants and what the company does and what stays there in, most interviewing is according to us. But more than that I think it's really important, like what the post interview onboarding process looks like.

Bobby: So let's spend a little bit of time talking about exactly that.

Laks: Yeah. I would go as far as to say, Listen, like if you've hired somebody, you've done your tests, they probably can do the job.And if they still can't do the job, then I don't think there's anything wrong with them. There's something wrong with the process of a company or the process you run in your company. And I would also go so far to say most engineering jobs or software engineering jobs these days don't require rocket science.

Like people are not, like people are writing credit of various forms. I don't think you need a PhD in neuroscience to write your marketing pages. So I think that's also, people have to be realistic about the engineer ambition fit. I think that's a very important thing.

So I would say if you've run your process fairly, okay, you found a person who should be able to do the job, now it is up to you to make them successful, right? If you have a system that produces quis, And suddenly say, why are the widgets not around? It doesn't work. So the process you have and the system you have is really important.

We screwed the puts on this like many times, right? Like we hyperscale without having tooling an infrastructure. The one thing that we did right though was we had a good three week onboarding bootcamp for anybody like that we hired. And once we started hiring bulk, we started having a bootcamp that starts on the first of every month and 15th of every month. And we made sure that people join on those dates. So a three week bootcamp.

Bobby: So let's pause.I'm a big believer of that. But at what point just in terms of company size and rough timeframe, did you have the capacity to create the materials and like a Zenefits University? That was the bootcamp?

Laks: Yeah. So it was mostly a volunteer run program. So we had about 30 engineers at that point. 30. 30, okay. 25, 30. So said, listen there's no way. People are going to come in and get onboard really fully. This is where I think being in Silicon Valley is a great place to run a startup because there've been numerous people who have helped me think through these things.

One of the people I spoke to was at Facebook who set up the bootcamp there. Yeah. So we took that and shrunk it. So part of the bootcamp was. You do a bunch of tickets in different parts of the organization. So you get a good idea of the court base, like you get a safari around the court base.

And you get to work with different people. Because they're doing your court reviews. You get to get a sense of what interests you. And then, We ask them, Hey, what do you want to do among all these things you've done? Yeah. And then we have the list of things that we need, and then we try and match that to the best possible so that if people are doing what they like, they're gonna be way more productive.

Yeah. And then the other thing that happens during the boot camp is I think every day we have two or three sessions where. A bunch of engineers will talk about, okay, like how do you do things like Python and Zenix? Like how do you do GitHub stuff, like basics. And there'll be architecture stuff and then there'll be some folks start talking about like, how does like JavaScript and like at that point we use Denver, right?

So like a Quickbook crash course on however works, right? Yeah. So that would be like four or five sessions, which we recorded and then like reuse them later. Yeah. When we did not have 10 people joining at once. Because that's way more efficient, right? When you have two people, one person joining, it's much better to record these things and just use it so that people can see their own.

Sure. But we had a buddy system. So we had one, two or three where one buddy would've two or three new hires assigned. And if you're doing lower volume, one to one is good. Yeah. And they would be the person who assigns them to catch so they'll be a neutral person who helps them walk through like the baby steps in terms of if they get stuck what to do about it.

And we had some fantastic buddies who developed in rank to become engineering managers here because that's one of the good ways to mentor people and learn whether to see whether you like it or not. To have a passion for that.

Bobby: Have you guys set internal goals for how soon after a new hire starts do you expect them to be productive on the code?

Laks: I think we have a rule of thumb because we were hiring so fast. Yeah. We had to have a process where we could let go of people who are not working out pretty fast.

Again, like usually the interview process. Hyper gently. Like we were charting interviews left and center. So we had a 30, 60, 90 day program where 30 days, like we look and see if they've done anything at all. If they've not made a single comment, not done anything through the boot camp, that's a bad sign.

And we probably say this is not the right fit. 60 days like we've just started with the team. So we'll see how well they're integrating. They've done some menial bug fixes, stuff like that. And in 90 days we expect them to have gotten started on their product of their own and start doing something a little more meaningful, having done some design docs, interacted with a bunch of people. So that's not happening then. Like it's not a fact.

Bobby: Having gone through that experience of developing that bootcamp and refining it it sounds like you started roughly around the time you had about 30 people. If you were to go back, do you think you would start earlier?

Laks: Sure. We just had so much to do. Remember--for most of the year when we grew from two to 20 million in revenue, we had about 10 engineers. Like we had more towards the back of the yard and. We, the startup was 14 months old, 14 months old, 18 months old. We didn't just have time to build all these systems.

So we were hand-implementing these companies, doing a lot of stuff, like supporting the operations side of the business. Yeah. So the, just so I, I do, I wish I would've done that. Sure. But would that be it would've been like if I had done that. Probably not.

Bobby: So think of it more in terms of if you're coaching a team that has those kinds of growth aspirations, They're not gonna have time to run bootcamps at least that very early days.

Laks: I would probably do a really hard thing to do because people who are looking for jobs are not like just sitting around like for a week where you could do a trial. That would be the best way to hire somebody. If you can pay them. They're, they come in and work with you for a week and if they like it and you like it works that's probably a lot more nuanced interview process than any questions anybody could ask.

I think the best interview process we had, like when we had a marketing engineer, was, we gave him the exact work that they'll be doing and gave him three hours. Listen, if you can do this in three hours, like at least get something done in three hours. Like you have the job and he was able to do it and he had the job.

Bobby: Yeah. Like you said, that's the closest I found too. But the issue is that the supply side of the equation is not so thrilled to do that because they have options.

Laks: It's competitive. Yeah. The thing that we found worked really well, even when sometimes when our interview process is not extremely, doesn't give a clear answer, but maybe it's a referral or a strong referral. We've done these things for take-homes like later and that's probably takes two to four hours to complete. So that can potentially be done on a weekend. And we've had some great candidates who killed it on the take-home, but did not do the interview itself that well.

Bobby: Interesting.I guess what you're saying is it's all a function of learning from the false positives and the false negatives.

Laks: Yeah. I wish, like we learned well from the false negatives, like what we, aspirationally we wanted to follow everybody that we didn't hire through their career and see how well they did. But it's just happens like once every year.

Bobby: That journey from say three to 10 to 12 engineers, the engineering organization is, I'm guessing, fairly flat at that point.

Laks: Yeah, I think we had 10 engineers. Everybody was a software engineer and everybody in the product to me, It just got weird because people would join the company and they wouldn't know who the fuck was, what Like, there's no titles. Who do I go and talk to? So it cost their problems. So we said in true startup style, okay we need to solve this problem. Let's get two people to go figure this out. So two people sat there for two weeks and came up with a list of titles and responsibilities and all that stuff.

And I'm like, wait, like why are we doing this? This is a solved problem. Titles are a solved problem in the world. We shouldn't be reinventing the wheel of these things. So we start out saying listen, like there are a lot of solved problems in the world. We are not this unique snowflake, sunflower, whatever you wanna call it.

If that is a solved problem, we should just adopt it, right? But in the thick of things we asked to forget these things. So titles was one of them. So like we spent two weeks, like two people's time like trying to figure this stuff out. And then we said fuck it, let's just use the standard titles out there.

Like we got this like really cool, full job description and title levels and bands and all that stuff, from what people do. And then we just used that.

Bobby: And so out of that was born the org structure.

Laks: Although everybody was a software engineer, there was an organization mostly by what they worked on, the products they owned. So it was loosely like teams. It was loosely like pods. Okay. So we had a bunch of payroll stuff that we did. So it was like payroll and time was a pod.

All our HR and core services was a part, and all of our benefits teams were a part. So we had these like concept of large parts. Yeah. And we had notional leaders for each of those. But it just wasn't titled that way.

Bobby: And then it became more official. Talk a bit about your own role as the co-founder and engineering leader. The evolution of how you were spending your time from spending 110% of IT coding to starting to spend less time coding and more time on the people process management, leadership, communication.

Laks: Yeah, I probably screwed that up. I should have probably switched my time, spent writing code a lot earlier than I did. It felt like I was spending, it felt like that's the key word. It felt like I was spending 80% of my time coding hard and 10% of my time interviewing. And I had no time for anything else. So we did and we, a lot of the process we ran were like ad hoc which is where I think that was a really bad thing.

I wish that we had done that slightly differently. Everything was well intentioned, right? We had wikis documenting all these processes, how they work, to make it as fast as possible. But people don't read. There's a reason why--people write to write code rather than read code like people are just like somehow reading stuff. And I've come to think maybe it's extreme that no knowledge is institutional unless it's codified or automated in some way in tooling or infrastructure. Yeah. So like we took that to heart as we scaled further and we built a lot of tooling around right after the code is committed for a pull request.

Like it just takes over. There's a whole bunch of things. Yeah, so coming back to that question, like I, I wish I had spent less time writing code, because eventually my code… I'm so happy that most of my code is died a painful death. It deserved to!

Bobby: As Laks the coach, what would you have recommended to yourself?

Laks: I would've probably switched to doing full-time code review at 10-15 engineers.

Bobby: And when did you actually make that switch?

Laks: One and 60 and 70. So I still have a long streak by the way.

Bobby: I can definitely believe it.

Laks: Over time, I've stopped thinking about it as a matter of pride. I think it's a poly that I have the longest drink.

Bobby: I think it's hard to know these things without experiencing them. We've talked about the engineering organization growing and the org changes throughout it. Now let's look at the lens for that same engineering organization growing for something like testing. And the processes you put in and at what stages you put in, what processes?

Laks: Yeah. So okay, these are my biases. Yeah, sure. I think the kind of people we hired were also my biases.

Like we want we wanted all leaders to be player-coaches, so we wanted them to be able to actually do the thing that team will do. So for most leaders that we hired, we said, listen, like you're just gonna be on the team. And if you are good enough, as you say you are, you'll become the automatic leader in four to six months.

So we actually intentionally give people lower titles, like to be on the team with the. Understanding that if they are, if they have the skillsets that later have right, they'll become the national leader for that team. And that's when, like we make them the manager of that team. And that way, like they work in the trenches with the team. They understand everything. And those were my biases. And for most part, I think they still work because I think there's a stronger bond that's formed with the manager and the team. So that, that was one of the things. The other big biases we have is we are big on ownership, which means you don't write code and toss it over the wall to somebody to test, like you write your own test, like you are the last line of defense between anything bad happening on production, right?

So to a large extent, like we still have a huge like test week. Automated tests and integration tests and we build tooling for all that stuff so that engineers can build like end-to-end integration test like that runs in RCI environment. Okay. And we use rate for Q in the early days to run smoke tests.

Now we use this tool functionalize and a bunch of stuff. That said, we do have we to four specialized quality engineers that are embedded with the team that help them test new products. We have a five person contractor team in Bangalore. That runs the end-to-end tradition every day. And that's pretty much it.

Bobby: Those are the things. Engineering team growing from a handful to five, to 10 to 20. At what point do you start or how do you handle the DevOps function?

Laks: Yeah, so we, we were monolith for a long time, for the first three years. Like we, we had a single deploy. Yeah. So we deployed three times a day in the beginning, and then we cut it down to once a day.

We do once a day today. Yeah. But today we have a plethora of services as well as the monolith. So the monolith is just we had one deploy pipeline we had to build for the first 18 months of Zenefits. Fun fact. Our app server, DB server and our web server was the same machine. Ah, and we had one standby hot swap and we were doing 10 million of revenue.

Bobby: Would you recommend that to others?

Laks: There was a reason for that, right? We had six engineers. We had some really good data that we wanted to protect in our lives. It's so much easier to protect one server than protect a fleet of service. And also no network.

Yes. We develop some bad habits because of that, but it was done for a reason. Like it was not like, oh, let's just do this and you know it.

Bobby: Yeah. And At, what was the motivation? What drove you to move as an organization away from monolith to services or microservices?

Laks: I still think monolith is a great architecture type. And if you build your team a lot more slowly, if you have people who know what they're doing for the most parts, I think more or less still has a huge number of advantages. People talk about distributed modelless, like you can deploy multiple times, like turn on different services, make it look like a service oriented architecture.

Do a lot of like tricks and magically and all that stuff. Because again, I think code is fundamentally written for humans to collaborate on, make changes, and right. And it's just incidental that the machines that do interesting stuff, right? Because if humans can't like change it, like then it's just stuck in that like static form and it's not very useful.

So that's why the monolith automatically enforces a certain number of things, like a single repo and a bunch of stuff like that makes it easier. Not that you can't have that with the services, but traditionally, like the services maximalist, think about like individual repos, individual level things like I'm doing on DevOps, so it's like making changes in garments becomes a pain. Like it's really hard. So I'm big on governance. Like we will not let a thousand sunflowers bloom. You use whatever the language you want, somebody writes closer and leaves the next day and you're stuck with this.

Like it's not very useful. So we were big on governance, we let the team do its scores and learn and so we are now going back to a mono depot with microservices. And we hired this person like who had this, who was building this infrastructure called Dulo, which made it really easy to run like microservices as a platform. So we used that stuff. Yeah. So again, now we are looking at how can we make our monolith, because we use Django each as an app. So we had this Light transformation was, we wrote this tool called Fortress. So if you drop Fortress on an app, it makes it behave like it's a Microsoft. So you can't access everything because it's five times we can do inter interpret type stuff.

So it makes it behave like that. So that's the first step. And then because moving from one to microservices is a whole world thing and I'm sure like a lot of people go through it. So I, and also we spoke to a whole bunch of people who were extremely helpful. Like we spoke to the people who did at LinkedIn, we spoke to people in Uber, we spoke to people with Petrus and they were extremely helpful.

Bobby: And How long did that process take?

Laks: It's still an ongoing process. And we are very careful about what gets to be a microservice, how is that done? And so on and so forth. But I think, okay so I think the reason also, like we decided, okay, that's a good thing because I think the microservices architecture makes it harder to do the wrong thing.

Like our monolith, if you drew a quote dependency graph, like it looked like a chicken feet drawing, it was like two people took two hands and went at it on a spiral. So it's very easy to do the wrong thing in a monolith. So that's where microservices makes

Bobby: it easier. Yeah, I can definitely attest to that journey from monolith to microservices is one that comes up a lot.

And when to do it and how best to do it. So I think one of the, unique things about Zenefits and your time there is that you had this met growth period and then you had some turbulence and then you come out of the turbulence and you continue to go up into the right as a solid success.

Statistically very few people come out of that turbulence, but you guys did. And what. How were you able to, maintain the culture and the quality through that

Laks: period? Yeah, so it was definitely a rollercoaster. But we learned a lot from that. The big thing is, I think fundamentally one thing that kind of both part and me like we talk about is the, you're not as good as they say you are.

You're not as bad as they say you are. What really matters is like what the customers say and whether they're still customers throughout this period. Like most of our customers, like customer are customers, right? And we added new customers so that's that kind of helped people see through a lot of these like other stuff.

And I also, I think the delta between what we think entirely about. What needs to be turned around. This is like what externally was mentioned, I think was huge. So the arbitrage was in our favor. Yeah. I think like it was really important for us to take some of the lessons learned and turn it into products.

So we have we did two products. One was for compliance calendar. Which kind of lays out all the federal compliance rules and regulations and dates for filings and all that stuff as a calendar so that our customers we just know, oh, your deadline for filing ACA is coming up like in two weeks.

And this is, these are the instructions right now. We could also say if you wanted to do it, if you want us to do it for you, click here and sign up for that product. Yeah. But we wanna make sure that. Nobody ever misses these kind of things, right? So all the federal stuff exists in our Compliance Canada product.

The other thing we did was this app, Salesforce app or Licensing Plus, which would ensure that no broker or any person who needs a license to do something cannot do that without having a license. So it enforces certain rules and rule sets, and we have more than a hundred companies using that, including insurance companies.

Bobby: Interesting. So there's like this great opportunity for Sort of dog food in your own experience and creating something that, it sounds like a large number of customers not use that.

Laks: Yeah. I think Jake calls it drinking our own champagne.

Bobby: Indeed. For those people that are currently individual contributor engineers and have aspirations to become a manager how would you help them evaluate whether it's a right fit for them?

Laks: Joking aside, I think I think you should really find out if that's what you want to do. Because I really think this is like 10x engineer, right? I think different people are 10x in different ways, right? There is a 10x engineer, there's a 10x product manager, there's a 10x data science, there's a TenX, something else.

So I think that's why I talk about the engineer ambition fit. Like I think that's really important. So just because people become managers and directors and VPs and just because like people doing that doesn't mean it's a right fit for everybody. So I think one needs to introspect deeply. To figure out if that's what you want to do, because. More people, more problems. So one thing and some people really enjoy doing that, right? People can 10 x themselves by leading a team of 10 engineers or people can themselves by writing code work for 10 engineers, right?

So it's a great way to scale one. The second thing is I wish we had done New manager boot camps like earlier than we did manager trainings earlier than we did. Because listen, like just because you're a great engineer doesn't guarantee you're gonna be a great manager. The day you become manager, you're starting a new job, day zero.

You have zero skills in this thing and I think it's important to tell 'em like, you are gonna screw up, there are gonna be days like where you wish you'd never become a manager. And it's okay. It's about expectations, right? Most of these things is about expectation setting.

I heard this talk by somebody who once mentioned like there's a baby manager, then they become a teenage manager and they become another manager, right? So it's like when somebody's a baby manager, I think it's important to say listen, like this is a completely different job from like what you've been doing so far.

And just because you're good at that doesn't mean you're gonna be good at this. So I think like having a framework for them, like setting expectations and what the expectations are from them as well, I think is important from an organization perspective. I mean that hopefully, like if they listen to this, like they're gonna know, okay, fine, I'm gonna screw up and it's okay.

Bobby: Yeah, I think that's important to know. Are there, as you've gone through your journey in improving your leadership chops. Are there books or things that you've read that you've valued quite a lot?

Laks: I think there's a bunch of things. I really like the Michael Lo book for, I, I forget the name.

I'll put it in the show. I'll put it in the show notes. Yeah. And then I think the mythical commandment the closet in terms of like project management and. That, that stuff. And then it's just, I think everybody develops a feel for it as they learn and grow.

Yeah. I also think certain things are super important that are fairly generic kind of things to do. I think one is if you have some values and rules and all that stuff, I think it is important on day one to establish that in the team. So that they know what to expect.

This is how I see the world. I'm open to changing it but if we can have an argument about it and like you prove it, otherwise I'm happy to change that, but this is how I see the world based on all my experiences and here's what I expect from you guys. Like here's my non-negotiables, right?

I think those are like important to like, establish, and the second thing that I found to be useful is like having a predictable, transparent process, right? It's okay, how do people get recognized in this team? What do they get recognized for? Yeah. Who gets promoted and like, why do they get promoted for one of the like, unintended consequences are everywhere, right?

Like one of the fun stories that, like we had demo days, right? Everybody has demo days. Like it's awesome. Like people who are working on products come and showcase it. But what it created was people appeared an incentive for people to work on these like shiny products. Rather than like infrastructure stuff.

Some people gravitate towards that, but they felt that oh, if I have to be working on a product, if my work is to be showcased. So like we changed that and said listen, like it's not a demo day, but it's like show tells. Like you can show until anything that's what it was meant to be turned into this, right?

So I intended consequences are everywhere. So it's useful to identify that they are going to happen. It's useful to like identify that early on and make adjustments.

Bobby: That makes sense. So in my research I found that you played basketball and represented your school. Is that right?

Laks: Yeah, I played basketball in college in India. So do you

Bobby: are you still a fan of the sport? Do you watch the nba?

Laks: Yes, I do. Okay. So here, I used to wake up at 5:00 AM India time in 1995 to watch the Jordan Post.

Bobby: Yeah, that was the second of the threepeat years. Yeah. Of the second threepeat, I think.

Yeah. The second three. The second. Do you remember the center on that bull team? It's from Australia.

Australian guy called Luke Longley. Luke Longley? Yes. Who very famously was asked, how would you define Michael Jordan in one word? And he said, predator. Wax this has been a fantastic experience. I think my listen, I really appreciate hearing your stories. Thank you so much for your time.

Laks: Of course. Happy to share this and thank you so much for having.