Developer onboarding with Limor Bergman, PowerToFly and DigitalOcean

Transcript

Beyang Liu: All right. So I'm here with Limor Bergman, who was a former director of engineering at DigitalOcean. And she's now director of a mentorship program, PowerToFly, whose mission is to help women grow their careers. Limor, thanks for joining me today.

Limor Bergman: Hi, Beyang. My pleasure to be here today.

Beyang Liu: Awesome. So, as you know, we're talking about engineering onboarding and trying to understand how different engineering organizations handle onboarding. I want to kick things off and just ask for an overview. What was onboarding like at DigitalOcean? Both non-technical and the overall experience.

Limor Bergman: Absolutely. I'll be happy to share that; things may have changed since then because I haven't worked there for over a year. DigitalOcean, I started working there at the beginning of 2016. It's the first time I worked fully remote and I... To be honest, I was very anxious at the beginning, how it's going to be like. Especially because I was in a leadership position. So I was a little bit skeptical at the beginning. How was it going to be like leading people remotely? The onboarding processes at DigitalOcean is the best I've ever seen, at any company I've worked at. And it starts with... Again, things probably have changed because of COVID. But before then, typically the first week you will travel to the headquarters, which is in New York in Manhattan. And you'll get an opportunity to meet some people there. Potentially sometimes people who work with you were traveling as well.

Limor Bergman: So you had an opportunity to meet with them in the office because the teams were about 50% remote and 50% in the office. And the company had a very robust onboarding process. Which started obviously by the people team, introducing the company. A little bit of history about the company and all the benefits and all that. And you had a lot of tasks you had to do from IT, it was very, very organized. Like you had a checklist of what you need to achieve in the first day and in the first week with check boxes and reminders and all that jazz. And also what I really like, you got an opportunity to hear an onboarding session, which lasted about an hour from each department leader or department representative.

Limor Bergman: It was not all happening in the first week. There were ongoing onboarding sessions that happened. I think back then it was about every two weeks. Probably things have changed since, at all different departments. It could be finance, it could be marketing, could be product, engineering, each department had their own session. And what I really liked about it, you really felt connected to the company. And you felt well, I get opportunity to hear about what other people are doing here. Especially when coming from engineering you think everything is surrounding around you. And then you hear that, oh, there are actually other people in the company to do a lot of things.

Beyang Liu: That's awesome. So, as a new hire on the engineering team, I would get this spiel of ongoing concerns and top priorities from the department heads of all the other functions, like marketing sales and product and things like that is. Is that...?

Limor Bergman: Not necessarily about top priorities. It could be just describing the department, describing what they do, how they do it. Like it was for design team or product, like product thing, for example, would highlight all the products the company has, the roadmap and all that. So depending on the... Just to get you an understanding of the company and the different functions.

Beyang Liu: That's awesome. So you get situated within the business and you understand where you fit in, into the big picture. What about the technical onboarding side of that? And I know that a lot of this is team specific. But at your level as a director, what sort of things were you thinking about in terms of technical onboarding? Onboarding of the code base, getting people ramped up on tools, technologies, frameworks? That sort of thing.

Limor Bergman: Definitely. So, as I said the company had an engineering onboarding and when I started engineering was much smaller than when I left. So when I started, everything was relatively small and people knew each other. Most engineering people knew each other. When I left, obviously it was not the case. We had an engineering onboarding session, usually someone from the veterans... Like from the people with the most seniority of the company would do a technical overview of the architecture. But again, as we grew, it wasn't obviously possible because there were multiple products, multiple teams, it was just too much.

Limor Bergman: So there will be a generic engineering overview. And then each department, like for example there was network storage. Like every different team will do their own onboarding, which includes typically a high level architecture overview and onboarding of, how do you deploy? How do you set up the environment, the development environment, the tools, all that things. And then team specifics about a code base and some would give some tasks on your first week, deploy your first code... Depending obviously on the team and your team specific things.

