Developer onboarding with Jean du Plessis, Director of Engineering, Sourcegraph

Transcript

Beyang Liu: So I'm here with Jean du Plessis, a member of our team at Sourcegraph and we're chatting about onboarding engineers. And I guess, to kick things off Jean, can you tell us about what your current role is and what it is that you do at Sourcegraph?

Jean du Plessis: Yeah, thanks man. I'm the director of engineering of our Developer Insights organization at Sourcegraph. Our teams mostly focus on bringing Sourcegraph's intelligence as well as other third-party tools that customers might be using, bringing that to the developer where they're at, whether that be in their code hosts, like GitHub and GitLab, or if they are using Sourcegraph.com, and eventually in their IDE as well.

Beyang Liu: Awesome. And so let's talk about onboarding. So how do you think about onboarding engineers onto your team as a director of engineering?

Jean du Plessis: Well for me, the important part is that when you bring a new team member intoba team, you want to make them feel at home. For me, it's all about making them feel comfortable, giving them psychological safety to know that they don't have to come in and try and be a rock star. We already hired them because we believe they're good. We want them to come in and really acclimatize to the new environment, new teammates, get familiar with the company, the processes. And so my initial objective is really to empower them, ready to be full, expecting anything from it. Give them the support they need and help them to gain that context they don't have upfront so that when they get stuck into the code and they start working on the roadmap, they have the necessary knowledge paths in their head in terms of making the right decisions along the way.

Beyang Liu: Yeah, that makes sense. When would you say that people first dive into the code? Is there a period of time where you have people focus on just meeting members of the team first or do you try to introduce them into the code as quickly as possible?

Jean du Plessis: I think most engineers that I've met want to get into the code as quickly as possible. And I'm always the one that tries to pull them back to say, hey, take it easy. I've seen some engineers ramp up in two weeks and they just want to, they feel able to learn better by just getting stuck in with the code, other engineers take a little bit longer. But I really encourage them, especially in that first week. Take the time to go through your onboarding tasks diligently, make sure you read as many pages of a handbook as you can. Get the context and understand things.

Jean du Plessis: And then I create like a list of people that they should meet up with both in the team and outside of the team, form relationships and start creating bonds with people, you're going to need those relationships later on. And the more people you meet early on, the more people you have to reach out to when you get stuck. Especially in more a remote environment where you can't just walk up to somebody and tap them on the shoulder. You want to foster those connections as early as possible. And also just to create a sense of belonging.

Beyang Liu: Do you have a list of specific milestones? Is there a checklist that you have either written down or in your mind that you want every new member of the team to run through or is it fuzzier or more informal than that?

Jean du Plessis: Yeah, I think we've got a hybrid approach and we use this workflow and software to help drive new teammates through specific steps, administrative tasks and things everybody should be doing. And then there's even some engineering generic stuff that people should be doing, setting up a local environment, understanding the code standard and principles we work on. And then there are some domain specific things you want an engineer to learn about the team that they're in. And I think that's where things become a little bit more tailored to the team that they're joining. And each team will probably have a little set of things that they want to share with them. But then there's also another part of this is we create a document with expectations that we have of somebody in their first 90 days.

Jean du Plessis: So week one normally is about just focusing on onboarding tasks in the software we use. Make sure that you get all of those done, there's no expectation of you to do anything. Two to three might be get more familiar with the codebase. You start making a small change, we'll probably assign an issue to you that's a good first issue to tackle that's a little bug or little enhancement, something just to get you comfortable with the development process going from writing the code, opening PR, getting it reviewed, going through the build system and seeing that change go live. Because that gives you a lot of context as well, and that maybe would open some of those questions in their minds as well. And I would say, and then we have set one month, two months, three months kind of outcomes we want them to achieve. Something that, and this is more about giving them a mark in time to know whether they're performing well.

Jean du Plessis: I think as a new engineer or any new employee in the company, you always want to know, am I doing well? Am I living up to expectations? And having a document that just sets up clearly what your expectation is over the first three months gives them that sense of ease that I know what they expect of me and I can benchmark myself against that expectation. And most engineers tend to overachieve on that because we set the expectation low. We want to give them an easy on-ramp into the business, into the team and set them up for success. It doesn't help they come and we have this high bar that we expected them to achieve. And then we just set them up for failure. So you want to set them up for success.

Beyang Liu: Yeah, that makes sense. Does engineering experience factor in at all to the onboarding steps? Are there higher expectations that you have for engineers with more experience or do you have kind of a unified approach for that early stage onboarding?

