Hiring Juniors

This is a story about hiring juniors, why we should do it, and what things I’ve learned from hiring a bunch and mentoring them.

(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)

Here are my raw speaker notes for my Web Directions Code Leaders talk, titled “Hiring Juniors”. The video will be online later.

The slides for this talk are available here on Speakerdeck

Intro

[slide]

Hi, I’m Ryan. You know that part already. What you might not know is that I’ve been mentoring juniors on-and-off for close to a decade now and I’ve had varying rates of success.

I’ve mentored juniors who have gone on to become lead developers at tech companies you’d probably know about.

But, at the same time, I’ve also mentored juniors that have quit the industry altogether.

Recently, I’ve spent about the past 10 months recruiting, hiring and training up juniors as a part of the Culture Amp Junior Engineering Program and today I’ve got some things about that process to share with you.

Today I’m going to tell you a little bit about our Junior Engineering Program, why I think hiring juniors is the right move — by the 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.

[slide]

You’ll be pleased to know that there is absolutely no subliminal messaging in this talk at all. It’ll be just some plain speaking from yours truly.

Mentoring juniors is something that I am really passionate about and I’m hoping today some of that passion will rub off on you. My goal for the end of the talk is to convince you to hire and mentor juniors at your own companies.

Culture Amp’s Junior Engineering Program

[slide]

So let’s start with Culture Amp’s Junior Engineering Program.

At Culture Amp, we decided we would run a structured program for juniors as a way of teaching juniors skills that are relevant to our industry today. This is kind of like the antithesis of a university computer science course. Not a line of C or Java in sight.

The idea behind the program is that, over time, we would be able to bolster our best and brightest with some new faces who could help us out.

We ran our very first Junior Engineering Program recently, for 6 months — from November last year until June this year.

[slide]

Before we started this program, we had 5 juniors already working at Culture Amp, and then we hired another 5 on top of that for a total of 10 juniors across the company. We put all of our juniors through this program.

These are a mixed bunch of fresh faces all with varying backgrounds. Not all of them have CS degrees, or have even worked in IT, for instance.

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

[slide]

In the Junior Engineering Program, we taught these 10 developers the foundational skills that they needed to be confident and capable developers within our tech stack. We taught them Ruby, Rails, two different kinds of databases and a whole suite of JavaScript tools, all within 6 months. They know these things and a lot more now.

[slide]

During the program, the juniors worked part of the time with me working on learning this tech stack, and part of the time with one of our development teams, fixing bugs and delivering features. This split was designed to give the juniors the opportunity to be taught these skills, as well as a chance to get some real-world workplace experience. The best of both worlds. On one hand: they need the training, but on the other they also need the real-world job experience in order to be truly effective people.

We chose to run a structured program because it would allow us to train up a bunch of people all at the same time, on all the same skills. This would also mean that they could support each other throughout the process. If we brought on only a single junior it would be a “The Junior vs The World” type scenario, which can feel quite intimidating and disheartening. This is not the experience we want for any one, junior or not, to have at Culture Amp.

During this program really encouraged the juniors to succeed and to grow their skills together as a group, despite whatever struggles they might encounter. This “shared pain” aspect of the struggle is important: it makes juniors feel comfortable about being in a position where they don’t know all the answers, and someone else also doesn’t know the answer with them. They then could puzzle it out together. If they got stuck, there was still a support net of knowledgeable people who could help them out.

Hiring a bunch of juniors and running them through the Culture Amp Junior Engineering Program worked extremely well. The juniors that we hired in November are now confident and capable members of our teams who have helped ship real software that thousands of people use. We are very proud of what our juniors have been able to accomplish in just half a year.

[slide]

In fact, the program was so successful that we’re going to be running it for a second time… real soon now.

Juniors makes your team better

Now that’s just how we’ve chosen to do it at Culture Amp but a structured program that hires cohorts of junior developers every 6 months isn’t the only way to train juniors at a company.

You don’t need to be a large established organisation, and you don’t need to run a structured program to be able to hire and support a junior.

[slide]

I reckon if you’ve got at least 4 senior developers within your organisation, your next hire should be a junior. 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 hard to hire a junior at the moment, either.

