Hiring Juniors

(upbeat music) (audience applause) - All right, so we're on, I guess.

I'm the middle talk in the kind of morning session, and I noticed on the speaker schedule probably last week that there was an S after my last name.

(audience laughs) And this has been an on going issue.

I remember my grandfather ranting and raving, said the bank, the bank wouldn't let me open an account because they had, or wouldn't let me close the account because they had S, and my driver's licence didn't have the S.

And I'm like, this is a big kerfuffle about it. And I was like oh, that's a bit weird.

And I was like oh, silly old man, ranting and raving about things.

And then I started getting emails about structural engineering, and I thought maybe he was actually on to something. So I receive emails from them.

I'm not sure if they received my emails, but if there's anyone in here who knows someone who works at that company, can you let them know? So I'm Ryan Bigg.

On the side of what I do, I write books.

I've sold about 15,000 copies.

I'm not here to talk about my books today, I'm here to talk about the Junior Engineering Programme and about hiring Juniors.

So on that front, I have mentored Juniors, I've been mentoring Juniors for 10 years now. It's been a long time.

I've been teaching youths who have gone on to become Lead Developers at tech companies that you probably know about, which I think is pretty good. But at the same time, I've also mentored Juniors that have quit the industry all together.

So whether or not you should be following my advice, I'm not actually sure about (chuckling) at this moment. But recently I've spent about the last 10 months recruiting, hiring and training up Juniors as a part of the Culture Amp Junior Engineering Programme. And today I've got some things about that process to share with you.

Today I'm gonna tell you about that Junior Engineering Programme.

Why I think hiring Juniors is absolutely the right move, by way of a short story.

And finish up by sharing some tips about what you can do with the Juniors that you're going to hire soon. You'll be please to know that there is absolutely no subliminal messaging in this talk at all.

(audience laughing) There'll just be some plain speaking from yours truly. Because mentoring Juniors is something that I'm really passionate about, and I'm hoping today that some of that passion would rub off on you.

My goal, of course, by the end of this talk is to convince you to hire mentored Juniors at your own companies.

So let's start with the Culture Amp Junior Engineering Programme.

At Culture Amp we decided we would run this structured programme for Juniors as a way of teaching Juniors the skills that are relevant to our industry today.

This is kind of like the antithesis of a university computer science course, because there's not a line of C or Java in sight. The idea behind this programme is that over time we'd be able to bolster our best and brightest with some new faces that could help us out. We ran this programme for the very first time for six months, from November last year until June this year. Before we started this programme, we had five Juniors already working here at Culture Amp. And then we hired another five on top of that, for a total of 10 Juniors across the company. And we put all of the Juniors through this same programme. As you can see from the slide, there's a mixed bunch of fresh faces here but what you can't see from the slide is that they all come from different backgrounds. Not all of them have computer science degrees, or have even worked in IT as a primary industry. An interesting artefact of our hiring process is that seven out of 10 people on this slide are women. That's an artefact of our process, not a target. Which I think is pretty cool.

Just as a comparison to how fresh these people faces are, all of them have a much fresher face than what I had as a Junior developer.

This was before I learned what shaving was. (audience laughing) In the Junior Engineering Programme we taught these 10 developers the foundational skills they needed to be confident and capable developers within our tech stack.

We taught them Ruby, we taught them Rails, we taught them two different kinds of databases relational and document.

We taught them a whole suite of JavaScript tools, and all of this within six months.

They now know these things and a hell of a lot more. During the programme the Juniors worked part of the time with me learning this tech stack.

And part of the time on a development team fixing bugs and delivering features.

This split between educating and real world work experience was designed to give Juniors the opportunity to be taught these skills, as well as a chance to get that real world workplace experience that everyone so craves when they're hiring somebody. This in my opinion is absolutely the best of both worlds. On one hand, they need the training.

But on the other hand, they also need that real world experience in order to be truly effective. We chose to run this structured programme at Culture Amp because it would allow us to train a bunch of people all at the same time, all of the same skills. This would also mean that they could support each other throughout the process, because if we brought on only a single Junior, it would really feel like the Junior verses the world type scenario.

