Philosophy
February 22, 2022

Onboarding Lessons: Q&A with Ryan Richardson, Chief Learning Officer at Edify

Now as Edify’s Chief Learning Officer, Ryan is using his expertise to share how Edify’s tools support sustainable and scalable onboarding programs for engineering teams.

Building a career in technical onboarding is a rarity, making Ryan Richardson a true specialist in a field. For the past 15 years, Ryan has built successful onboarding programs for engineers in multiple companies, including Yahoo, LinkedIn, and Atlassian. Now as Edify’s Chief Learning Officer, Ryan is using his expertise to share how Edify’s tools support sustainable and scalable onboarding programs. 

 This interview has been edited for length and clarity.

What do you think are the essential ingredients to building a technical onboarding program?

Ryan – First, engagement with others in the organization. You cannot put new hires in a box, and say, ‘stay over here.’ You’ve got to strategically extract them, and have them interact with the organization as a whole.

The second thing is you have to enable new hires. They have to be enabled for tools, tasks, to ask questions, to try stuff, to get a feel for the place. And to be able to say this is terrible, and responds with ‘yeah we need to fix it, that’s why you’re here! Come on, help us fix it.’ They need to get their hands dirty.

New hires also need to be given some sort of model of where to go: how to behave, where to get help, what is the culture, You have to model something where they can say: this is the organization I’m a part of now, this is how the norms are, this is how I communicate, this is how I ask for help, this is how I don’t ask for help. 

What do you think organizations tend to miss about technical onboarding for engineers?

Ryan – The biggest problem in the space that [companies] miss, is understanding how many different problems technical onboarding solves or helps solve. They always try to look at solving one problem; whether it’s the time to first code to commit, tenth code commit, whether it’s security, whether it’s access. They always tend to focus on a singular thing that is a pain point. 

But the reality is, by looking at a single problem, companies end up building the wrong onboarding experience. And so you put new hires through a program that doesn’t meet the needs of the hire or the organization. Because they need to take a step back and ask:

  • What is the organizational challenge?
  • What is the managerial team-level department challenge?
  • What is the new hire experience challenge?

Companies tend to bias on one thing, heavily, and that inevitably leads to ineffective, and really unsatisfactory experiences. You very rarely ever hear engineers say ‘My onboarding was awesome!’ Unless they go through a program that has been designed by someone who pushes back on the engineering leaders to get a deeper understanding of what is needed. 

It really is a space where unless their manager or their team buddy really takes them by hand, engineers don’t see a good experience, unless someone looks at all of the challenges.

How do you start building a technical onboarding plan when it touches all these broad categories?

Ryan – You start by asking the right questions to the right people. One question would be how do you want your CTO to hear new hires describing their onboarding? A second question is what are the challenges within the organization that a new hire is going to face? 

You’re not going to get every single piece of code or tooling correct, but if you can give your new hire context to what they’re walking into, and help them validate what they inevitably chose to do for the foreseeable future, you are on the right path.

Ask how can we validate their choice to be with us—to be a member of our engineering community—and how do you give them as much context as possible. That’s the first step. 

What’s the objective long-term? What’s the bigger picture they’re trying to solve for? To many programs the first commit. You hear ‘I want them to be able to commit code’ regularly. Is that more important than [new hires] not quitting in 30 days or 60 days? Isn’t turnover the bigger problem? It might be better for [a new hire] not to commit code for three months, and then not leave in six months. 

Another thing to focus on is: make it safe, give them context, validate their decision so they are encouraged—then unfold the tools, the practices, the procedures, the best practices, culture, relationships, all of that [knowledge] now fits together and creates a full view of their new role.

Why should we make this distinction between technical onboarding versus just regular onboarding?

Ryan – There’s an argument to be made that they could be similar, but technical onboarding has a certain level of complexity to it. A technical role has tooling, it has industry knowledge, it has these other layers on top of organizational [work], a business objective—so there’s a level of complexity for what you’re entering into, technical onboarding can also be interpreted very broadly here, 

I think that complexity makes onboarding harder, and that complexity is often tied to teams, it’s often tied to access to secure documents or tooling. If you’re going on in most other roles, there’s maybe one system, maybe two, and those are your lifeblood. 

Whereas in engineering, it’s often 15 to 30 different frameworks and tooling on top of your [coding] languages. It just is that much more intimidating. You’re also entering into organizations that tend to need you right now.

How do you know when technical onboarding is successful, and how do you design a program that’s not seen as a burden?