Beyang Liu: Yeah. That makes sense. As the code base grew, obviously DigitalOcean... Actually, how big was the company when you first joined and how big was it when you left?

Limor Bergman: So when I joined, we were, I think around 150 people in total. And when I left, it was crossing the 600.

Beyang Liu: Wow. Okay. So I imagine that growth presents a lot of challenges. And especially as you bring on all those people, you've got to figure out how to onboard them and make them effective. How did the onboarding process change as the company grew and the engineering team and the code base grew?

Limor Bergman: I think it changed mainly... It really forces us to be more process oriented, to document more, versus one person telling another. Initially it was more about, "Oh, go meet with this guy or this girl, meeting those people. They'll show you." And it turns to more, "Okay, those are the pages that describe all the information." There are still a person, right. We usually try to match a buddy for everyone that started, "This is your buddy." Typically, someone from the same team that will meet with them and will help them. Until they... Basically as long as they need, but still a lot of that relies on reading materials and doing some things individually. Rather than, "Oh, go sit with this person and they will show you everything."

Beyang Liu: Got it. So you're putting more things into writing, writing up more documentation. Because it's harder to ensure people have the proper onboarding experience just through osmosis and informal conversations and things like that. That makes a lot of sense. I think from talking to a couple of other engineering leaders, one challenge that rises due to this solution is that documentation... Especially onboarding documentation can sometimes get out of date, because you write them and then time passes. And it's not always top of mind. Was that an issue that you saw at all at DigitalOcean? And if so, how did you deal with that?

Limor Bergman: Absolutely. So we had one thing that helped us a little bit. I don't know if it's a good thing. But we had obviously, because DigitalOcean is a cloud infrastructure provider, so everything is live running all the time. So you have to have 24/7 on-call rotations. We had on-calls and as we grew, we need to onboard people also to on-call. When someone joined, they weren't on call the first day. Only after they be in a certain amount of time at the company and they felt comfortable, they will join an on-call rotation. And for the on-call, at least in my organization, we try to do on-call training. So the training included a lot of things like troubleshooting and all that, but also high level, because I had some initial...

Limor Bergman: I had some challenges in my team about how to set up the on-call rotation. So it would be not too small, not too big. So sometimes people had to be on on-call on areas that they weren't maybe very familiar. And the on-call rotation also forced us to create trainings and to update them because really someone can not be on call if they don't know the codebase or don't know what's going on. And it was actually very helpful also for onboarding new people.

Beyang Liu: Got it. That makes a ton of sense. What about difference between junior and senior engineers in terms of how they onboard? As you grow as a company, you get people with a wide range of experience levels coming in. Are there things that you notice in that, that are different between how these two different sets of engineers onboard and do you tailor specific parts of the process to each of them? Or is it more like, have a single standard and we'll react to each individual on an individual basis?

Limor Bergman: I don't think we're big enough in order to start tailoring that. And to be honest in my organization, we didn't hire many junior developers... At least developers at the time I was there.

Beyang Liu: Yeah.

Limor Bergman: We did have a very successful internship program that resulted in several hires. So we did experience a very junior developers joining versus very senior developers joining. When a seasoned developer joins, the expectation from them is to be able to do a lot of things independently. To be proactive, to reach out to whoever they need to. Usually this is not one person. As the code base grows, the company grows, no one knows everything. Different people are more familiar with different parts of the code. So we expected someone seasoned, more senior to be more proactive. Yeah as I said, we matched him with someone, we had all the documentation in place. But eventually they had to really do a lot of independent reading, learning, and reach out. When someone very junior joins, especially an intern, the expectations are entirely different.

Limor Bergman: We expect them to be less independent and less proactive. We do want proactiveness at all levels, but again, because those people don't come with a lot of experience, a lot of them it's their first job, we do more handholding. Meaning we try starting with smaller things, setting up their own local development environment, maybe not the full deployment to the production. First, the local development environment and giving them smaller tasks. So they can start small maybe with some small bug fixes, instead of overwhelming them with the entire architecture on the first day.