I'm sure you've probably worked at organisations like that, you have a team of Seniors and you bring on a Junior, and the Junior's like oh shit, what happened? This can feel quite intimidating, I think for a Junior. And kind of disheartening too.

This is not the experience that we would want anyone, Junior or not, to have a culture in.

So we brought them on all together.

During this programme we really encouraged the Juniors to succeed and to grow their skills together as a group. Despite whatever struggles they may encounter individually. This shared pain aspect of the struggle as a Junior is important, because it makes them feel comfortable about being in a position where they don't know all the answers.

This is what a Junior encounters all the damn time, and somebody else is also in that same position, not knowing the answer with them.

The idea behind it is that they can get together like this, and puzzle it out together.

If they got stuck, there was still a support net of knowledgeable people, the other people in the organisation who could help them out.

So hiring a bunch of Juniors and running them through the Culture Amp Junior Engineering Programme worked extremely well.

The Juniors that we hired in November are now confident and capable members of our teams who have helped shape real world software that thousands of people use daily. We are extremely proud of what our Juniors have been able to accomplish is half a year, and look forward to seeing what they can accomplish in the future.

In fact, the programme was so successful that we're going to be running it for a second time, real soon now, which is pretty awesome I think. Now that's just how we've chosen to do it at Culture Amp, but really a structured programme that hires cohorts of Junior developers every six months, isn't the only way to train juniors up at a company. You don't need to be a large, established organisation. And you don't need to run a structured programme to be able to hire and support a Junior.

I think if you've got four Seniors within you organisation, your next hire should be a Junior.

Because as long as you've got someone within that group who can dedicate some time to supporting a Junior, you can do it.

And it's not like it's exactly hard to hire a Junior at the moment either, you don't even need to go to a recruiter to do it. Just walk passed someone on the street, guaranteed they're a Junior developer.

(audience laughing) But why, why would you wanna do this? Like why would you put yourself through this? Won't Juniors slow down your team dramatically, leading to those precious productivity losses? Think of all the shipping that should have been done instead of mentoring the Junior.

Well yeah, productivity losses are gonna happen when you hire a Junior, that's unavoidably true. But on the day that you hire them, they will do it, yeah. And the day after that too, and the next week. But over time and with mentoring they will improve, believe it or not, and their productivity will be even better than before. Now I admit this point isn't really a great one, with a lot of evidence to back it up.

It's kind of like, this is how I feel, good luck. So I have a greater one to make.

One great side effect of hiring and working with Juniors is that everyone else on the team will get better too, at what they're doing, because they're now working with this Junior. And it will be almost instantaneous.

Well, not quite instantaneous in the natural sense of the word.

It'll take like a week or two, but they will get better really soon.

This is because mentoring Junior developers forces the people during the mentoring to slow down and methodically explain their thought process. It makes them think of things and explain them in different and usually better ways.

They have to practise really understanding something and being able to explain it someone who doesn't yet know it.

And sometimes they might even find out that they thought they knew something, when in fact they didn't know it very well at all. Mentoring Juniors is quite humbling in that regard. One of my favourite stories around this point is about what happened on a team of mine when we hired a Juniors.

This is back when I was a Senior developer at Culture Amp, which is was long before the Junior Engineering Programme. At the time we were building a new microservice, as was and still is the cool thing to do.

Right, right, yeah, no? Silence, I have no idea.

For extra street cred, this microservice is even event sourced and written in Ruby on Alexa. My team that was building this microservice would often talk about it in really high level terms. Because the team was quite senior heavy, look at how smart we are, yes look at how smart I am too. We knew what we were talking about, or at least we pretended to do so because we had those big Senior developer egos to protect. When the Junior joined, they asked a lot of questions about the microservice. A Junior is like a question machine.

They just spit them out.

It's like when you're playing tennis, you know those machines you put the balls in and it spits them out rapid fire? It's like that, with questions.

It's cool, it keeps us on our toes.

In our team we tried our best to answer these questions. We tried explaining things to them using the jargon that we had all collectively built up, and it didn't work. We tried again using different jargon that maybe they'd understand, it didn't work. The Junior was still horribly confused.

