The Art and Science of Onboarding

(upbeat electronic music) - Thank you for having me today.

Again, my name is Ted Tencza, I'm head of engineering at Prospa.

I wanna talk to you guys today about the art and science of onboarding, specifically bringing on new hire developers. That's where my interests really lie.

And so, but it can be adapted to other talks, or to other positions, but this one's really gonna be focused on developers and people in the technology space. I feel like I can skip this slide.

I'm gonna talk all about it.

20 years, 13 years in leadership.

My last companies.

I've been heavily involved in either creating or significantly modifying the onboarding processes at those environments. So at Prospa, before that Finder, Bigcommerce, Atlassian, thanks for stealing my slide, Emma.

And yeah, Dom, I know that's the wrong logo, but that's what it was when I was there, so I'm stickin' with it.

So, why even bother with this? Why do we care about sort of onboarding? What's the point of doing it? Well, quite honestly, I mean, when we think about it, hiring is really, really expensive. You've got, not just in money, but in time and investment.

You've got you know, interviews.

You've got all these other things.

So when you bring someone on board, you want them to become productive, and happy as quickly as possible.

You've made that investment in it.

But not only that, you can also benefit from it in ways, for your organisation, not just the individual employees. Probably most of you have seen, when somebody starts at a new job, if they have a really great experience, they've got that picture of their first day desk. And they tweet about it.

And it can become a recruiting tool.

It can help you get other people.

Into your organisation.

You can get referrals.

You get people productive more quickly.

And, you prevent that negative, sort of experience that can actually impact the rest of the team. Where you get somebody comes in, thinkin' they made a mistake, and just drags the whole team down.

Which you really want to avoid.

So it's a really good opportunity to sorta set the stage. Now, what are we talking about, when we're talking about onboarding? What we're not talking about is sort of the HR, bring 'em in, you know, give 'em the policy handbook, and find out what their TFN number is, or anything like that.

That's a solved problem.

We don't need to worry about that.

What we're talking about is organisational socialisation. In other words, we're talking about bringing up and getting new hires aligned with the organisation's culture and strategy as quickly as possible.

Helping them to adjust to the social and the performance aspects of the new job. And helping them do it quickly, and helping 'em do it pretty smoothly.

And Lady Natalya Buyer, Bauer, wrote a really great article on this, called, "Onboarding New Employees." And what she talks about, she talks about the different levels of onboarding. So these are the ways you can sort of grade where your onboarding system is, or programme is. And the easiest one, and the one that most companies have, is simply this.

Compliance.

Rules and regulations, you have to check their paperwork, when they show up on the first day.

But then you wanna go beyond that.

You wanna talk about clarification.

And in that, you can help the new hire really understand their role and their responsibility in your organisation.

What are they gonna be up to? What kind of things they're gonna be working on. Yes, you might've covered a lot of that during the interviews, but this is a way to get to 'pecific.

A lotta times in interviews, you won't maybe know exactly which team they're going on, or exactly which project they're going on.

Here you can sort of get them started on that, and what they're gonna be working on.

The next one, next level up, is start talking about the culture.

What's your organisation's personality and values? And how do you get the new hire sort of bought into that and contributing to it? And helping evolve it.

Again, sort of, we'll talk a lot today about culture and how it should evolve and become even greater. But if the new hire doesn't even know what the culture is, there's no way they can try to help advance it or improve it.

And finally, what you really wanna aim for, is when you get a connection with that new employee. So they come onboard, and they start to understand, and to get a relationship with the existing staff. Very, very quickly.

You know, they maybe find out who their supervisor is, and who their super-supervisor is, and who they may be supervising.

You know when I get hired nowadays, I come on and I end up with a bunch of direct reports right away.

So getting to know them really quickly.

As part of that onboarding process.

And so that's what you really wanna strive for. Those, are those levels in your onboarding. So, how should you get there? Well, we when I first started thinking about this talk, I was thinking about, well I started the Atlassian onboarding programme, called the Developer Boot Camp.