Beyang Liu: Yeah. That makes a ton of sense. It sounds like, some other companies that I've talked to, they have like a boot camp program for new engineers. It sounds like DigitalOcean didn't have that. It was, "Let's get you onboarded to the actual engineering team as quickly as possible, provide you with docs, provide you with the high-level architecture overview and then set clear goals and you drive yourself in acquiring the pieces of knowledge and context that you need." Is that kind of the overall philosophy?

Limor Bergman: Overall, but again, I'm speaking on behalf of people I lead. So I cannot speak for the half of the entire company. And again, each team may have been a little bit different. Also it was because I was overseeing multiple teams. So it was not like in the bits and bites of everything.

Beyang Liu: What about this tension between ensuring consistency versus giving individual teams the freedom and flexibility to tailor their onboarding experiences to their specific needs? Can you talk a little bit about striking the right balance there?

Limor Bergman: Yeah, I think it doesn't go only on onboarding. It goes in general to the processes the company have, which tooling you use and all that. And obviously when a company is small, when things are starting off, it's free for all. Everyone does pretty much whatever they feel like and as the company grows and mature, there are more standards. DigitalOcean is no different. So as the company grew, there are more standards around okay, which tools. But there was never a very strict rule, "You have to use this editor, you have to use this, you have to use this." And each team had different onboarding and had different... Even doing agile, they had variants each team, some run scrum team, some did other things. It was never completely strict that everyone have to do exactly the same thing. There was some freedom, but on some things like deployment, continuous integration, all that, there was less freedom.

Beyang Liu: Got it. So the standardization was more on... Would you say it's more on the ops side? Because at the end of the day you have to deploy this single...

Limor Bergman: I think more on the ops side, yeah. On the processes, again was not exactly like it happened. There was still a lot of work to do, but it was leaning towards more standardizing that. Versus having everything free for all, everyone can do whatever they want.

Beyang Liu: One of the things that we were talking about earlier is this issue of legacy code. And we've seen this across many engineering organizations as they grow. When your company is younger, the code base is younger. There's less legacy code, as you become wildly successful and your team grows a lot there's more and more existing code to deal with. How does that change who you hire for, how you onboard them and what sort of things that you look for to make them successful?

Limor Bergman: Yeah. I think my organization had probably the most legacy code than any others because the Droplet's product that I led among others was the original product, and there were new products that came in later. So I had the most legacy code. I think it depended which team or which exactly we hired for what role and how much they had to handle legacy code. We would be transparent about it during the interview process, not to try to scare them off. But at least they know what they're getting into. It's not like they only need to worry about legacy code. It's not like a maintenance job, but part of the job. And really based on that, a lot of times we figure out if they are fit, maybe they are fit on a different team.

Limor Bergman: I don't think there's a company that hires people unless it's a brand new startup that is starting everything from scratch, that hires only people that write new things. Anywhere you go, there is always code that needs to be maintained and engineers by nature, they like to write something new. They don't like to maintain. So there's always a balance. And we try to make sure that someone joins they understand that they need to also maintain or fix or whatever and touch legacy. And it may not be in the language they feel most comfortable with or whatever. And based on that, we'll figure out if this person is a fit or not.

Beyang Liu: So you're mostly able to hire great people it sounds.. And as I understand it, the code base, that was the initial product, that was originally written in Perl. And then later they migrated to Go and changed a lot of the architecture around it. Is that right?

Limor Bergman: Yeah.

Beyang Liu: Got it. What do you look for? How do you tell that like, "Okay, this person is going to be able to take on this very large and complex task and make forward progress."

Limor Bergman: Yeah, I think it's hard to know. First of all, being transparent helps. But also trying to figure out from the past how they dealt in situations where they had to deal with the legacy codebase. How they were able to basically look at someone else's code, if they can give an example of situations where they had challenges with potentially debugging or trying to understand what this person was thinking about when they wrote this code. And then you can try to understand if this person really done that or they are getting away from this, like getting away from fire.