Jean du Plessis: No, I think you really have to tailor it. I think people are unique, each person is their own individual. The role that you hire somebody into a team for is specific as well. And so I think you want to tailor those expectations you have to the role, to the experience, to the complexity of the task at hand. And so you want to be careful of trying a one size fits all solution because it can come across generic and unauthentic, and you want a new starter to feel like, man, they really thought about how they want to help me be successful in this business. Because that's the first sign that they get that they care about me more than just another person that's coming in to do some work.

Beyang Liu: What about the technical aspects of onboarding? So one of the challenges is you're diving into a new codebase as an engineer. And I think every codebase just seems like massive and daunting the first time you dive into it. And there's kind of that first milestone, which is you fix your first bug, you've made a change, but then from there, there's the rest of the codebase and learning about the architecture and all the different product areas. How do you think about giving people that more holistic or high level knowledge?

Jean du Plessis: Yeah, I think as a new engineer onboarding, you're a little bit of an adventurer, you're going into uncharted territory. And I think what you want to do as a manager, you want to allow them some freedom to explore because in that exploration, that process leads to learning and discovery, but you also want to again, set them up for success. So you want to give them a map, that could be your architecture documents. You want to make sure they have the right gear so that could make sure they have the right software and the a laptop and all of that. And you probably would have given them a satellite phone as well if they really get stuck out in the wilderness and they can call for help. And that might be the team that is there to support them or an onboarding buddy that gives them guidance along the way. Something that they can call a friend if they really get stuck in something.

Jean du Plessis: But I do think there's this merit in allowing them to navigate their own journey. Because as you kind of like, you can listen to somebody explain something to you, and that might be helpful, but it's different when you're figuring it out yourself and you starting to connect the pieces. My personal opinion is that is a little bit more valuable. And so I'm happy to have somebody who is struggling a little bit upfront and navigate the codebase by themselves with the right guidance obviously, and in that way, probably gain more insights and understanding.

Beyang Liu: Cool. I have a challenge question here, which has come up, I think in these other conversations, which is when you're bringing new folks onto the team, you try to transfer as much knowledge and context from the existing folks to the newer folks. And every company does this and you get the newest folks spun up and they're getting the motion of contributing bug fixes and improvements to the existing codebase. But often what's harder is transferring that complete historical context that gives people the confidence and the knowledge to make these big sweeping changes, like a big change to the architecture.

Beyang Liu: And sometimes teams get stuck in this mode where the original authors of the team have now left, all the people currently working on it are people who have joined after that first initial stage. And there's kind of this implicit set of assumptions that are baked in now that the current team doesn't feel comfortable challenging. Do you think at all about that in the onboarding process? Do you think of that as conveying that knowledge as a thing that is possible to do, and is that part of onboarding or is that something else?

Jean du Plessis: It's interesting you mentioned it because this exact scenario played out for an engineer recently. They love context and understanding the history behind decisions and helping them have confidence in what they performed as ideas. And thankfully, Sourcegraph has this practice of putting RFCs to get a for when we want to have introduce any changes or make architectural decisions. And we were able to kind of track back this document, which even predates my time, that gave context on these decisions, which was amazing as an artifact to be able to refer back to that. Because even the people that worked on it at the time, they forget about it.

Jean du Plessis: What you did six months ago is essentially for them in history. And so this helped him and I asked him recently in a skip level meeting that I had with him, I said if you were, because we specifically talked about the onboarding experience and how he experienced it, then essentially we agreed, or he agreed that having more of these RFC type documents, as almost like history documents as to why we came to work where we are is really helpful for somebody new coming in. Because as somebody that's coming in, you look at the codebase and can make some assumptions and you can make judgments without knowing the context and having those documents and decisions documented that you can refer back to them is really helpful, especially to those individuals who strive on understanding context before they feel empowered to move forward.

Jean du Plessis: Other people are more comfortable with moving forward. They'll look at what there is, they will take it as fact and they'll move forward with in terms of what they feel is the best way to go. But personally, I found a lot of value looking back at some of these RFC documents and just understanding things a little bit.

Beyang Liu: That's interesting. So you said the word artifact when you were referring to these documents and another term that's come up is code archeology. And I guess this is beyond code archeology, this is now into the product planning process. When you think about helping people acquire that context, oftentimes it's quite painful. If I don't have someone who knows that a particular document was written back in the day or knows something about the codebase that will help me jump to the right revision or past version or uncover the pull request. I guess my question here is, organizationally, how do we make that easier? Or is it even possible? Is it just kind of a necessary part of the job that this is difficult?

Jean du Plessis: Yeah, that's a good question because it's got some of the challenges as if it wasn't documented, you still need to know who to ask.

Beyang Liu: Yeah.

Jean du Plessis: I think one of my beliefs around code comments is that it should give context, not explain what the code is doing. You can look at the code and figure out what it's doing, but you want to know the context and I'm thinking we should almost reference these RFCs in our codebase. And so you can easily jump to it. Might even be a nice Sourcegraph feature to incorporate one day.