Ryan –  I would say that most onboarding is seen as a chore, a tax, or an absolute obstacle to overcome by everyone involved in onboarding, when it’s not done well. From the manager to the buddy/mentor, to the new hire, it's a ‘let us just survive’ kind of approach and attitude.

There’s just so many toxic things that happen when you dump a new hire into a busy team. And almost all technical teams are busy. Almost all technical managers have other priorities.

When technical onboarding is done well, it is a pleasure. It is setting experience. It is building relationships. It is establishing and normalizing culture. When it's done well—[success] is seen by the organizations very quickly.

The whole point of technical onboarding is that it makes it easier on the manager. It makes it better for those folks [on the team], and their new hire is more comfortable, they’re not scared anymore. So everyone is like ‘This is great! I love this! This is amazing!’ Then you know you’ve hit the mark with onboarding.

Then, it is organic, and it is helpful, and it’s supportive, and it’s serving the needs of the organization. It’s serving the needs of the individuals, and the only real challenge left is on the program manager and developers who have to make sure it keeps running well.

There’s a perception that onboarding is just for new hires, but how do you see technical onboarding benefiting engineering teams and their managers?

Ryan – When technical onboarding is done right it keeps subject matter experts, it keeps managers, it keeps existing hires more focused on the work they should be doing, which is moving the company’s objectives forward. 

It is less disruptive to the work, if the onboarding program is smoother, more cohesive, and can do more of the heavy lifting. And that [results in] faster time to productivity, faster to integration with the team, all that good stuff that we want to see. That’s part of why it matters to everyone.

There’s the other side of this which is that onboarding is also available for things that are changing within the organization. We can actually be onboarding from one platform to a different platform internally. We can have an entire team that needs all new awareness of a product, tool, or platform. 

That type of onboarding—the new way we deal with testing, the new way we deal with documentation, the new repo we put our code in—that's a whole other level of onboarding to new-ness that can be addressed with the same approach.

How does onboarding help technical teams share knowledge and learn?

Ryan – The normal state of being in a technical company is that you will never know it all, and you will constantly know less than you need to know. That is the nature of these very amazing, complex, technical companies and technical environments. 

Every single tool has 90 options you’re unaware of. And getting comfortable with that acceptance of not being able to become an expert in those areas is very, very difficult.

When you get to the level of companies that need technical onboarding programs, they move too fast, they change too fast, there’s just not a person who can know it all.

And once you unlock that ability to say ‘I don’t know,’ it opens up the second piece, which is asking for help. I talk to a lot of leaders who say if only I could get my new hire to ask for help, versus wasting that five or six hours trying to find it themselves.

One of the nice features about eddy, is the fact that you can ask eddy in Slack, ‘hey, I don’t know this,’ then eddy finds and asks someone for you. It is such a silly disconnect, yet it serves a very fundamental purpose.

And that’s what continuous learning allows, when you expect it in the organization, when you understand it's a collective knowledge base—not an individual knowledge base—and you’re going to learn every day you’re here, it’s easier to ask for help, it’s easier to say ‘I don’t know.’ We can move on quicker, faster, and more efficiently.

What excites you about working with Edify, what’s the biggest headline for you?

Ryan - Edify is absolutely a product that allows flexibility of use. I think it’s more of this multi-tool. Through its path builder, from the different paths that you can construct, the different ways you can engage with others, allows you to adapt to a lot of situations and compliment the other elements [of onboarding].

One of the fundamental core development concepts within Edify was engineer enablement, with a specific emphasis on onboarding. I certainly have never found a product that has done that. 

When you look at the way Edify meets engineers in Slack where they want to be, when you look at the idea of having template-tized pathways that can be customized by role, by manager, by month, by day, by week. And can be scaled from one day to many, many days, and [the tools] can be used for existing hires, and mergers differently.  

And then, there’s a really nice empowerment of letting the new hire engage and guide their experience, saying [to eddy] I’m ready to move on, I have a question, I want help, introduce me to someone.

For all those reasons, I was like, finally a product that can scale onboarding! That can help the program live and deal with turnover in the onboarding team itself – which is a huge problem for these organizations. Edify helps with all of those things, and there’s a lot more to be built on top of it. 

I do believe that the future of Edify is clearly going to be like: ‘What do you use for onboarding?’ ‘Edify of course. What do you use?’ ‘Oh yeah, Edify, that’s the tool.’ The same way we treat Slack now, it is one of the most standard ways we engage and share knowledge in the technical world, which should be Edify for onboarding technical talent.

 I think that anyone who is serious about onboarding and cares about their talent having a great experience technically, they’ll be like of course we want to use Edify, it’s a no-brainer.