Beyang Liu: Makes sense. So you just asked them to talk about past experiences and see how they describe it. Were they able to work productively or is this like a...

Limor Bergman: We also, at some point... When I was still engineers, we had in our interview process, we took a code snippet and we asked people to look at that code and tell us what it is doing.

Beyang Liu: Oh, interesting. So you actually tested for ability to read and quickly understand?

Limor Bergman: It was just a piece of code that did something, that had some logic. I don't remember what it was, to be honest with you. And we asked people, okay, can you tell us what he does?"

Beyang Liu: That's really fascinating. I think that's... I might have to steal that for our own interview process. Because I feel like the tendency is you have people write code and you optimize on that. But then especially as the company scales, I feel like, more and more time spent reading and understanding code and figure out where your change is going to fit in.

Limor Bergman: Yeah.

Beyang Liu: Cool. Another challenge that we've come across on growing engineering teams that ties into onboarding is transferring historical knowledge. Especially from original authors and maintainers to the folks who inherit the codebase. How do you make sure that knowledge is transferred? And what do you do when it isn't? I think it's inevitable. At some point you're going to run into a situation where there's an area of the code where you need to go and make some change into it. And no one at the company actually understands how it came to be. So yeah. How do you deal with that?

Limor Bergman: Yeah. So first of all, as I mentioned, we had this on-call training. I think that those were really helpful in trying to keep some of the information. But there was never a hundred percent and also there's a limit to how much you can invest in documentation, in whatever. And we did have situations where there were code no one knew, no one wrote, no one worked on it. Whoever wrote it left. And we were looking for someone who is willing to take the challenge, to be honest with you. And you'll be surprised that some people take that as a challenge and actually are fascinated by that. Some people are not.

Beyang Liu: Yeah. Some people are natural code archeologists.

Limor Bergman: Yeah.

Beyang Liu: Cool. As a last parting note here, right now in your current role, you spend a lot of time mentoring people and advancing their career development. And you've had a long and very interesting career working at some of the big names, Sun Microsystems, VMware, DigitalOcean. So you've seen a lot when you, when you think back to what it was like when you were that junior engineer first out of college and you're onboarding to your own codebase, are there tips that you would give people now? And to what extent has the world of code changed?

Limor Bergman: So it's yes and no. I'll tell you why, it's not different. Because, well, like I started, it was code and I had to go and understand what the hell is going on there. And I think the tip, I would give people who are starting out, don't be ashamed of admitting you don't know something or you don't understand and just ask. This is something I see a lot that some people are just... They're go getters, they ask, they try to reach out. They're very proactive. Some people are just they don't ask and they don't have the confidence. So that would be my number one tip. It's okay not to know. It's okay not to understand, especially when you're just starting out. Just go and ask and look for people who can help you. And I think a lot of changed since I started. Back then, things were, I think simpler in a lot of ways, applications were simpler.

Limor Bergman: The scale was much smaller. There were not distributed systems running and scaling like we do today, open source. The world has changed a lot, it was more monolith applications, client server, something relatively... I don't know if to call it simple, but more manageable.

Beyang Liu: Yeah.

Limor Bergman: Then what we run today, the workloads that are running today. Like you cannot attach a debugger and walk through it. I remember I was debugging the code walking through, there are a lot of situations today that you cannot do that.

Beyang Liu: Yeah. It certainly feels that a decade or more ago, the quality of the tooling was a lot lower. There were certain things that I feel like "Wow, people actually had to make do with that?" But at the same time, the amount of code that you had to deal with was a lot smaller back then, too. So in some sense things get better, but new challenges presented themselves.

Limor Bergman: For sure.

Beyang Liu: Cool. Well Limor, thanks so much for taking the time to chat with us today and sharing your experience and insights on ensuring onboarding. Really appreciate it. And yeah. Thanks for taking the time.

Limor Bergman: Absolutely. My pleasure.

Want to dive deeper into better onboarding practices? Read about how to prevent codebase overwhelm and more onboarding advice from engineering leaders.