I thought it was pretty successful.

And I'll just tell people about that.

And prescribe that as what you should go back and do in your organisation.

But that would've been really, really disingenuous, because I've gone on to three organisation since then, and I still don't use Atlassian's onboarding programme at the new ones.

Because you can't just copy and paste culture from one organisation to the other. I was at a talk once, senior Spotify engineer was adamant that Spotify doesn't use the Spotify model. Right? You can't use the stuff I did at a previous organisation just, and just copy and paste it in your organisation, it's not gonna work, they're different.

They have different goals, they have different values. So, I was inspired by an article I read by Joel Spolsky, a number of years ago, where he started asking all these questions, and he called it the Joel Test. And it was basically a way, to think about, you know, how's your production systems work, can you deploy with a single click, can you, you know, build all of your stuff out of a single repo? And, I don't even remember what all the questions were, but the point is, is that, regardless of what you are working on, you could ask yourself these questions, and sort of find out where you're going. So, with that, I've decided to come up with the Ted Test. 10 questions that you can ask yourself, eventually I'll get it trademarked.

Ted Talk was already taken.

So, the first question.

Do developers have equipment, access to systems and accounts created before they start? You, as I said earlier, you've invested a lot of time, you've invested a lot of effort, getting a new hire in.

And, I'm sure you've all heard horror stories where they show up and they don't even have a computer. Right, their desk.

They don't have a desk, in some cases.

You know, they're set down in the reception room waiting for somebody to show up.

And it really sets a really, really bad first impression. You'll get a lot of even buyer's remorse, people goin' like, "why the heck did I join this company?" And that can be really bad.

You've spent the time, you've spent the effort, make that thing come in, make the new person come in, and have everything set up on their desk, ready to go. Now, go beyond that.

Also have all their accounts set up.

It doesn't do them any good to spend the first half of the first day, setting up their GitHub accounts, setting up their email accounts, setting up this, that, and the other account. It's just, there's no value to it.

Have all that stuff ready to go when they walk in the door, and move on to more important things.

The other thing you can do is, then you can use this to sort of put a lens back on your own organisation.

As you're going through, and you're setting up all of these accounts, do you still use 'em? Do you still need 'em? It's a really good way to reflect back on yourself and your own organisation, and figure out, you know, are these the kind of things that you need? Does your company have a specific list of goals to accomplish for the onboarding? Now, this sometimes gets confused with, do you have a specific list of tasks that you wanna accomplish? And that can be pretty straightforward.

You wanna do x or y, or whatever.

But the real important thing is, you want a list of goals. Why are you doing these? You know, it's a really good way to sort of say, "these are the things I wanna get done with this particular onboarding programme." When I started the one in Atlassian, we had a series of libraries, it was called "Common Modules." And it was an absolute mess.

Nobody wanted to touch it.

Everybody was afraid of it, because it touched a couple different applications, and nobody wanted to be blamed for breaking something outside of their own silo.

So what I did is, I wanted to break that down. So I made the new hires, one of their first activities, was they had to fix a bug in that Common Modules library. And that accomplished the goal of then, one, making sure that they weren't afraid of it. And two, getting them to talk across the different teams, and across the different silos.

So that they got, sort of that socialisation started really early, even though it was done in a very technical sort of way.

And then share it with them, share the goals. There's no reason to be coy about it.

You know, create a Confluence page, or whatever sort of, whatever your sharing mechanism. And tell them the goals that you're trying to get them to accomplish.

So that way, as they're doing these tasks, they can tailor it to what they're trying to accomplish. Do the goals explain and re-enforce the company missions and company values? This is really important, right? It's not just good enough to have goals.

You want those goals to you know, advance what you're trying to do with your culture, with your mission.

How many people here work for an innovative company? Yeah, I know, every single person.

Happens every audience.

How many people here will let the new hire pick out or totally invent a new feature, and push it out to production to test it? A lot less hands just went up.