By
for Edify

Building a career in technical onboarding is a rarity, making Ryan Richardson a true specialist in a field. For the past 15 years, Ryan has built successful onboarding programs for engineers in multiple companies, including Yahoo, LinkedIn, and Atlassian. Now as Edify’s Chief Learning Officer, Ryan is using his expertise to share how Edify’s tools support sustainable and scalable onboarding programs. 

 This interview has been edited for length and clarity.

What do you think are the essential ingredients to building a technical onboarding program?

Ryan – First, engagement with others in the organization. You cannot put new hires in a box, and say, ‘stay over here.’ You’ve got to strategically extract them, and have them interact with the organization as a whole.

The second thing is you have to enable new hires. They have to be enabled for tools, tasks, to ask questions, to try stuff, to get a feel for the place. And to be able to say this is terrible, and responds with ‘yeah we need to fix it, that’s why you’re here! Come on, help us fix it.’ They need to get their hands dirty.

New hires also need to be given some sort of model of where to go: how to behave, where to get help, what is the culture, You have to model something where they can say: this is the organization I’m a part of now, this is how the norms are, this is how I communicate, this is how I ask for help, this is how I don’t ask for help. 

What do you think organizations tend to miss about technical onboarding for engineers?

Ryan – The biggest problem in the space that [companies] miss, is understanding how many different problems technical onboarding solves or helps solve. They always try to look at solving one problem; whether it’s the time to first code to commit, tenth code commit, whether it’s security, whether it’s access. They always tend to focus on a singular thing that is a pain point. 

But the reality is, by looking at a single problem, companies end up building the wrong onboarding experience. And so you put new hires through a program that doesn’t meet the needs of the hire or the organization. Because they need to take a step back and ask:

  • What is the organizational challenge?
  • What is the managerial team-level department challenge?
  • What is the new hire experience challenge?

Companies tend to bias on one thing, heavily, and that inevitably leads to ineffective, and really unsatisfactory experiences. You very rarely ever hear engineers say ‘My onboarding was awesome!’ Unless they go through a program that has been designed by someone who pushes back on the engineering leaders to get a deeper understanding of what is needed. 

It really is a space where unless their manager or their team buddy really takes them by hand, engineers don’t see a good experience, unless someone looks at all of the challenges.

How do you start building a technical onboarding plan when it touches all these broad categories?

Ryan – You start by asking the right questions to the right people. One question would be how do you want your CTO to hear new hires describing their onboarding? A second question is what are the challenges within the organization that a new hire is going to face? 

You’re not going to get every single piece of code or tooling correct, but if you can give your new hire context to what they’re walking into, and help them validate what they inevitably chose to do for the foreseeable future, you are on the right path.

Ask how can we validate their choice to be with us—to be a member of our engineering community—and how do you give them as much context as possible. That’s the first step. 

What’s the objective long-term? What’s the bigger picture they’re trying to solve for? To many programs the first commit. You hear ‘I want them to be able to commit code’ regularly. Is that more important than [new hires] not quitting in 30 days or 60 days? Isn’t turnover the bigger problem? It might be better for [a new hire] not to commit code for three months, and then not leave in six months. 

Another thing to focus on is: make it safe, give them context, validate their decision so they are encouraged—then unfold the tools, the practices, the procedures, the best practices, culture, relationships, all of that [knowledge] now fits together and creates a full view of their new role.

Why should we make this distinction between technical onboarding versus just regular onboarding?

Ryan – There’s an argument to be made that they could be similar, but technical onboarding has a certain level of complexity to it. A technical role has tooling, it has industry knowledge, it has these other layers on top of organizational [work], a business objective—so there’s a level of complexity for what you’re entering into, technical onboarding can also be interpreted very broadly here, 

I think that complexity makes onboarding harder, and that complexity is often tied to teams, it’s often tied to access to secure documents or tooling. If you’re going on in most other roles, there’s maybe one system, maybe two, and those are your lifeblood. 

Whereas in engineering, it’s often 15 to 30 different frameworks and tooling on top of your [coding] languages. It just is that much more intimidating. You’re also entering into organizations that tend to need you right now.

How do you know when technical onboarding is successful, and how do you design a program that’s not seen as a burden?

Ryan –  I would say that most onboarding is seen as a chore, a tax, or an absolute obstacle to overcome by everyone involved in onboarding, when it’s not done well. From the manager to the buddy/mentor, to the new hire, it's a ‘let us just survive’ kind of approach and attitude.