So we ended up drawing a diagram of these two systems, our monolith and the microservice, indicating the different parts that were involved. It was this little thing, nothing too complex. We stuck it on a wall in our team area and gave the Junior a copy on their desk as well. This actually worked.

The Junior wasn't confused anymore.

The Junior was able to look at the diagram and the figure out how these two systems work together. They understood what our jargon meant because it was labelled very clearly on the diagram. But then shortly after this a really, really funny thing happened.

The Seniors started using the diagram more and more. We talked about this microservice a lot, but when we did we involved the diagram in those discussions. This is the diagram that we built for the Junior, but the Seniors were using.

We used terms that were listed on the diagram rather than our own words for it.

We even redrew the diagram as our system morphed and changed.

We, the Seniors, ended up using the diagram more than the Junior did.

By having this Junior join our team, we very soon realised that one of our blind spots was how we communicated about how we built this microservice and how it was constructed.

The Juniors' joining led to the creation of the diagram, and lead us all to communicating more effectively about everything.

Ultimately, it made us a better team.

This is just a small example, but I think quite a good example of the kind of benefit that hiring a Junior brought to a team that I was part of. Now wouldn't you like this kind of thing in your teams too? This one simple trick that I have to share today to make your teams better, is to introduce a Junior into that team.

And then to have the team mentor them.

I have personally seen this improve teams again and again.

It will work for you too, and if it doesn't you have my money back guarantee. So please, hire at least one Junior.

Because I know from my experience and the experience of teams at Culture Amp that it has most certainly made our teams better and it will make your teams better too.

So now that I've utterly convinced you 100% to hire a Junior.

Okay, put away your phones, stop hiring the Junior. I wanna talk about what you can do with them once you have them.

It's kind of like you get a puppy and you're like, okay, puppy is a great idea, now what? Okay, a bit scary.

It's really scary in fact, it's terrifying, thank you. But I have three easy tips that can help you. My first tip is to assign a mentor.

I know it sounds easy, it's not.

In order for Juniors to grow into amazing superstar developers that we want them to be, we must provide them with the mentorship and direction that will get them there.

Juniors are going to need a lot of love and attention. You can't just put them in a corner and expect them to thrive, it just won't work at all. Think of the Junior more like a puppy than a cactus. A puppy needs love and attention and some training in order to become an amazing loyal dog, or whatever. But the cactus, this analogy quickly falls apart, doesn't it? (audience laughing) I'll keep going.

But the cactus only sunshine and some water. The cactus is indifferent to your love, your attention or the intensity of the training you provide. In short, cacti are just gonna cacti.

You can put them in a corner, they'll keep thriving, whatever.

Junior developers don't grow into Senior developers with just sunshine and water.

My job would be so much easier, right? Go over to the window where the sun is, put the Junior developer there and spray some water on them. Done, I would then go home.

I would work for half an hour, I'd put all my Juniors in a row where they'd get the most sunshine, water them and then go home.

And I'd still be paid as much as I am today. That would be nice, but it doesn't work that way. What Juniors need actually, is they need mentorship, and they thrive on direction, so give it to them. At Culture Amp we provide this mentorship by pairing each Junior with a mentor within Culture Amp from day one.

This is someone who's been at the company a while and can show them the ropes.

This mentors job is to work with the Junior in order to grow their skill set and grow them as a person. They do this by doing things like setting goals together, reviewing feedback they've received.

Whether that be in person, or around personal skills, or around code or wherever.

And other activities doing things like weekly one-on-ones. While the Junior is on a development team, the team supports them by pairing them up with a Senior developer who could help them work more effectively on that team and to skill them up on whatever the team needed. We assign people this mentoring and pair them up within teams because we wanted the Juniors to feel ultra supported at Culture Amp.

We wanted their experience to be one of overwhelming positivity, because being a Junior is already hard enough. And I want you to do this within your organisations too. I want your Juniors to have a single point of contact at least.

Someone who can be around for the Junior.

I want you to have weekly check-ins with the Junior to set professional goals with them.

Actively seek out feedback about how they're going and work with the Juniors on these things within that feedback, and support them as much as possible.

The Junior is going to need the support.

Remember my horrible analogy? Puppy not cactus.