[slide]

But why would you want to hire a junior? Won’t juniors slow your team down dramatically, leading to precious productivity losses? Yes, that is unavoidably true. On the you day you hire them, they will do that. And the day after that too. And the next week. But over time, and with mentoring, they will improve and productivity will be even better than before.

I admit that that point isn’t a great one with a lot of evidence to back it up. So I have a greater one to make.

[slide]

One great side-effect of hiring and working with juniors is that everyone else will get better at what they’re doing because they’re now working with a junior. And it will be almost instantaneous. Well, it will take a week or two, but they will get better.

This is because mentoring junior developers forces the people doing 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 practice really understanding something and being able to explain it to someone who doesn’t know it.

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 can be quite humbling in that regard.

The Junior, the Monolith and the Microservice

[slide]

One of my favourite stories around this point is about what happened on a team of mine when we hired a junior, back when I was a senior developer at Culture Amp. Long before the Junior Engineering Program.

At the time, we were building a new micro service, as was, and still is, the cool thing to do. For extra street cred: this micro service is even event sourced and written in Ruby on Erlang, oops I mean Elixir.

My team would often talk about the Elixir microservice in high-level terms because the team was quite senior-heavy. Us senior developers knew what we were talking about, or at least pretended to — after all, we all have big senior developer egos to protect.

When this junior joined, they asked a lot of questions about the microservice. We tried our best to answer these questions. We tried explaining things to them using the jargon that we had all collectively built up. It didn’t work. We tried again using different jargon. It still didn’t work. The junior was still terribly confused.

So I ended up drawing up a diagram of the two systems, our monolith and the microservice, indicating the different parts that were involved. It was this little thing.

I stuck it on a wall in our team area and gave the junior a copy too. This worked! The junior wasn’t confused anymore. The junior was able to look at the diagram and figure out how the two systems worked together. They understood what our jargon meant because it was labeled clearly on the diagram.

But then a really funny thing happened. The seniors started using the diagram more, and more, and more. We talked about the micro service a lot, but when we did we involved the diagram in a lot of those discussions. We used terms listed on the diagram rather than our own words for it. We even re-drew the diagram a few times. We, the seniors, ended up using the diagram more than the junior did!

By having this junior join our team we soon realised that one of our blindspots was how we communicated about this microservice. The junior’s joining led to this creation of “The Diagram” and led to us all communicating more effectively about this microservice. Ultimately: It made us a better team.

This is a small example, but quite a good example of the kind of benefit that adding a junior brought to team that I was a part of.

[slide]

Now wouldn’t you like that kind of thing in your teams? The 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’ve seen this improve teams again, and again. It’ll work for you too. You have my money back guarantee.

[slide]

I want you to 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. It will make your teams better too.

My three tips

[slide]

Now that I’ve utterly convinced you 100% to hire a junior, I want to talk about what to do with them once you have them. This is the scariest part, but I have three easy tips that can help you.

Mentorship

First tip: Assign a mentor.

In order for juniors to grow into amazing superstar developers, you 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 the corner and expect them to thrive. It won’t work!

[slide]

Think more of them like a puppy than a cactus: the puppy needs love and attention and some training, but the cactus needs only sunshine and some water. The cactus is indifferent to your love, your attention or the intensity of the training you provide. Cacti are going to Cacti.

Junior developers don’t grow into senior developers with just sunshine and water. And they don’t do it just by practicing development by themselves, either. They need mentorship and thrive on direction! So give it to them!

[slide]

At Culture Amp, we provide this mentorship by pairing each junior up with a mentor within Culture Amp from day one. This is someone who has been at the company a while and can show them the ropes. The mentor’s job is to work with the junior to grow their skill set. They do this by setting goals together, reviewing feedback they’ve received and other activities during weekly 1-on-1s.

While a junior is on a development team, the team supports them by pairing them up with a senior developer who then could help them work effectively on that team and skill them up in what the team needed.

We assigned people this mentor and paired them up within teams as we wanted the juniors to feel super-supported at Culture Amp. We want their experience to be one of overwhelming positivity because being a junior is already hard enough.