So, are you really that innovative? It's a good way to, again, reflect back on your own organisation.

What do you, what is it doing? If you, at Prospa, we have a value that's obsessed about the customer.

So, when we get the people, a new hire's come in, we have them sit upstairs, with the agents and listen to our customers talk about what they need and how they use it.

And if we, we got a little bit of pushback, saying, you know, well the developers are really busy. I'm like, "yeah." But if they're busy doin' the wrong thing, it doesn't matter.

Let's live our values, and have them do that. And learn.

So, are the people involved active members of the team trained on how to deliver the information? And I don't mean, the HR team.

There are so many organisations that have sort of a learning and development sorta team, that then wants to take over and kind of do all of these trainings.

But if you have your HR person come in and teach, you know, system architecture.

Or principles in engineering design.

It's not gonna work.

The other thing that this does, is you don't just have, you know, your senior engineer come in and do it.

One of the things that I find most depressing about the tech industry, is we take developers and after sort of five to seven years, we automatically assume, we just grant them all these skills that they don't have.

So after five years, all of a sudden, presto, without any training, you can interview, you can lead a team, you can give courses.

And that's just not the case.

So invest in your people that are already there, to make sure that they can deliver this information effectively, and it also gets them a new skill. You know, from what I understand, being able to speak up and you know, stand in front of a crowd, and talk is supposed to be a good skill that you're meant to have. We'll see how that goes.

The other thing is that when you're doing this, you can also use it, again, and I say this a lot, I keep going back, you know, going back to how it helps the organisation. You can use it to evaluate, sort of, the course material. You know, are you sittin' there, saying, "okay, hey, this is how we do our deployments at Prospa." And you go in there and you watch it, and you realise we haven't done deployments like that in four months, but nobody's gone through and updated the course material.

So you wanna make sure that you can use that when you're evaluating the people that are giving these courses.

And training them up.

Do developers have a fully functioning dev environment before lunch? Ideally, you should have one before they even start, but again, it just depends.

If you can't get a dev environment up before lunch, then you've got a whole host of other problems that you need to solve besides onboarding and those are, those are sort of a different talk. But it really does sort of reflect back on the dev environments themselves.

When I was at my previous location, at Finder, one of my goals was to have the developer build their own environment.

Or the task was have them build the own environment, the goal was so that way they would really understand that environment.

And so when I had somebody come through, and I was watching 'em do it, and I realised that so much of what they had to do to get it to work, were just like little tweaks, and things that they'd never have to do again. You know, downloading a specific MPM package. Or, you know, any one of a number of other things. And I realised there was absolutely no value in having this goal.

Because the dev environment, once it was up, was up and running, and it was fine.

And they didn't get anything from spending half a day trying to get it up and running.

So we changed the onboarding programme, and had the entire dev environment scripted, so that it was sittin' there, on their machine, ready to go in the morning.

Again, it depends on your organisation.

Do you need the developers to have that deep understanding and be able to build their own? Or do you have one that's just a script that they can run? So, it depends on what you need.

But don't do it just by default, have a reason for it. Do developers write and commit non-trivial code for production systems on the first day? Now, this is the one that I probably get the most amount of comments on.

The most amount of flack about.

You know, people tellin' me that, you know, in their particular organisation, you know, that's all well and good for a startup, but in their particular organisation, you know, they launch once every three months, and so they can't get it in to production right away. Once again, that, to me shows that you've got a whole host of problems that you really need to focus on solving. But, I think the important thing is, you wanna at least get them committing code. Even if you can't get it to production, which you really should try, even if you can't. You want them getting code into whatever your pre-production environment is, right away. And there's a number of reasons for this.

First of all, is it gives them a good idea of what your deployment systems look likes, maybe even some of what the libraries are.

Things like that.

So, you know, you can, you learn something. The second thing is, it helps them feel productive on that first day.

You know, as engineers, we like to solve problems. We like to feel like we belong.