My second tip is to tell your Juniors that it is always okay to ask questions.

And to repeat this absolutely as much as possible. If you have a Junior who rarely asks questions at your organisation, really enforce with them that it's okay to be asking these questions. Because if a Junior is asking questions, it means they are looking for answers.

And if they're looking for answers, it means they want to know something.

So take that opportunity to teach them.

Along side this, pay attention to what the Juniors are doing.

Ask them if they need any help or assistance. Maybe see if they're looking uncomfortable, sad or angry, or any other negative emotion.

I don't have enough pages to list the negative emotions a Junior could possibly be feeling, but it's a long list.

Sometimes Juniors can be too afraid to ask questions because they think they're stupid questions. Reinforcing with them that it's absolutely okay to ask questions and it's always okay to ask questions, gets them to open up, and ultimately helps them to feel supported. My third tip is that small wins matter.

When a Junior joins your organisation, they're going to have a huge dose of impostor syndrome. The question that's gonna go around and around in their head is why did they hire me? I know nothing.

You need to start chipping away at this immediately. And the best way to do this is to give them wins on the board as soon as you can. These wins act as opposites to the feelings of impostor syndrome.

Impostor syndrome is saying you are not good enough. And the wins are saying you are good enough. Get them to do things like fixing typos, investigate bugs, dive deep into the source to figure out things, and encourage them to drive this effort as much as humanly possible. They'll feel better about these things that they were able to accomplish on their own. With this cushion them when they fall, celebrate with them when they succeed, and chip away at that impostor syndrome piece by piece and day by day by providing them with these small wins. Later on you can make them up to bigger and bigger wins, but for now in the early stages, small wins are absolutely critical.

So ultimately your mentorship should be about making the Junior feel welcome and safe within your organisation.

You probably sense this is a theme to my points already, but I wanna take the last few minutes of this talk to really, really drive this point home.

In fact, feeling welcome is what everyone should be having. The feeling of being welcomed is what should be happening with everyone on your team.

Don't just take my word for it though.

Google ran a study called Project Aristotle, where they attempted to find out what made an effective team.

They interviewed hundreds of their own employees and they came up with five things that effective teams had consistently.

Here they are.

Psychological safety, dependability, structure and clarity, meaning and impact.

The number one item on this list isn't feeling welcome, but psychological safety, which is essentially the same thing.

The text underneath says, team members feel safe to take risks and be vulnerable in front of each other. This is the number one thing you should be encouraging your Juniors to do, take risks and be vulnerable. It is how they will grow as people.

Juniors should ultimately feel safe to take risks and to be vulnerable in our teams and our organisations. Juniors will make mistakes, this is the nature of taking risks.

And they will mess up from time to time.

Ask me about that time that I dropped a production database as a Junior.

That was a learning lesson.

Give these Juniors space to make mistakes.

It is absolutely how they will learn best.

But the remainder of this list must not be discounted either.

Dependability, structure and clarity, meaning and impact are all important.

A Junior must be able to depend on the people around them for support.

They must be reminded that it is always okay to ask questions.

Take my slide, print it out as big as it was here and put it on a damn wall if you have to.

They must have people around them for that support, who they can turn to and ask these questions of. They must have clarity on what the direction is, and you can provide that with some solid mentoring and those weekly one-on-ones.

Work together with your Juniors to set some goals for them during these one-on-ones.

And help them work towards the goals.

Gather up some feedback from their peers and talk about it with them.

Try and drive actions from that feedback.

Juniors must feel like they're contributing back to a greater whole to keep them motivated and enthusiastic about what they're doing.

Give them meaningful work to accomplish and to celebrate with them when they finish it. You can start with those small wins, but work them up from there into bigger and bigger wins. Chip away at that crap impostor syndrome, be their champion. When you hire a Junior developer please keep these things in mind and ask yourself regularly if you're following along with these.

These things should underpin everything you do with everyone in your organisations, but especially Junior developers.

With a concerted effort to make the Juniors feel psychologically safe and some semi-structured mentoring in place, they can grow into the future's most brilliant developers. So let's hire and mentor Juniors at all of our companies so they become the next generation of amazing developers. Thank you everyone.

(audience applause) (upbeat music)