I want you to do this in your organisation too. A single point of contact. Someone who can be around for the junior. I want you to have weekly check-ins with the junior and set professional goals with them. Actively seek out feedback about how they’re going and work with the junior on things within that feedback. Support them as much as possible.

[slide]

The junior is going to need this support. Remember: puppy, not cactus.

It is always ok to ask questions

[slide]

My second tip is this: tell your juniors that it is always OK to ask questions. Repeat this as much as possible.

Or, if you have a junior at your organisation who rarely asks questions, really re-enforce with them that it’s OK to be asking questions. If a junior is asking questions it means that they’re looking for answers, and if they’re looking for answers it means they want to know something! So take the opportunity to teach them!

Alongside this, pay attention to what juniors are doing. Ask them if they need assistance at all. Maybe see if they’re looking uncomfortable, sad or angry. Sometimes, juniors can be too afraid to ask questions because they think they’re “stupid” questions. Asking juniors if they have any questions gets them to open up, and helps them feel supported.

Small wins matter

Third tip: Small wins matter.

When the junior joins your organisation, they’re going to have a large dose of Imposter Syndrome. A lot of “why did they hire me? I know nothing!”. You need to start chipping away at this right away and the best way to do that is to give them wins on the board. These things act as opposites to the feelings of imposter syndrome. Imposter syndrome is saying “you’re not good enough” and these wins are saying “you are good enough”.

Get them to fix typos, investigate bugs, dive into the source to figure out things. Encourage them to drive this effort as much as possible. They’ll feel better about things they were able to accomplish on their own.

Cushion them when they fall, but celebrate with them when they succeed. Chip away at that imposter syndrome piece by piece, and day by day by providing them with small wins. You can work them up to bigger and bigger wins later on. For the early stages, small wins are absolutely critical.

Feeling Welcome

[slide]

Ultimately, your mentorship should be about making the junior feel welcome and safe within your organisation. You’ve probably sensed this as a theme to my points already, but I want to take the last few minutes of this talk to really drive this point home: In fact, this should be what’s happening with everyone in your team.

[slide]

Don’t just take my word for it. Google ran a study called “Project Aristotle” wherein they attempted to find how to build effective teams. They interviewed hundreds of their own employees and they came up with 5 things that effective teams had consistently:

[slide]

[image:EEF8C544-A631-4F6F-8796-09A3F95F045D-94246-0000594A81D4A05E/eQWsRq5-q-m41eEI6GLEObqpxBYJd1pm96gIa-eRSn-QXlPjwO5K6O-DHU8sxny3ChnIQE0mjpnXaaW7QAhQ=s0.png]

The #1 item on this list isn’t “Feeling welcome”, but “Psychological safety”. Same thing. The text underneath says: “Team members feel safe to take risks and be vulnerable in front of each other.” This is the #1 thing you should be encouraging your juniors to do. Take risks and be vulnerable. It is the way they will grow.

Juniors should ultimately feel safe to take risks and to be vulnerable in our teams. Juniors will make mistakes. This is the nature of taking risks. They will mess up from time to time. Give them space to make mistakes. It is how they will learn best.

The remainder of this list is not to be discounted. Dependability, Structure & Clarity, Meaning and Impact are all vital to junior developers progressions.

A junior must be able to depend on the people around them for support. They must be reminded that it’s always OK to ask questions. They must have people around them for that support who they can turn to and ask questions of.

They must have clarity on what their direction is and you can provide that with some solid mentoring and weekly 1-on-1s. Work together to set some goals for them during these 1-on-1s and help them work towards the goals. Gather up some feedback from their peers and talk about it with them.

The 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 celebrate with them when they finish it. You can start with small wins, but work them up from there. Chip away at their imposter syndrome. Be their champion.

When you hire a junior developer, keep these things in mind and ask yourself regularly if you’re following along with them. These things should underpin everything you do with everyone in your organisations, but especially junior developers.

With a concerted effort to make the junior feel psychologically safe, and some semi-structured mentoring in place, they can grow into the future’s most brilliant developers.

Let’s hire and mentor juniors at all of our companies so that they become the next generation of amazing developers.

Join the conversation!

Your email address will not be published. Required fields are marked *

No comment yet.