And you don't want to feel like you're a drain on the team. And if you come in and it's two weeks before you're even looking at the code, you don't feel like you're a developer at the moment. So you wanna come in, you wanna be able to contribute to the team, be productive, have that sense of accomplishment, that sense of just having that celebration of a win, as you go in.

For us, at Prospa, the other thing that it does, is it sets up the expectation you know, that they know now that they can release something once they get it, you know, code complete, and test it.

So they don't have to wait for you know, a monthly release cycle or something like that. And even more importantly, it sets up the expectation that now they know they're required to get this thing live once it's done.

Because when it's just sitting in your machine, it doesn't have business value.

And our value at Prospa is, deliver value.

So, are the developers instructed with hidden and institutional knowledge early on? What I mean by this, is simply the fact that in many places you've got so much sort of, knowledge that's ingrained into the team.

And a lot of people hold it close to the vest. Because that's how they feel like they can deliver value. That's a really unhealthy culture to have.

So, you wanna have it very open.

The other thing is it helps to reduce some of the confusion. You walk in and somebody says, "hey," you know, "the QB project needs a CD, work on the SOP." And they're goin' like.

(audience chuckling) You know, so we have a Confluence page, it's a glossary.

And it just has a list of every single thing on there, and if a new hire is shown that page as part of their very first day, the induction page. Here's a list of everything you're gonna hear. Come back and find it.

That also helps us keep it up to date.

'Cause if they hear something that's not on that list, they add it.

And so we get it up, and so it generates for the next people.

Do developers have a designated person to go to for help? As engineers, a lot of times we don't like to interrupt other people, we know how hard it is to get back in the zone.

You want to make sure that that person says, "go to this particular person.

They have had their workload reduced, in order to help you get on board and be able to answer these kind of questions." Then, actually reduce that person's workload. Don't give them the super critical thing that has to be launched on Friday.

Because then, every time, they're gonna walk up, the person's just gonna like run into a meeting room and hide.

And you really don't want that.

Is the programme mostly, you know is comprehensive and mostly uniform? Comprehensive, you wanna make sure you're accomplishing a lot of your goals.

Getting the stuff across the line.

Mostly uniform.

Especially if you've got distributed teams, you don't want, like in your headquarters, everybody gets to go to lunch with the CEO, and at the remote teams, you just say, no that's, CEO's not there so you don't get anything. Like try to, it's obviously impractical for the CEO to fly to every single location every single new hire.

But maybe do a slack call, maybe you'll have lunch with the local GM.

You wanna try to have like for like.

And you also wanna try to make sure that your senior and your juniors are doing basically the same thing.

They can be, the piece of code that they do on the first day can vary much in complexity, but they still should both be pushing code, on that first day.

And finally, is the new, improved with input? As agiles, we wanna have that retrospective. As Dom was saying in his talk, you know, it can be really, really confronting. When I was doing still Atlassian, one of the things we said was that everyone had to give an example of how to improve it.

And I thought that this would be a really good thing, right? 'Cause they tell me some tweaks and things that I could do to improve.

And they were telling me things like, "this part of it sucks." And I was like, "but I like that part." (laughter) And you get really defensive.

You have to let that go.

It can also be challenging.

One of the things I got was I had two people going through at the same time, and one of 'em's suggestion was make it longer, and the other was make it shorter.

So we made it self-paced, so it was longer and shorter at the same time. There's always a solution.

And they also, they get there with fresh eyes, and they can really help you.

So, a couple of stats, real quick.

They've done this, ClickBoarding, a company in Minnesota.

69 of employees are more likely to stay, and they're 58% more likely to be with the organisation after three years, if you have an effective onboarding programme.

If they come in, and if they enjoy it.

And finally, I'd like to answer this question in one more way.

So, one of the reasons why is because it gives us sort of happy, engaged, productive employees. And as leaders, and as people who care about culture, isn't that what we want? I think it is.

So I think, spending the time to really develop and build out your onboarding programme, to me, it's just the right thing to do.

So, thank you.

(applause) (upbeat electronic music)