What it's like to be onboarded by GitHub's Darcy Clarke

Intro

Aboard Co-founder Evan Hallward recently sat down for a pleasant (virtual) chat with Darcy Clarke, a Staff Engineering Manager at GitHub & one of Aboard's Advisors, to cover all things engineering and onboarding. Darcy joined GitHub in April 2020 as part of the acquisition of npm inc.. Darcy currently leads 3 Engineering teams with 9 direct reports spanning Packages, Client Applications & Open Source domains under the Code-to-Cloud vertical in the organization.

Evan & Darcy discussed some of the unique elements to GitHub's Engineering onboarding while also looking at what it means to onboard a Software Engineer more generally in today's remote world.

Pre-boarding

Evan: Right off the bat, what do you do when welcoming a new engineer to your team?

Darcy: Our HR team helps us [Hiring Managers] immensely to ensure the onboarding experience goes smoothly; that said, once I know someone is joining our team, I use a set of templated emails to ensure the unique aspects of our team & a warm welcome are in that person's inbox come day one.

The HR team tends to cover things like how you'll be paid, how to get & set up health benefits, and a number of other general org trainings; what I send out is much more detailed and relevant to our team. That information, ideally, helps accelerate a new employee's time-to-understanding and time-to-contribution.

My teams' involvement in, and development of open source software means that Engineers external to our organization have the same access to the libraries and documentation we use on a daily basis. It's all online for them to go checkout proactively. Enterprising new hires can & have trained up on the tools & technologies we're using before they even start. This unique opportunity helps empower the Senior Engineers we attract while also providing a mechanism for future interested parties to learn more about our stack at their own pace.

Tip: Send personalized welcome messages (even if an HR team is going to do their own thing) to provide the info to start helping that new hire get oriented to your team

Evan: That's kind of unique to GitHub, eh? What you're working on is open source and available for anyone, new employees especially, to see. So if a new Engineer knows that they're coming to join your team, as an external hire or internal transfer, they can actually proactively, without you having to do anything, go and start looking into how the things are going. Is that right?

Darcy: Yes, it's actually extremely helpful. Based on the fact that our project is completely open source, that's a unique opportunity we have. That said, I have done similar things in other companies [that are closed-source]. Once people are exposed to what your tech stack is, and know where documentation lives, they come into a new opportunity with that much more knowledge & experience. That is, if they're a self­-starter and motivated to learn!

Tip: Be very explicit with new Engineers on the tech stack & provide resources to help them learn before they start

Onboarding

Evan: What is the onboarding process actually like then?

Darcy: Currently we have a dedicated two week, remote onboarding process as well as a 90-day (12 Week) plan to help ramp-up new employees. The first week is very much the fundamentals/orientation: high-level company, culture, vision & mission, payroll, benefits, security access & exposure to resources like our internal wiki etc. The second week is specific to Engineering onboarding; you'll learn more about our fundamentals, how we work, the expectations of us as Engineers, and what kind of systems they'll be touching. This extends to what sort of metrics they're tracked on and how they'll be graded.

Evan: Ah cool, so no coding in the first 2 weeks?

Darcy: It's not a mandate, but I don't generally expect to find Engineers actively contributing in projects until their 3rd week and beyond.

Evan: What do you think is truly unique about onboarding an Engineer, over maybe other disciplines or other roles?

Darcy: Probably the focus on data integrity & security practice/systems access. This stems from the fact that we [Engineers] are dealing with building the infrastructure that is going to house private information for our end users & consumers. We are the ones that are building the systems that create the value proposition for our organizations. It's integral to get every Engineer onboard and understand the importance of processes, and what kind of training might be required to ensure that data integrity and trust.

Getting access to sensitive information & systems or handling user's private data is a privilege and it's something that not everyone in an organization does.

Tip: Consider the unique areas of onboarding a specific role, build specific content & practices around that

Remote

Evan: Given the way of the world, when you think of remotely onboarding an Engineer, do you think it's easier, harder, or the exact same as if you were doing it in person?

Darcy: So Engineers are people too, we're not robots. When it comes to remote onboarding, sure in some regards it's easier, but it's also harder to create culture in general. That is a common denominator between all employees, all people, when you're joining a team and you want to learn the culture. You want to recognize who is important, what the structures are of the organization, who you need to work with, and which relationships will help you get things done. It's all much harder remotely, especially if your organization doesn't have great documentation.

Tip: Regardless of their role, every employee is a person and seeks social interaction

Darcy: To harp on documentation, if your organization is highly bought into the idea of a remote work culture, as many of us have had to be, then hopefully you're working on a fast pass for people. This would mean a knowledge base or internal wiki/resources that are constantly being updated. The goal is that somebody, like an Engineer, can quickly and easily access everything you need to be remotely onboarded. You gotta ask yourself: "How well has our organization documented and mapped out this information for end users? How quickly can somebody discover and get an answer to a question they have?"

At GitHub, we've got an internal knowledge base with search capabilities that are pretty incredible / invaluable; I can easily find exactly what I want by typing a couple of words. The aim should always be to make discovery of information easy, so that we [leaders] can tell others, like Engineers, where they can go to find the answers to whatever questions they have.

Tip: Create content that is up to date and built for remote work and make it super easy to search

Getting everyone acquainted

Evan: So we're talking about what could be done to onboard new Engineers, what about from the personal standpoint? Do you think trying to get Engineers to socialize more or talk to each other more, and not around work necessarily is an area for improvement? Or to be organized better?

Darcy: Having worked fully distributed with my current team for about two and a half years (pre-pandemic), and working with remote teams long before that even, creating a human connection is something that needs to happen in some way, shape or form; and it's not engineering-specific at all. Creating opportunities for connections & collaboration to happen requires a holistic and welcoming culture in your organization. That should be a shared identity. How you make somebody feel directly effects how engaged they'll be, through their onboarding and beyond.

I also don't think we [GitHub] ever do a social activity that's just Engineers, there's always a few folks that tend to be from the outside that role (ex. Product Managers, Designers etc.). GitHub tries to keep things interesting, play games, set up social groups, organize coffee & music hangouts along with using a buddy system; I think all of those are working for us.

When Engineers do get together & socialize, I think we often end up talking about what's happening within our industry - shop talk seems to be inevitable as we're all extremely passionate about what we do.

Bringing it all home

Evan: Thanks for sharing Darcy, it's always great to get a peak behind the curtain of what goes on at other organizations. To summarize some of your practices & highlights:

• Send a personalized welcome email (even if an HR team is going to do their own thing) to provide the info to start helping that new hire get oriented to your team
• Empower that new employee to get a head start and start teaching themselves about the work you're doing
• Be very explicit with new engineers on the tech stack
• Provide resources to help them learn before they start
• Consider the unique areas of onboarding a specific role, build specific content & practices around that
• Regardless of their role, every employee is a person and seeks social interaction
• Create content that is up to date and built for remote work
• Make it super easy to search or find what you are looking for, i.e. use smart document titles, descriptive content, organize it

Interested in discussing engineering onboarding with someone at Aboard? Grab some time (sure we can invite Darcy) or drop us a line. If you are ready to get started 👇