Beyang Liu: It's an extension. Link to Google docs.

Jean du Plessis: Yeah. The other part that I'm thinking of now is when somebody, for our organization, we've got a specific slack channel, which is purely for onboarding. Every team member is in there across the org and when a new teammate joins, we specifically ask them to ask questions out loud in it. Whenever they thinking of something that they don't have an answer immediately, they should ask it there. Not that there isn't value in trying for them figuring it out, but because it can unblock them quickly by utilizing the collective memory of the teammates, but also it showcases where the gaps are in our onboarding material.

Jean du Plessis: Where can we make sure that we provide the right context for somebody so the next person doesn't necessarily have to worry about this question? And I think that could be a mechanism of helping surface or at least tap into the collective memory of teammates that might know what the answer is, and we make the expectation clear to teammates that when a new teammate asks a question in that onboarding channel, your highest priority is to unblock them at that point. And so it still relies a little bit too much on humans to achieve this. And this is why I really liked the idea of being able to reference this even from the code. When you're looking at the code and you're like, why is this like this? Being able to click through to an RFC that explains to you the thinking that led to this could be quite valuable.

Beyang Liu: Yeah. I feel like that's maybe a practice we should adopt.

Jean du Plessis: Yeah.

Beyang Liu: How do we know that we're doing a good job with onboarding? Are there specific metrics that we should track or are tracking or specific signals or pieces of evidence that indicate that we're doing a good job of bringing people onto the team?

Jean du Plessis: Currently we don't track it in a quantitative manner. I think the strongest signals I'm seeing right now is from observations in terms of how quickly people are ramping up. Recently, a new hire joined and I saw him become productive within two weeks. PRS was starting to go out and lots of things were kind of becoming productive in his mind. And I think I was wondering why that was. Yes, he's got a good manager and maybe smart but why did he get up to speed so quickly and in terms of ramping up, I saw him delivering features very quickly. And my expectation is that maybe after a month, somebody starts delivering at that pace. And in a recent skip-level with him, first I asked him, how was your onboarding experience?

Jean du Plessis: What really worked for you? And one of the things that he mentioned was that his manager had a 30-minute meeting with him every morning for the first week where they literally, all they did was he was just sharing context with him. And that made me think, it is so true that most engineers, the thing they miss is not the ability to read code or understand code, it's the ability to understand the context behind the code. What is the architecture that we're working with? What is the thing that we're trying to achieve here? And once you give them those kind of pillars of knowledge, they can utilize that and use their intellect to do things quickly. And so, yes, it's a very high touch way to do it and maybe not every manager has the time to do it, but maybe you could use another engineer in your team that's maybe in the same timezone.

Jean du Plessis: And just the continuous sessions of every day for 30 minutes, they just discussed the context of things, setting up. And I think that proved to me that context is king for engineers when they join their company. We kind of hire the brightest engineers with the best technical abilities, but without the right context, they'll be stifled to make progress because they will be uncertain about what to do because they need to first figure out what it is they're working on, how does it work with everything with this to really be able to contribute effectively.

Beyang Liu: I like the way you phrased that context is king. It's kind of short and pithy and I think entirely accurate. I was thinking the other day about onboarding and how it relates to stuff that we do even after the kind of early stages of joining a new team. Because in some sense, when we're talking about ramping onto a codebase, I think a mini version of that happens every time we dive into a section of the code that's still unfamiliar to us, or maybe start a new project in a new feature area. There's kind of a ramp stage in that to spinning up on context. And I wonder if part of what we do as engineers is kind of this continuous onboarding because no one likes to work in the same part of the code for too long. We're always looking to acquire new skills, learn about new things and build things in other areas of the product. So I guess, are there lessons that we can take from what makes a good onboarding experience to what makes a productive software team in general in kind of the steady state?

Jean du Plessis: I think the one thing that is, when somebody new onboards, you're almost deliberate about making sure that they have the right information before you set them free to go. But once the team is established and when we talk about maybe touching a new product feature or a new area, we tend to overlook that upfront work you always need to do to get yourself into that ready state. And I like the way you put it. It's like you're constantly onboarding when it's a new area of a product or codebase. And I think if teams were more deliberate in terms of understanding the context of the area they're going in, where they're going rather than rushing to things, maybe that is something that has really helped them as well. I think if it's proven that context and being deliberate in preparing for an engineer while they're onboarding is effective, and we have this similar pattern that happens in different stages of teams' evolution, it might be worthwhile exploring those again.

Beyang Liu: Yeah, it's an interesting thought. Jean, thanks so much for taking the time today to chat and share your wisdom on onboarding. Really appreciate it.

Jean du Plessis: It was my pleasure, thank you.

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