There’s just so many toxic things that happen when you dump a new hire into a busy team. And almost all technical teams are busy. Almost all technical managers have other priorities.

When technical onboarding is done well, it is a pleasure. It is setting experience. It is building relationships. It is establishing and normalizing culture. When it's done well—[success] is seen by the organizations very quickly.

The whole point of technical onboarding is that it makes it easier on the manager. It makes it better for those folks [on the team], and their new hire is more comfortable, they’re not scared anymore. So everyone is like ‘This is great! I love this! This is amazing!’ Then you know you’ve hit the mark with onboarding.

Then, it is organic, and it is helpful, and it’s supportive, and it’s serving the needs of the organization. It’s serving the needs of the individuals, and the only real challenge left is on the program manager and developers who have to make sure it keeps running well.

There’s a perception that onboarding is just for new hires, but how do you see technical onboarding benefiting engineering teams and their managers?

Ryan – When technical onboarding is done right it keeps subject matter experts, it keeps managers, it keeps existing hires more focused on the work they should be doing, which is moving the company’s objectives forward. 

It is less disruptive to the work, if the onboarding program is smoother, more cohesive, and can do more of the heavy lifting. And that [results in] faster time to productivity, faster to integration with the team, all that good stuff that we want to see. That’s part of why it matters to everyone.

There’s the other side of this which is that onboarding is also available for things that are changing within the organization. We can actually be onboarding from one platform to a different platform internally. We can have an entire team that needs all new awareness of a product, tool, or platform. 

That type of onboarding—the new way we deal with testing, the new way we deal with documentation, the new repo we put our code in—that's a whole other level of onboarding to new-ness that can be addressed with the same approach.

How does onboarding help technical teams share knowledge and learn?

Ryan – The normal state of being in a technical company is that you will never know it all, and you will constantly know less than you need to know. That is the nature of these very amazing, complex, technical companies and technical environments. 

Every single tool has 90 options you’re unaware of. And getting comfortable with that acceptance of not being able to become an expert in those areas is very, very difficult.

When you get to the level of companies that need technical onboarding programs, they move too fast, they change too fast, there’s just not a person who can know it all.

And once you unlock that ability to say ‘I don’t know,’ it opens up the second piece, which is asking for help. I talk to a lot of leaders who say if only I could get my new hire to ask for help, versus wasting that five or six hours trying to find it themselves.

One of the nice features about eddy, is the fact that you can ask eddy in Slack, ‘hey, I don’t know this,’ then eddy finds and asks someone for you. It is such a silly disconnect, yet it serves a very fundamental purpose.

And that’s what continuous learning allows, when you expect it in the organization, when you understand it's a collective knowledge base—not an individual knowledge base—and you’re going to learn every day you’re here, it’s easier to ask for help, it’s easier to say ‘I don’t know.’ We can move on quicker, faster, and more efficiently.

What excites you about working with Edify, what’s the biggest headline for you?

Ryan - Edify is absolutely a product that allows flexibility of use. I think it’s more of this multi-tool. Through its path builder, from the different paths that you can construct, the different ways you can engage with others, allows you to adapt to a lot of situations and compliment the other elements [of onboarding].

One of the fundamental core development concepts within Edify was engineer enablement, with a specific emphasis on onboarding. I certainly have never found a product that has done that. 

When you look at the way Edify meets engineers in Slack where they want to be, when you look at the idea of having template-tized pathways that can be customized by role, by manager, by month, by day, by week. And can be scaled from one day to many, many days, and [the tools] can be used for existing hires, and mergers differently.  

And then, there’s a really nice empowerment of letting the new hire engage and guide their experience, saying [to eddy] I’m ready to move on, I have a question, I want help, introduce me to someone.

For all those reasons, I was like, finally a product that can scale onboarding! That can help the program live and deal with turnover in the onboarding team itself – which is a huge problem for these organizations. Edify helps with all of those things, and there’s a lot more to be built on top of it. 

I do believe that the future of Edify is clearly going to be like: ‘What do you use for onboarding?’ ‘Edify of course. What do you use?’ ‘Oh yeah, Edify, that’s the tool.’ The same way we treat Slack now, it is one of the most standard ways we engage and share knowledge in the technical world, which should be Edify for onboarding technical talent.

 I think that anyone who is serious about onboarding and cares about their talent having a great experience technically, they’ll be like of course we want to use Edify, it’s a no-brainer.


Like this post? Share it!